What DMARC does
SPF says which servers may send for a domain. DKIM signs messages so receivers can check they were not altered and came from a key you control. Neither says what a receiver should do when a message fails, and neither checks that the domain being authenticated is the one in the From: header the user sees. DMARC fixes both: it requires alignment (the SPF or DKIM domain must match the From domain) and it publishes a policy telling receivers what to do with mail that fails. It also asks them to send you reports, which is how you find out what is sending as you.
The record lives at _dmarc.example.com as TXT and looks like v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100. The email deliverability checker decodes it and tells you what each tag means for your mail.
The three policies
| Policy | What receivers do with failing mail | When to use it |
|---|---|---|
| p=none | Nothing. Deliver as normal, but send you reports. | The first few weeks. You are collecting data on every source that sends as your domain, including the ones nobody told IT about. |
| p=quarantine | Treat as suspicious: spam folder, or a lower reputation score. | Once the reports show every legitimate source passing. Spoofed mail now goes to junk instead of the inbox; a missed legitimate sender goes to junk too, which users will tell you about. |
| p=reject | Refuse the message at SMTP time. It never reaches the user. | The destination. Spoofing your domain becomes impossible at receivers that honour DMARC, which is all the big ones. Required for BIMI and increasingly expected by Gmail and Yahoo for bulk senders. |
Why almost everyone should start at none
The moment you publish a DMARC record with any policy, receivers start sending aggregate reports (to the rua address) listing every IP that sent mail claiming to be from your domain, how much, and whether it passed SPF, DKIM and alignment. In every organisation I have done this for, the first week of reports contained at least one legitimate sender nobody had on the list: a CRM that a sales team signed up for, a printer that emails scans, a payroll provider, a monitoring system on an old server. At p=none that mail is unaffected while you fix it. At p=reject it silently disappears.
So: publish p=none with a rua address, wait two to four weeks, and read the reports. The raw XML is unpleasant; use a free aggregator or a small script. You are looking for any source with meaningful volume that is not passing DMARC.
The tags that matter
| Tag | Meaning |
|---|---|
| p | Policy for the domain itself. |
| sp | Policy for subdomains. Defaults to p. Set sp=reject even while p=none if you know no subdomain sends mail; attackers love invoices.example.com. |
| pct | Percentage of failing mail the policy applies to. pct=10 with quarantine lets you ramp gradually. Only meaningful for quarantine and reject. |
| rua | Where aggregate (daily summary) reports go. Always set this. If it points to a different domain, that domain has to publish a record authorising it. |
| ruf | Forensic reports: copies of individual failing messages. Few receivers send them and they can contain personal data. Optional. |
| adkim, aspf | Alignment mode: r (relaxed, subdomains count) or s (strict, exact match). Relaxed is the default and is fine for nearly everyone. |
The move from none to quarantine
- Every legitimate source in the reports passes DKIM with your domain (preferred) or SPF with alignment. Fix the ones that do not: usually this means turning on custom DKIM signing in the provider's settings and adding their CNAME records.
- Forwarded mail will fail SPF (the forwarder's IP is not yours) but should pass DKIM if the forwarder did not alter the body. Mailing lists that rewrite subjects will break DKIM; that is what ARC is for and it is beyond your control. Accept a small residual failure rate.
- Set
p=quarantine; pct=25. Wait a week. Check the reports and your helpdesk queue. Increase to 50, then 100.
The move to reject
Once quarantine at 100% has run for a few weeks with no legitimate mail being junked, change to p=reject. There is rarely a reason to ramp pct again; if it survived quarantine it will survive reject. Keep the rua address forever. New senders will keep appearing and the reports are how you find them before their mail bounces.
Common mistakes
- Staying at p=none for years. It is the most common state on the internet and it provides no protection. Set a date.
- No rua. A policy with no reports is flying blind. You will not know what you broke.
- Jumping straight to reject because an auditor asked. Expect a week of missing invoices.
- Record on the wrong name. It must be
_dmarc.example.com, notexample.com. Check with a TXT lookup. - SPF over the lookup limit so SPF never passes and everything depends on DKIM. See the SPF 10 lookup limit.
- Forgetting subdomains. If
spis unset, subdomains inheritp; if you setp=noneand forgetsp, your subdomains are wide open.