DMARC Policy: p=none vs p=quarantine vs p=reject — Which Should You Use?
Your DMARC policy is one word in a DNS record, and it decides what the world's mailboxes do with mail that fails authentication for your domain. Here is what each setting really does, both failure modes to avoid, and a safe path from none to reject.
The p= tag in your DMARC record is an instruction to receiving mail servers: when a message using my domain fails DMARC, do this. There are exactly three values, and the difference between them is the difference between "watching spoofing happen" and "stopping it."
What each policy does
| Policy | Receiver behavior on failure | Protection | Risk to real mail |
|---|---|---|---|
p=none | Deliver normally, send you reports | None — monitoring only | None |
p=quarantine | Treat as suspicious — typically the spam folder | Spoofed mail lands in junk | Misconfigured real senders land in junk too |
p=reject | Refuse the message outright at SMTP time | Spoofed mail never arrives | Misconfigured real senders bounce |
p=none: the observation phase, not a destination
Every DMARC rollout should start at p=none with a rua address set:
v=DMARC1; p=none; rua=mailto:reports@yourdomain.comNothing changes for your mail flow, but every major receiver starts sending you daily XML reports listing every source that used your domain — your mail platform, your CRM, your invoicing tool, that newsletter service marketing signed up for two years ago, and any spoofers. (New to the XML? See how to read DMARC reports.)
The trap: staying at p=none forever. It offers zero protection — spoofed mail is delivered normally — and it can quietly become permanent because nothing forces the next step. If your record has said p=none for a year, you have a monitoring subscription, not email security.
p=quarantine: real protection, forgiving failure mode
p=quarantine asks receivers to treat failing mail as suspicious; in practice that means the spam folder. Spoofed messages stop reaching inboxes, and if you got something wrong, genuine messages are recoverable from junk rather than lost. The optional pct= tag lets you phase it in — p=quarantine; pct=25 applies the policy to a quarter of failing mail while you build confidence.
p=reject: the destination
p=reject tells receivers to refuse failing mail during delivery. The sender gets a bounce; the recipient never sees the message. This is the setting that actually ends spoofing of your domain, and the setting phishers check for before choosing whose brand to impersonate. It is also unforgiving: a legitimate sender you forgot to authenticate starts bouncing, visibly, immediately.
When to move — a checklist, not a calendar
Move from p=none toward p=reject when your reports — not your memory — say it is safe:
- Inventory is complete. A few weeks of reports show no unexplained sources of legitimate mail. Day-one reports routinely surprise people; tools sending on your behalf that you forgot about are the norm, not the exception.
- Every real source passes aligned DKIM. Not just "DKIM pass" — the signing domain must match your From domain. Forwarding breaks SPF, so aligned DKIM is what carries you at strict policy (the distinction is unpacked in SPF vs DKIM vs DMARC).
- Failure volume is explained. Remaining failures are attributable to forwarding quirks or actual spoofing — not to any system you own.
Then: p=quarantine (optionally with pct=), watch a couple of weekly cycles for any legitimate source drifting into failure, and finish at p=reject. If you need to generate the records themselves, the free DMARC generator builds them interactively.
The two failure modes, summarized
- Too timid: parked at
p=noneindefinitely — full visibility, zero protection, and your domain remains an attractive spoofing target. - Too bold: jumping to
p=rejectbefore every legitimate sender passes aligned authentication — the failure is silent for you and loud for your customers, whose invoices and password resets simply stop arriving.
The only way to avoid both is to actually read what the reports say each week — which is exactly the chore most teams abandon by week three, because it means hand-parsing XML from a dozen receivers.
Know when it's safe to tighten — without reading XML
PlainDMARC watches your aggregate reports and gives each domain a weekly plain-English verdict: what passed, what failed and why, and whether you are ready for the next policy step. Agencies get every client domain on one flat-price plan, with white-label reports to forward as proof of work.
Create your free account Check your current policy freeFrequently asked questions
Is p=none better than having no DMARC record at all?
Yes, for two reasons. It starts the flow of aggregate reports, which is the only way to inventory who sends as your domain. And bulk-sender rules at Google and Yahoo require at least p=none, so a missing record now directly hurts deliverability for higher-volume senders. Just treat it as the first step, not the finish line.
How long should I stay at p=none before moving to quarantine?
As long as it takes to authenticate every legitimate source your reports reveal — for a simple domain that can be two to four weeks of report data; for an organization with many SaaS tools sending on its behalf, longer. The trigger is a clean report picture (all real senders passing aligned DKIM), not a number of days on a calendar.
Does p=reject stop all phishing that uses my brand?
No. It stops exact-domain spoofing — mail with your real domain in the From address. Phishers can still register lookalike domains (yourcompany-billing.com) or display your brand name with an unrelated address. p=reject removes the most convincing attack, exact impersonation, and is still unambiguously worth reaching.