Learn · Email authentication
DMARC policies explained: none → quarantine → reject
The p= tag in your DMARC record is the instruction every mailbox provider follows when a message claiming your domain fails authentication. Getting from monitoring to enforcement is the entire point of DMARC — and rushing it is how companies lose real mail.
The three policies
| Policy | What receivers do with failing mail | Use it when |
|---|---|---|
p=none | Deliver normally, but count it in your aggregate reports. Zero protection, full visibility. | You've just published DMARC and are discovering your senders. |
p=quarantine | Treat as suspicious — in practice, the spam folder. Mistakes are recoverable: misclassified mail sits in spam rather than vanishing. | Your known senders pass aligned and you're validating enforcement. |
p=reject | Refuse delivery outright. Spoofed mail never reaches a human. The destination. | Reports show clean, aligned traffic from every legitimate source. |
The supporting tags
sp=— a separate policy for subdomains that exist. Attackers love unprotected subdomains (billing.yourbrand.com); if your subdomains don't send mail,sp=rejectis a free win even while the apex is still at none.np=— a policy for subdomains that don't exist at all, which is where most subdomain spoofing actually happens. New in RFC 9989. If nothing legitimate can send from a name you never created,np=rejectcosts you nothing.adkim=/aspf=— alignment strictness. The default, relaxed, lets subdomains align with the parent (mail signedd=news.example.comaligns with a From ofexample.com); strict requires an exact match. Relaxed is right for almost everyone.
pct= is gone. The old percentage tag — p=quarantine; pct=25 to enforce against a quarter of failing mail — was removed by RFC 9989. It was widely misread, inconsistently implemented, and gave a false sense of a gradual rollout. Leaving it in your record is harmless but does nothing; receivers are free to ignore it. Ramp by fixing senders and then moving p=, not by sampling.
The safe playbook
- Publish
p=nonewith reporting. Nothing changes for your mail; data starts flowing. Expect surprises — most teams find senders they forgot existed within days. - Fix every legitimate source. Work through your reports: your mail platform, each ESP, the billing system, the support desk. Each needs SPF or (preferably and) DKIM passing aligned to your domain. This is the long stage — typically two to eight weeks depending on how many tools send as you.
- Move to quarantine when compliance is stable. A steady 98–100% of legitimate volume passing aligned for a couple of weeks is the usual bar. There is no partial setting to hide behind since
pct=was removed, so the ramp is your sender inventory, not a percentage. Forwarded mail will produce some unavoidable stragglers — that's expected and small. - Watch, then reject. If quarantine produces no complaints and reports stay clean for a few weeks, move to
p=reject. Your domain is now closed to spoofing at every mainstream provider. - Keep monitoring. New tools get adopted, keys expire, records get edited. The companies that get burned post-reject are the ones who stopped reading their reports.
Rolling back is not failure. If tightening breaks something, drop back one level, fix the source in the reports, and advance again. The staged path exists precisely so mistakes cost a spam-folder incident, not a lost contract.
Not sure where your domain stands right now? The DMARC checker reads your live record and grades it — which stage you’re at, and whether anything in SPF or DKIM would make the next step unsafe.
Common mistakes
- Jumping straight to reject because a compliance checklist said "publish DMARC". Legitimate-but-misconfigured senders go dark instantly.
- Parking at
p=noneforever. None is a starting line, not a policy — it stops zero spoofed messages. (It technically satisfies bulk-sender requirements, but leaves your brand unprotected.) - Forgetting subdomains — enforce the apex, leave
spandnpunset, and attackers just spoof a subdomain instead. Usually one that doesn't exist, which is whatnpis for. - Editing DNS by hand under pressure. A typo in the record can invalidate the whole policy. This is why Canny Pigeons offers hosted DMARC: you delegate the record once via CNAME, and policy changes become dashboard buttons — advance or roll back in one click, with no DNS edits and no syntax to fumble.