DMARC: Domain-based Message Authentication, Reporting & Conformance
DMARC tells receiving mail servers what to do when an inbound message claims to be from your domain but fails SPF and DKIM authentication checks.
TL;DR
- 1 Publishes a DNS TXT record at _dmarc.<your-domain> containing your policy.
- 2 Receivers report aggregate stats daily so you can see who's spoofing you.
- 3 At p=reject, receivers refuse mail that fails authentication outright.
Watch
How DMARC stops attackers from spoofing your exact domain, and how to roll it out safely.
The receiver checks SPF and DKIM, verifies alignment with the visible From: domain, then looks up your DMARC policy to decide what to do with a failure.
What it does
DMARC is a policy layer on top of SPF and DKIM. It does two things at once: tells receiving servers how to handle messages that fail authentication (deliver, quarantine, or reject) and asks them to send aggregate reports of every IP that sent mail claiming to be your domain.
Without DMARC, an attacker can register a server, forge your From address, and send phishing messages that look genuine to recipients. SPF and DKIM alone don't tell receivers what to do when they fail; DMARC fills that gap.
DMARC also requires alignment: the domain in the visible From header must align with the domain SPF or DKIM authenticated. This stops attackers from passing SPF with their own domain while spoofing yours in From.
How it works
-
1
Publish a TXT record at _dmarc.<your-domain> declaring your policy (start at p=none for monitoring).
-
2
Mail receivers (Gmail, Microsoft, Yahoo, etc.) check inbound messages against your published SPF and DKIM, then evaluate alignment.
-
3
If neither SPF nor DKIM aligns, the receiver applies your policy: none = no action, quarantine = spam folder, reject = bounce.
-
4
Receivers send daily aggregate reports (rua) showing every source IP that sent as your domain, with per-IP pass/fail counts.
-
5
You parse those reports to identify legitimate senders missing from SPF/DKIM, then tighten the policy to p=quarantine and finally p=reject.
Example record
Common pitfalls
-
Jumping straight to p=reject without first observing 14 days of rua reports. This guarantees broken legitimate forwards.
-
Not setting up DKIM signing on every legitimate sender (mailing platforms, CRM, calendar invites). Without DKIM, forwarded mail breaks SPF and fails DMARC.
-
Leaving t=y on indefinitely. DMARCbis test mode makes receivers apply the next-lower policy (p=reject; t=y behaves like quarantine, p=quarantine; t=y like none), so a domain stuck at p=reject; t=y is only quarantining, never reaching the reject you intended. Remove t=y once reports are clean. (The old pct tag that used to ramp enforcement was removed in DMARCbis; don't reach for it.)
-
Forgetting subdomains. Without an explicit sp= tag, your subdomains inherit the parent policy. If you have aggressive subdomain senders, you may need a separate _dmarc.subdomain entry.