DMARC Reject vs Quarantine: What's the Difference?

Q: What does a DMARC quarantine policy do?

p=quarantine instructs receiving servers to accept email that fails DMARC but treat it with suspicion. In practice, consumer mailbox providers like Gmail and Yahoo route these messages to the spam or junk folder, while some business email gateways hold them in an administrative quarantine for review instead. Quarantine is the standard middle stage of a DMARC rollout. It delivers real protection — spoofed messages stop landing in inboxes — while leaving a safety net: if you missed a legitimate sending service in your SPF record or forgot to enable DKIM signing somewhere, those messages are still delivered (just to spam), not silently destroyed. You can spot the problem in your DMARC reports,

Q: What does a DMARC reject policy do?

p=reject is the strictest DMARC policy: it tells receiving servers to refuse any message that fails DMARC during the SMTP transaction, so the message is bounced and never reaches the recipient in any folder. This is the policy that actually stops domain spoofing — attackers can no longer land impersonated mail anywhere in your recipients' mailboxes. The trade-off is that reject leaves no room for authentication mistakes. If a legitimate service sends on your behalf but isn't covered by SPF or DKIM, that mail bounces. That's why reject should be the destination of a staged rollout, not the starting point.

Q: What about DMARC none vs quarantine?

p=none is the third policy option: monitoring mode. Mail that fails DMARC is still delivered normally — the only effect is that you receive aggregate reports showing which sources are sending as your domain and whether they authenticate. None provides visibility but zero protection; quarantine is the first policy level that changes how failing mail is handled. Every DMARC deployment should start at p=none to build an inventory of legitimate senders. But staying there long-term defeats the purpose: spoofed mail is still delivered while you watch it happen in reports.

Q: Which DMARC policy should you use, and in what order?

The proven rollout order is none → quarantine → reject: 1. Start at p=none and collect aggregate reports for a few weeks to identify every service sending as your domain. 2. Fix authentication for each legitimate source — add them to SPF, enable DKIM signing, and confirm alignment. 3. Move to p=quarantine once reports show your legitimate mail passing consistently. Optionally phase it in with the pct tag (for example p=quarantine; pct=25 applies the policy to a quarter of failing mail). 4. Move to p=reject when quarantine has run cleanly — no legitimate mail failing — and you're confident the sender inventory is complete. Move gradually: monitor reports and verify senders before enforcing re

Q: How do you move from quarantine to reject safely?

Treat the switch as a data-driven decision: - Watch aggregate reports while at quarantine. Every failing source should be either an attacker or a sender you've deliberately chosen not to authorize — never a forgotten legitimate service. - Check subdomains. Unless you set a separate subdomain policy (sp), your policy applies to subdomains too, so confirm their senders are authenticated as well. - Phase with pct if cautious. Stepping pct up (25 → 50 → 100) at reject limits the blast radius of any surprise. Note that under RFC 7489, failing messages not selected by the percentage are treated under the next-less-strict policy (reject falls back to quarantine). - Keep monitoring after enforcement

The difference between DMARC reject and quarantine is what happens to email that fails authentication: p=reject tells receiving servers to refuse the message entirely, while p=quarantine tells them to accept it but treat it as suspicious — usually by delivering it to the spam folder. Reject is the stronger end state; quarantine is the safer stepping stone while you confirm every legitimate sender passes SPF and DKIM.

	`p=quarantine`	`p=reject`
Failing email is	Delivered to spam/junk (or held in a gateway quarantine)	Refused during delivery — never reaches the recipient
Protection level	Strong — spoofed mail is kept out of the inbox	Strongest — spoofed mail is never delivered at all
Risk to legitimate mail	Low — a misconfigured sender lands in spam and can be recovered	Higher — a misconfigured sender bounces outright
Best for	Rollout and testing phase	Fully verified sending setup (the end goal)

DMARC Reject vs Quarantine: What's the Difference?

Both policies only apply to mail that fails DMARC — messages where neither SPF nor DKIM passes with a domain that aligns with the visible From address. Mail that authenticates correctly is delivered normally under either policy.

What does a DMARC quarantine policy do?

p=quarantine instructs receiving servers to accept email that fails DMARC but treat it with suspicion. In practice, consumer mailbox providers like Gmail and Yahoo route these messages to the spam or junk folder, while some business email gateways hold them in an administrative quarantine for review instead.

Quarantine is the standard middle stage of a DMARC rollout. It delivers real protection — spoofed messages stop landing in inboxes — while leaving a safety net: if you missed a legitimate sending service in your SPF record or forgot to enable DKIM signing somewhere, those messages are still delivered (just to spam), not silently destroyed. You can spot the problem in your DMARC reports, fix the authentication gap, and move on without losing mail.

