What is DMARC?
A plain-English explanation of DMARC — what it does, how it builds on SPF and DKIM, the three policy modes, and common pitfalls to avoid.
What is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a DNS-based email policy that tells receiving mail servers what to do when an incoming message fails authentication — and sends you reports so you can see who is sending email on behalf of your domain.
DMARC builds on top of SPF and DKIM. You need at least one of those two working before DMARC can do anything useful.
Why DMARC exists
Before DMARC, a spammer could put any address in the From: header of an email. SPF and DKIM each check different things — the envelope sender and the DKIM signature respectively — but neither standard told receiving servers what to do when those checks failed. DMARC fills that gap. It lets you declare: "If a message claims to be from my domain and fails authentication, reject it."
How it builds on SPF and DKIM
DMARC requires alignment — not just that SPF or DKIM passes, but that the authenticated domain aligns with the From: header domain.
- SPF alignment — the domain in the
Return-Path(envelope sender) must match theFrom:domain. - DKIM alignment — the
d=tag in the DKIM signature must match theFrom:domain.
DMARC passes if at least one aligned check passes. If both fail, DMARC fails and the policy you have set determines what happens next.
Alignment can be relaxed (subdomains allowed) or strict (exact match required). Relaxed alignment is the default and works for most setups.
The three policy modes
You control DMARC behaviour through the p= tag in your DNS record.
none
p=noneMonitor mode. Receiving servers do not take any action on failing messages — they deliver them normally. You still receive aggregate reports so you can see what is passing and failing before you enforce anything.
Use none when: you have just published a DMARC record and are not yet confident all your legitimate sending sources are covered by SPF or DKIM.
quarantine
p=quarantineSuspicious mode. Receiving servers send failing messages to the spam/junk folder instead of the inbox. Legitimate mail that fails authentication will still reach recipients, just in their spam folder.
Use quarantine when: your none-mode reports show only your own legitimate senders and no unexpected third-party sources.
reject
p=rejectEnforcement mode. Receiving servers drop failing messages entirely. They do not reach the recipient's inbox or spam folder.
Use reject when: you have confirmed all legitimate senders pass authentication and you are ready to fully block spoofed messages.
Aggregate reports
DMARC aggregate reports are XML files sent daily (or more often) by receiving mail servers to the rua= address in your DMARC record. Each report shows:
- Which IP addresses sent mail claiming to be from your domain
- How many messages each IP sent
- Whether SPF, DKIM, and DMARC passed or failed for each source
These reports are the primary tool for auditing your email deliverability coverage. Most organisations use a third-party service to parse and visualise the XML, because the raw format is not human-friendly.
A note on DomainCare's coverage. DomainCare does not currently parse DMARC aggregate reports. We monitor the DMARC record itself — presence, policy mode, and changes — but the XML files arriving at your rua= address are not yet ingested or visualised in the dashboard. Aggregate report parsing is on the roadmap for a future release. Until then, you will need a separate parser to make sense of the XML.
Publishing a DMARC record
A DMARC record is a TXT record published at _dmarc.<yourdomain>. Here is a minimal example that starts in monitor mode and directs aggregate reports to your postmaster address:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"A more complete record with a pct rollout and forensic reporting:
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=r; aspf=r"Tag reference:
| Tag | Meaning |
|---|---|
v=DMARC1 | Version — always required, always DMARC1 |
p= | Policy: none, quarantine, or reject |
pct= | Percentage of failing mail the policy applies to (1–100, default 100) |
rua= | URI for aggregate reports |
ruf= | URI for forensic (failure) reports |
adkim= | DKIM alignment: r (relaxed) or s (strict) |
aspf= | SPF alignment: r (relaxed) or s (strict) |
Common pitfalls
Skipping the none phase. Publishing p=reject on day one will break legitimate mail from any sending service you forgot to configure — transactional email providers, CRMs, billing systems. Always start with none, review reports for 2–4 weeks, then move to quarantine, then reject.
Forgetting subdomains. DMARC applies to the exact domain in the From: header. Subdomains inherit the policy unless you publish a separate record or use the sp= tag. If you send transactional mail from mail.example.com, that subdomain needs its own SPF and DKIM records.
pct= and quarantine/reject. The pct= tag applies the policy to a random sample of failing messages. Setting pct=10 during rollout is a useful safety net — you enforce on 10% and can increase gradually. The other 90% are treated as if the policy were none.
Not collecting reports. Publishing DMARC without a rua= address means you have no visibility. Even in none mode, always include a reporting address.
SPF +all or no SPF. DMARC cannot protect your domain if your SPF record ends in +all, which authorises every IP in the world to send on your behalf.
Third-party senders not signing with DKIM. Many ESP platforms let you add a DKIM signature for your own domain. If an ESP sends on your behalf without a DKIM signature aligned to your domain, those messages will fail DMARC once you enforce. Check alignment in your aggregate reports before moving to reject.
The migration path
- Publish
p=none; rua=mailto:... - Wait 2–4 weeks and review aggregate reports
- Identify and fix any legitimate senders that are failing
- Move to
p=quarantine; pct=10 - Monitor spam-folder complaints; increase
pctincrementally to 100 - Move to
p=reject
DomainCare monitors your DMARC record and fires alerts when the record changes, when a policy change is detected, or when the record goes missing. See the email deliverability check for the full list of alerts.
Related
Ready to protect your domain? Create a free DomainCare account and see your current DMARC status in under a minute.