DMARC Quarantine vs Reject: Which Policy to Use (and When to Switch)

A DMARC record without an enforcing policy is like a security camera that doesn't record. The p= tag is where DMARC actually starts protecting your domain, and the choice between quarantine and reject matters more than most senders realize.

This guide explains what each policy does, when to use which, and the safest path from p=none to enforcement.

The Three DMARC Policies

DMARC supports three values for the p= tag:

Policy	What happens to mail that fails DMARC	When to use
p=none	Delivered normally; reported to you	Day 1 (visibility only)
p=quarantine	Delivered to spam folder	Transition phase
p=reject	Bounced (not delivered)	Final state: full protection

The pct= tag from RFC 7489 can apply policy to a percentage of mail. For example, p=quarantine; pct=25 asks receivers to quarantine 25% of failing mail and pass the rest. The current standard, RFC 9989 (May 2026), drops pct and keeps only its testing use as t=y, so treat percentages as a request many receivers apply loosely.

What p=quarantine Actually Does

Mail that fails DMARC is delivered to the recipient's spam folder. The recipient can still find and recover the message, which is useful while you're still discovering legitimate senders that aren't yet aligned.

Strengths:

• Stops most spoofed mail from reaching the inbox.
• Surfaces alignment failures without bouncing real mail.
• Low risk of legitimate-mail damage during transition.

Weaknesses:

• Some inbox providers handle quarantine inconsistently (Microsoft is stricter than Gmail).
• Doesn't prevent the recipient from rescuing spoofed mail manually.
• Provides partial brand protection only.

What p=reject Actually Does

Mail that fails DMARC is rejected outright by the recipient server. It never lands anywhere. The sender gets a bounce.

Strengths:

• Strongest possible spoofing protection.
• Eligibility for BIMI (logo display in supported inbox clients).
• Aligns you with Gmail/Yahoo recommendations for bulk senders.

Weaknesses:

• Any legitimate sender not properly aligned silently disappears.
• Misconfigurations cause real customer mail to bounce.
• Requires every shadow IT sender to be discovered and aligned first.

When to Pick Which

Use this decision tree:

• You just published DMARC → p=none with rua reporting. Stay here until your aggregate reports show 99%+ of legitimate mail aligning.
• Aggregate reports show >99% alignment for legitimate senders, with a few unknowns → p=quarantine; pct=10. Inspect weekly, increase pct gradually.
• Aggregate reports show 100% alignment of legitimate mail, no spoofing concerns → p=quarantine; pct=100.
• You want maximum protection AND every legitimate sender is verified aligned → p=reject; pct=100.
• You're a bank, healthcare, government, or any brand frequently spoofed → move to p=reject aggressively. The risk of spoofing damage exceeds the risk of misconfiguration.

The Safe Path from p=none to p=reject

The standard timeline that prevents disasters:

Week	Policy	What to do
1-4	p=none	Publish record, parse aggregate reports, identify all senders
5-6	p=none	Align any unaligned senders (custom domains, ESP CNAMEs)
7-8	p=quarantine; pct=10	Monitor, fix any new failures
9-10	p=quarantine; pct=50	Same
11-12	p=quarantine; pct=100	Same
13-16	p=reject; pct=10 then 50 then 100	Final ramp

Total: ~4 months from publishing DMARC to full p=reject enforcement. Faster is possible but raises the risk of dropping legitimate mail.

What Aggregate Reports Tell You

DMARC's rua aggregate reports arrive daily as XML attachments from every receiving provider. They show:

• Which IPs sent mail claiming to be from your domain.
• How many messages aligned with SPF, DKIM, both, or neither.
• What disposition the receiver applied (none/quarantine/reject).

Parse these into a dashboard, because raw XML is unreadable at scale. The free DMARC report analyzer reads the reports you open, in your browser.

Common Mistakes That Break Real Mail

• Going straight to p=reject without parsing aggregate reports. Discovery rounds always find legitimate senders you forgot.
• Forgetting subdomains. A p=reject on the root domain also covers its subdomains unless an sp= tag says otherwise, so a leftover sp=none quietly exempts every subdomain.
• Misaligned ESP setup. Your ESP signs DKIM with their domain by default; you need to set up a custom DKIM domain for alignment.
• Marketing automation tools. Many SaaS tools send "from" your domain via SendGrid/Postmark/etc. Each must be aligned independently.

p=quarantine vs Spam Filter Quarantine

A point of confusion: p=quarantine tells the receiving server to treat failing mail as suspicious. The receiver still applies its own spam filtering on top. So mail that fails DMARC under p=quarantine might land in spam or be junked even harder. The two filters compound.

FAQ

Is p=reject safe to use? Yes, once you've verified every legitimate sender is aligned. The risk is enforcing before you know every sender.

What does pct=0 do? Effectively p=none for new mail. Old-school trick to test policy changes without affecting delivery. RFC 9989 replaces it with t=y and notes that pct values other than 0 and 100 were applied inconsistently from one receiver to the next.

Does p=reject affect mailing list mail? Yes. This is the most common cause of legitimate mail loss after enforcement. ARC (Authenticated Received Chain) helps mailing lists preserve alignment. Most major lists now support ARC; check yours.

Should subdomain policy match root? Usually yes. Set sp=reject explicitly. If you have unauthenticated subdomains, set them to sp=quarantine temporarily and fix them.

Do I need DMARC if I have SPF and DKIM? Yes. SPF and DKIM verify individual mechanisms; only DMARC enforces alignment and gives you reporting. Gmail and Yahoo require DMARC for bulk senders.

Bottom Line

p=none is for learning. p=quarantine is for transition. p=reject is for protection. Skipping straight to p=reject is the most common way to lose real customer mail. Spend the four months. The protection is worth doing right.

👉 Continue: How to Fix SPF, DKIM, and DMARC · Gmail & Yahoo Sender Requirements · Try the DMARC generator

Sources

• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), the current DMARC standard: the p, sp and np policies, the t testing flag, and why pct was removed.
• RFC 7489: DMARC (2015 informational version), the 2015 version that defined pct and the rule that p applies to subdomains when sp is absent.
• RFC 8617: The Authenticated Received Chain (ARC) Protocol, how intermediaries such as mailing lists pass on authentication results that DMARC would otherwise fail.
• Set up DMARC (Google Workspace Help), Google's recommendation to start at p=none and move to enforcement gradually while reading reports.