What does a DMARC reject policy do?

p=reject is the strictest DMARC policy: it tells receiving servers to refuse any message that fails DMARC during the SMTP transaction, so the message is bounced and never reaches the recipient in any folder. This is the policy that actually stops domain spoofing — attackers can no longer land impersonated mail anywhere in your recipients' mailboxes.

The trade-off is that reject leaves no room for authentication mistakes. If a legitimate service sends on your behalf but isn't covered by SPF or DKIM, that mail bounces. That's why reject should be the destination of a staged rollout, not the starting point.

DMARC quarantine vs reject: which is more secure?

Reject is more secure, because failing mail is never delivered — there's no chance a user digs a convincing phishing message out of the spam folder and acts on it. Quarantine still blocks the inbox, but the message technically exists in the recipient's mailbox.

Side-by-side comparison of DMARC reject and quarantine policies covering action on failure, security level, and when to use each.

Reject blocks failing email outright; quarantine routes it to spam while you test.

That said, "more secure" only matters once your own mail reliably passes. A premature reject policy doesn't make you safer — it makes your invoices, password resets, and notifications bounce. Security teams should judge readiness by DMARC report data, not by ambition.

What about DMARC none vs quarantine?

p=none is the third policy option: monitoring mode. Mail that fails DMARC is still delivered normally — the only effect is that you receive aggregate reports showing which sources are sending as your domain and whether they authenticate. None provides visibility but zero protection; quarantine is the first policy level that changes how failing mail is handled.

Every DMARC deployment should start at p=none to build an inventory of legitimate senders. But staying there long-term defeats the purpose: spoofed mail is still delivered while you watch it happen in reports.

Which DMARC policy should you use, and in what order?

The proven rollout order is none → quarantine → reject:

Start at p=none and collect aggregate reports for a few weeks to identify every service sending as your domain.
Fix authentication for each legitimate source — add them to SPF, enable DKIM signing, and confirm alignment.
Move to p=quarantine once reports show your legitimate mail passing consistently. Optionally phase it in with the pct tag (for example p=quarantine; pct=25 applies the policy to a quarter of failing mail).
Move to p=reject when quarantine has run cleanly — no legitimate mail failing — and you're confident the sender inventory is complete.

Four steps for safely moving a DMARC policy from quarantine to reject.

Move gradually: monitor reports and verify senders before enforcing reject.

You can build a correct record for any stage with our free DMARC record generator, and verify what's currently published with the DMARC checker. For a deeper look at when tightening makes sense, see should you be changing your DMARC policy to make it stricter over time.

How do you move from quarantine to reject safely?

Treat the switch as a data-driven decision:

Watch aggregate reports while at quarantine. Every failing source should be either an attacker or a sender you've deliberately chosen not to authorize — never a forgotten legitimate service.
Check subdomains. Unless you set a separate subdomain policy (sp), your policy applies to subdomains too, so confirm their senders are authenticated as well.
Phase with pct if cautious. Stepping pct up (25 → 50 → 100) at reject limits the blast radius of any surprise. Note that under RFC 7489, failing messages not selected by the percentage are treated under the next-less-strict policy (reject falls back to quarantine).
Keep monitoring after enforcement. New tools and vendors get added constantly; each one needs SPF/DKIM set up before it starts sending, or its mail will bounce.

Frequently asked questions

Does p=quarantine always send mail to the spam folder?

No. DMARC expresses a request, and the receiving server decides how to honor it. Most consumer providers deliver quarantined mail to spam/junk, but enterprise gateways may hold it in an admin quarantine, tag the subject, or apply extra filtering instead.

Is p=none pointless since it blocks nothing?

No — it's the essential first step. None gives you the reporting data to find every legitimate sender before you enforce anything. It's only a problem when a domain stays at none indefinitely, which leaves spoofing unaddressed.

What happens to forwarded email under p=reject?

Forwarding usually breaks SPF because the forwarding server isn't in your SPF record, but DKIM signatures normally survive forwarding intact. Since DMARC passes when either SPF or DKIM passes with alignment, properly DKIM-signed mail still passes after forwarding. That's why enabling DKIM everywhere matters before moving to reject.

Can a DMARC policy affect email that passes authentication?

No. Reject and quarantine only apply to messages that fail DMARC. Mail that passes SPF or DKIM with alignment is delivered normally regardless of policy — though it's still subject to ordinary spam filtering like any other message.

Ready to enforce your DMARC policy?

Understanding reject vs quarantine is the easy part — the work is getting every legitimate sender authenticated so you can enforce with confidence. Palisade automates that journey for MSPs and businesses: monitoring reports, flagging unauthenticated senders, and guiding domains from none to quarantine to reject without lost mail. Start by checking where your domain stands with our free Email Security Score.