What Is DMARC? Email Authentication Explained (2026)
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.
What is a DMARC record?
A DMARC record is a single DNS TXT record published at _dmarc.<your-domain>. It is a list of semicolon-separated tags that tell receiving mail servers your policy and where to send reports. Here is a typical record and what each tag means.
| v=DMARC1 | Version. Required, and must be the first tag. Marks the record as DMARC so receivers parse the rest. |
| p= | Policy for your domain: none (monitor only), quarantine (send failing mail to spam), or reject (refuse it outright). This is the tag that actually stops spoofing. |
| rua= | Where to send daily aggregate reports (a mailto: address). This is how you see every IP sending as your domain. Almost always worth setting. |
| ruf= | Where to send forensic / failure reports (per-message samples). Many receivers no longer send these for privacy reasons, so treat it as optional. |
| sp= | Policy for subdomains. If omitted, subdomains inherit p. Set it explicitly when a subdomain has a different sending profile. |
| np= | Policy for non-existent subdomains (DMARCbis, RFC 9989). np=reject closes the spoof gap for made-up subdomains like invoices.yourdomain.com. |
| adkim= / aspf= | Alignment mode for DKIM and SPF: r (relaxed, the default, allows subdomain matches) or s (strict, exact match). |
| fo= | Failure-reporting options. fo=1 asks for a report when either SPF or DKIM fails to align, which is the most useful setting. |
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.