1What is DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol standardized inRFC 7489(March 2015). It builds on top of two existing mechanisms — SPF and DKIM — and serves three distinct purposes:
- Policy enforcement.It tells receiving mail servers what to do with email that fails SPF or DKIM checks — deliver it, quarantine it, or reject it outright.
- Alignment verification.DMARC checks that the authenticated domain in SPF or DKIM matches the domain in the
From:header visible to recipients — the key field for brand impersonation attacks. - Reporting.ISPs and mail providers send aggregate reports (daily XML summaries) and optional forensic reports back to an address you specify — giving you full visibility into who is sending email on behalf of your domain.
DMARC is published as a DNS TXT record under the subdomain_dmarc.yourdomain.com. When that record is absent, receiving servers have no instruction from you — which is exactly the problem.
2Why "DMARC Missing" is a Critical Finding
This is not a configuration preference — it's an active security gap.
Without a DMARC record, any SMTP server anywhere in the world can send email with your domain in theFrom:header — and receiving servers will accept it.
Your domain can be freely spoofed
Attackers routinely enumerate domains without DMARC and use them for brand impersonation phishing campaigns. Recipients see your domain name — they trust it. You have no way to stop this without a DMARC policy ofquarantineorreject.
Zero visibility into email abuse
Without a DMARC record (evenp=nonewith reporting), you receive no aggregate reports from Gmail, Outlook or Yahoo about who is sending email as your domain. Abuse can go undetected for months.
Compliance gap — documented and auditable
PCI-DSS 4.0 Requirement 5.4, SOC 2 Type II CC6.6, ISO 27001 A.13.2 and GDPR Article 32 all reference email security controls. A missing DMARC record is a traceable, auditable control failure that will appear in security assessments.
Deliverability risk since February 2024
Google and Yahoo now require bulk senders (5,000+ messages per day) to have a published DMARC record atp=noneor higher. Without one, your legitimate transactional or marketing email may be rate-limited or routed to spam.
3Prerequisites: SPF & DKIM First
Before publishing a DMARC policy ofquarantineorreject, you must have both SPF and DKIM correctly configured for every service that sends email on your behalf. Skipping this step will cause your own legitimate email to be blocked.
SPF Record
A DNS TXT record at your apex domain that lists which mail servers are authorized to send email as your domain.
v=spf1 include:_spf.google.com include:sendgrid.net ~allCheck with:dig TXT yourdomain.com
DKIM Signing
A cryptographic signature added to outgoing email by your mail provider. Published as a TXT record at a selector subdomain.
selector._domainkey.yourdomain.comConfigure via your email provider — Google Workspace, Microsoft 365, SendGrid, Mailgun, etc.
Map all your sending sources before you start
Create an inventory of every service that sends email from your domain: your primary mail provider, transactional email (SendGrid, Postmark, Mailgun), marketing automation (Mailchimp, HubSpot, Klaviyo), CRM (Salesforce, HubSpot), and any internally hosted mail servers. Each one needs an SPF include and DKIM selector configured before you move toquarantineorreject.
4The Three DMARC Policies
DMARC defines three policy values via thep=tag. They control what receiving servers do with messages that fail authentication.
| Policy | What Happens to Failing Email | Protection Level | When to Use |
|---|---|---|---|
p=none | Email is delivered regardless of failure. Reports are still sent torua= | Visibility only | Monitoring phase — learn who is sending, change nothing |
p=quarantine | Failing email is routed to the recipient's spam or junk folder | Partial protection | Transition phase — validate all legitimate senders first |
p=reject | Failing email is rejected outright by the receiving server and never delivered | Full enforcement | Full enforcement — all senders properly authenticated |
5The DMARC Record Syntax
A DMARC record is a single DNS TXT record published at_dmarc.yourdomain.com. Here is a complete example with all common tags:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; sp=none; pct=100; adkim=r; aspf=r| Tag | Required | Description |
|---|---|---|
v= | Yes | Version identifier - always DMARC1 |
p= | Yes | Policy: none | quarantine | reject |
rua= | Recommended | Aggregate report destination - mailto: URI where ISPs send daily XML summaries |
ruf= | Optional | Forensic (per-message failure) report destination - not all providers send these |
sp= | Optional | Subdomain policy - inherits p= if omitted. Set explicitly for parked subdomains |
pct= | Optional | Percentage of messages to apply the policy to (1-100, default 100). Useful for gradual rollout |
adkim= | Optional | DKIM alignment: r (relaxed, default) or s (strict). Relaxed allows subdomain matching |
aspf= | Optional | SPF alignment: r (relaxed, default) or s (strict). Strict requires an exact domain match |
6Step-by-Step Implementation Guide
Audit your sending infrastructure
List every service that sends email from your domain. Include your primary mail provider, transactional email services (SendGrid, Postmark, Mailgun, Amazon SES), marketing platforms (Mailchimp, HubSpot, Klaviyo), CRM systems, and any on-premise or cloud mail servers. Missing a single authorized sender from your SPF or DKIM configuration will cause legitimate email to fail DMARC.
Verify SPF is published and correct
Check your SPF record with dig TXT yourdomain.com. Ensure every sending service has an include: entry. SPF has a 10 DNS lookup limit - exceeding it causes permerror and automatic DMARC failure. Tools like MXToolbox can flatten your SPF if you exceed this limit.
Enable DKIM on all sending services
Generate a DKIM keypair in each service and publish the provided TXT record at selector._domainkey.yourdomain.com. Verify each one resolves correctly before proceeding. This is the step most frequently skipped - and the one that causes most quarantine failures.
Publish your first DMARC record at p=none
Start with a monitoring-only policy. This collects reporting data without affecting email delivery. Include an rua= address to receive aggregate reports - this is critical for the monitoring phase.
Monitor aggregate reports for 2-4 weeks
ISPs will send daily XML reports to your rua= address. Use a DMARC report analyser (Postmark DMARC Digests, Dmarcian, Valimail, or free tools) to identify all sources sending email as your domain, and confirm SPF and DKIM pass rates.
Progressively tighten the policy
Once all legitimate sources pass consistently, move through quarantine with pct=25, then pct=100, then reject with pct=25 and finally pct=100. See the Gradual Rollout Strategy section below.
7Gradual Rollout Strategy
Never jump directly top=reject. A phased rollout protects deliverability while progressively increasing protection.
Phase 1 - Monitoring
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100Establish baseline. Collect aggregate reports. Identify all sending sources.
Phase 2 - Partial Quarantine
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=25Quarantine 25% of failing messages. Monitor reports for unexpected failures.
Phase 3 - Full Quarantine
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100All failing messages go to spam. Validate no legitimate email is affected.
Phase 4 - Partial Reject
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=25Reject 25% of failing messages. Final check before full enforcement.
Phase 5 - Full Enforcement
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100Complete enforcement. Continue monitoring reports for new sending sources.
8Common Mistakes to Avoid
Jumping straight to p=reject
The single most common mistake. Any unauthenticated legitimate sender - a third-party tool your team added without informing IT - will have its email silently blocked. Always go through the monitoring phase.
Forgetting third-party senders
CRM tools, marketing automation, ticketing systems and bulk email providers all need SPF includes and DKIM selectors configured before you tighten policy.
Ignoring the subdomain policy
By default, subdomains inherit the apex domain DMARC policy. But parked subdomains or service subdomains may have their own sending behaviour. Audit your subdomains before assuming inheritance is safe.
Not reading aggregate reports
Publishing DMARC without monitoring the rua= reports defeats the purpose. Aggregate reports are the primary feedback mechanism - read them weekly during rollout.
Strict DKIM alignment too early
adkim=s (strict) requires the DKIM signing domain to exactly match the From: domain. If you use a sending subdomain (e.g. mail.yourdomain.com), relaxed alignment (default) is typically correct.
Leaving parked domains unprotected
Domains that do not send email are prime spoofing targets. Publish v=DMARC1; p=reject; sp=reject on all parked domains immediately - they need no monitoring phase.
9Verifying Your Record with DomainRisk.io
After publishing your DMARC record, trigger a new scan in DomainRisk.io. The email security sub-score will reflect the updated posture within seconds of the scan completing.
The _dmarc. TXT record resolves correctly and parses as valid DMARC syntax.
DomainRisk.io records the current policy value (none / quarantine / reject) and flags p=none as medium severity and missing as critical.
The email authentication security sub-score (20% of total security score) is recalculated based on DMARC, SPF and DKIM posture together.
Monitor continuously, not just once
DMARC is not a set-and-forget control. Policy changes, new sending services and DNS changes can reintroduce gaps. DomainRisk.io checks your DMARC record on every scheduled scan and alerts you the moment it changes or regresses.
✓Key Takeaways
A missing DMARC record means your domain can be freely used for phishing. This is a critical finding, not a preference.
Start with p=none and an rua= reporting address. This gives you visibility with zero delivery risk.
SPF and DKIM must be configured for every sending service before you move to quarantine or reject.
The gradual rollout (none → quarantine 25% → quarantine 100% → reject 25% → reject 100%) is the safest path to full enforcement.
Read your aggregate reports throughout rollout. They tell you exactly what is failing and why.
Parked domains should go directly to p=reject — they have no legitimate email traffic to protect.
A paid DomainRisk.io plan will re-check your DMARC configuration on every daily scan and alert you the moment it changes.
Built on these foundations
SPF Explained: How One DNS Record Stops Spoofing — and How One Misconfiguration Breaks Everything
Configure the foundational DNS record that authorizes your sending servers — the first prerequisite for DMARC enforcement.
Read the guideEmail SecurityDKIM Explained: How Cryptographic Signing Proves Your Emails Are Genuine
Add the cryptographic signature layer that makes DMARC resilient under email forwarding — the second pillar you need before enforcing any policy.
Read the guide