What is DMARC and what should my policy be?
SPF and DKIM authenticate things the recipient never sees. DMARC is the record that finally connects them to the From address on screen — which is the only part a human reads.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record at _dmarc.yourdomain.com that does two things: it tells receiving servers what to do with mail that fails authentication — p=none, p=quarantine or p=reject — and it asks them to send you aggregate reports about every source sending as your domain. Its real contribution is alignment: it requires the domain authenticated by SPF or DKIM to match the domain in the visible From header, which is what stops a spoofer passing authentication on their own domain while displaying yours.
The record, tag by tag
A working record: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=r; aspf=r, published at _dmarc.example.com.
| Tag | Means | Sensible value |
|---|---|---|
| v=DMARC1 | Version — must be first | Required |
| p= | Policy for the domain itself | none → quarantine → reject, in that order |
| sp= | Policy for subdomains | Same as p, or reject if you send no subdomain mail |
| rua= | Where to send aggregate reports | A mailbox you will actually read |
| ruf= | Where to send per-message forensic reports | Usually omitted — few receivers send them |
| pct= | Percentage of mail the policy applies to | 100; lower only during a cautious rollout |
| adkim= | DKIM alignment strictness | r (relaxed) unless you have a reason |
| aspf= | SPF alignment strictness | r (relaxed) |
| fo= | When to generate forensic reports | 1, if you use ruf at all |
What each policy actually does
| Policy | Effect on failing mail | Use it when |
|---|---|---|
| p=none | Nothing. Delivery is unchanged; reports still arrive. | Week one. Always start here. |
| p=quarantine | Failing mail goes to the spam folder | Reports are clean for two to four weeks |
| p=reject | Failing mail is refused at the server and never delivered | Quarantine has run without legitimate losses |
A rollout that does not cost you mail
| Stage | Record | What to watch |
|---|---|---|
| Week 0 | SPF and DKIM published and passing for your main sender | Send a test to a Gmail address and read the headers |
| Week 1 | v=DMARC1; p=none; rua=mailto:… | Reports begin arriving within a day or two |
| Weeks 2–4 | Still p=none | Identify every sending source in the reports; authorise or retire each |
| Week 5 | p=quarantine; pct=25 | A quarter of failing mail is junked — a cheap test |
| Week 7 | p=quarantine; pct=100 | Watch for complaints from staff and customers |
| Week 10 | p=reject | Failing mail is now refused outright |
| Ongoing | p=reject; sp=reject | Keep reading reports — new SaaS tools appear constantly |
Why it is worth the effort
Since 1 February 2024 Google has required a DMARC record from bulk senders to Gmail, and Microsoft did the same for Outlook.com from 5 May 2025 — at p=none, which is the easy part. The harder part, reaching p=reject, is what actually stops other people sending invoices in your name, and it is the only one of the three records that does. A domain at p=reject cannot be convincingly spoofed at any receiver that honours DMARC, which is now most of them.
Sources: IETF RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), Google Workspace Email sender guidelines (effective 1 February 2024) and Microsoft’s Outlook.com sender requirements (effective 5 May 2025).
Check your own numbers
Read the _dmarc TXT record for any domain and see its published policy.
Frequently asked
Should I start at p=reject?
No. Start at p=none, which changes nothing about delivery and simply turns on reporting. Spend two to four weeks reading the aggregate reports, because they will show sending sources you had forgotten - a billing system, an old marketing platform, a form on the website. Fix those, move to p=quarantine, watch again, then go to p=reject. Jumping straight to reject is how organisations discover their own invoices were failing.
What is the difference between alignment and authentication?
Authentication asks whether SPF or DKIM passed for some domain. Alignment asks whether that domain is the same one in the From header the recipient sees. A phisher can trivially pass SPF for their own domain while putting yours in the From line - that is authenticated but not aligned, and DMARC is the only one of the three records that checks it.
Why am I getting XML files from Google and Microsoft?
Those are the DMARC aggregate reports you asked for with the rua tag, and they are the most valuable part of DMARC. Each is a daily summary from one receiver: which IPs sent mail claiming your domain, how many messages, and whether SPF and DKIM passed and aligned. Raw XML is unreadable at volume, which is why report-parsing services exist; for a small domain, opening a few by hand is genuinely informative.
Does DMARC break mailing lists and forwarding?
It can, and this is the main cost of p=reject. A mailing list that rewrites the subject or appends a footer breaks the DKIM signature, and forwarding breaks SPF because the forwarding server is not in your record. Well-run lists work around it by rewriting the From address to their own domain. Plain forwarding to an address that then applies DMARC strictly is the case that still loses mail, and there is no clean fix for it.
Related answers
Need email authentication checks inside your own product?
We build SPF, DKIM, DMARC and MX validators as embeddable widgets or a plain JSON API in your branding, wired to your own lead form. Tell us which checks you need and we will send a working demo.
Request received
Thanks — we will reply within one business day. Meanwhile, all 164 tools are free to use, no signup.