DMARC p=reject vs p=quarantine: Which Policy Should You Choose?
Published · updated
Figures as of 2026-07-28 · methodology v8. Aggregate census data across 276 million graded domains. DMARC is the DNS policy that tells receiving mail servers what to do with messages that fail authentication. See how we grade.
Part of the DMARC pillar — DMARC adoption, maturity and league tables, measured across the whole census.
Choose p=reject if your DMARC reports show every legitimate sender passing — it is the only policy that refuses forged mail outright, and for most domains it is the destination. Choose p=quarantine as the deliberate step on the way there, or as the permanent setting when a wrongly-flagged real message must land in a spam folder you can recover it from, rather than bounce. Both count as enforcement; both stop the everyday forgery that p=none waves through. And the internet’s enforcers are split almost exactly down the middle: as of 2026-07-28, 6.43% of domains quarantine and 5.41% reject — out of just 11.84% that enforce at all. This guide is the decision between the two, and the safe way to get there.
What each policy actually does at the receiver
A DMARC policy is an instruction you publish in DNS; the receiving mail server is the one that acts on it. When a message claiming to be from your domain fails authentication, your p= value tells the receiver what you’d like done:
| Policy | What you’re asking | A forged email | A misconfigured real email |
|---|---|---|---|
p=none | ”Deliver it anyway, just report it” | Lands in the inbox | Lands in the inbox |
p=quarantine | ”Treat it as suspicious” | Goes to spam/junk | Goes to spam — recoverable |
p=reject | ”Refuse it” | Bounced at the door | Bounced — the sender gets an error |
Two details matter in practice. First, a DMARC policy is a request, not a command — receivers apply it at their discretion. The major mailbox providers honour it, which is why enforcement works; a few smaller ones interpret quarantine loosely. Second, the failure modes differ in a way that drives the whole decision: under quarantine, a legitimate message that fails authentication is misfiled — annoying, but sitting in a junk folder waiting to be found. Under reject, it is refused during delivery — the sending server gets a bounce. That bounce is loud (the sender knows immediately something broke), but the message does not arrive.
Why p=none is surveillance, not protection
Before comparing the two enforcing policies, be clear about the one that isn’t. p=none tells receivers to deliver forged mail and send you a report about it. You get visibility; the forger gets delivery. It is the correct first step — and the single most common place to get stuck: 13.96% of all domains sit at p=none, more than the 11.84% that enforce. From an attacker’s point of view, a domain parked at p=none is identical to a domain with no DMARC at all. If that’s where your domain is today, the question isn’t reject versus quarantine — it’s how quickly you can safely reach either. See why p=none is not protection.
The staged path: none → quarantine → reject
Nobody should jump from monitoring straight to p=reject, and nobody has to. The policy ramp is designed to be climbed in small, reversible steps:
- Start at
p=nonewith reporting on — a record likev=DMARC1; p=none; rua=mailto:reports@yourdomain. Collect aggregate reports for a few weeks and account for every legitimate sender: your mail provider, the newsletter platform, the invoicing tool, the CRM. Get each one passing SPF or DKIM with alignment. - Move to
p=quarantine; pct=10. Thepcttag asks receivers to apply the policy to a sample — here, 10% — of failing mail. If something legitimate starts landing in spam, only a slice of it is affected while you fix the sender. - Ramp
pctup — 25, 50, then 100 (or remove the tag; 100 is the default) — watching the reports at each step. - Switch to
p=reject. Same ramp available if you want it. This is the setting that actually refuses forgery at the door.
Each step is a single DNS edit. Two honest caveats: pct sampling is not honoured by every receiver — some apply any enforcement policy in full, so treat the ramp as damage limitation, not a guarantee — and the DMARC standard’s 2026 revision (DMARCbis) retires pct in favour of a simpler t=y test flag, so expect tooling to evolve. Neither caveat changes the shape of the path: quarantine first, watch, then reject.
One more trap on the way up: the policy value must be spelled exactly none, quarantine or reject. The census found 38,650 domains whose record carries a token receivers can’t parse — quarentine, rejet, keine — which silently downgrades the record to no policy at all. The typo list is worth two minutes before you publish. If you manage DNS at a big provider, the per-host walkthroughs cover the exact clicks: Google Workspace, Microsoft 365, Cloudflare.
When quarantine is the right permanent choice
The standard advice — quarantine is a waypoint, reject is the destination — is right for most domains. But “most” is not “all”, and the near-even split in the census (6.43% vs 5.41%) is not purely domains in transit. Quarantine is a defensible permanent policy when:
- Your mail flows through forwarders you don’t control. Forwarding can break SPF, and mailing lists can break DKIM. If your reports show a steady trickle of legitimate-but-failing mail you cannot fix at the source, quarantine keeps that mail recoverable instead of bounced.
- A lost message costs more than a delivered forgery. For some businesses — bookings, legal notices, supplier invoices coming in reply to your domain’s mail — the worst case of
reject(a real message refused, sender assumes it arrived) outweighs the worst case ofquarantine(a forgery in someone’s spam folder). - You’re mid-migration. Changing mail providers or consolidating domains re-opens the “who sends as us?” question; quarantine holds real protection while the picture settles.
What quarantine permanently costs you: forged mail still arrives — into junk folders, where some users dutifully dig it out. Reject is the only policy under which a forged message never reaches a human at a participating receiver. If your reports have been clean for a month and none of the above applies, take the last step.
Rollback safety: reject is not a one-way door
The fear that keeps domains at p=none for years is “what if we break real mail?” — so it’s worth stating plainly what a rollback looks like: editing one TXT record back. The change propagates within your DNS TTL — set that TTL to something short (300–3600 seconds) before you start moving policies, and a bad step can be fully reversed in minutes.
The two policies also fail differently, and knowing this in advance is most of the safety:
- Quarantine misfires quietly. A legitimate sender you missed lands in spam. Nothing is lost; you fix the sender’s authentication and the mail flows normally again. This is why it’s the middle step.
- Reject misfires loudly. The sending system gets an SMTP rejection and (for any well-behaved sender) a bounce notice — so a misconfigured newsletter run announces itself within the hour rather than silently degrading for weeks. Loud is unpleasant, but loud is fast to detect and fast to revert.
Also check your subdomain exposure before enforcing: the sp= tag sets a separate policy for subdomains, and an unstated sp= inherits your p=. Domains that send no mail at all — parked brands, redirect-only domains — skip the whole ramp: publish p=reject today, since there is no legitimate mail to protect. The full record syntax is covered in the DMARC fix guide.
The monitoring you need before (and after) you move
Every safe policy move in this guide depends on one thing: you can see what would break. That means aggregate (rua=) reports — the daily summaries receivers send you, listing every source that sent mail as your domain and whether it passed. Across the census, only 10.16% of domains collect them; a DMARC record with no reporting address is enforcing blind.
Before each policy step, your reports should show, for at least two clean weeks: every known sender passing and aligned, no unexplained legitimate-looking sources, and forwarding flows accounted for. The hard part is not reading the reports — it’s the detective work of attributing every source to a real system, which is the wall in the DMARC maturity model where most stalled deployments die. And monitoring doesn’t end at p=reject: new SaaS tools get connected, providers change IPs, configurations rot. The reports are how you find out before your customers do — a discipline major receivers now effectively require of bulk senders anyway.
Frequently asked questions
Is p=reject better than p=quarantine? For stopping impersonation, yes — reject is the only policy under which forged mail is refused rather than delivered somewhere. Quarantine is the right choice while you build confidence, and a defensible permanent choice when lost real mail costs you more than a forgery in a spam folder.
Can I go straight from p=none to p=reject?
Only if your domain sends no mail at all — then do it today. For a sending domain, move through quarantine (ideally with a pct ramp) so that anything you missed misfiles recoverably instead of bouncing.
What does pct= actually do?
pct=25 asks receivers to apply your policy to roughly 25% of failing messages, letting you phase enforcement in. Not all receivers honour the sampling, and the 2026 DMARC revision replaces it with a t=y test flag — treat it as a damage limiter, not a guarantee.
How long should I stay at p=quarantine? Until your aggregate reports show every legitimate sender passing and aligned for a few clean weeks — typically two to six weeks in practice. If the reports stay clean and no structural reason (forwarders, migration, recoverability) applies, move to reject.
If reject goes wrong, is mail lost forever? The refused messages don’t arrive, but well-behaved sending systems receive a bounce, so legitimate senders find out immediately — and your rollback is a single DNS edit that takes effect within your TTL. Keep the TTL short during the transition.
See which policy your domain publishes today
The gap between “we have DMARC” and “we enforce DMARC” is where impersonation lives. Check your domain free and private — see your actual policy, whether reports are flowing, and the one move to the next stage.
Check your domain → · Fix DMARC → · What is DMARC? → · The DMARC pillar → · Aggregate data only. Data stored and processed in the EU.