May 20, 2026 · 7 min read · DMARCEmail SecuritySPF

DMARC p=reject vs p=quarantine: Which Policy Should You Set?

Most domains sit at p=none forever because admins are scared of breaking email. Here's what each policy actually does, when each is appropriate, and how to safely move to p=reject without dropping legitimate mail.

What DMARC policies actually do

DMARC tells receiving mail servers what to do when an email fails authentication — when an inbound message claims to be from your domain but can't pass SPF or DKIM alignment. There are three policy values:

Policy	What receiving servers do	Your visibility
`p=none`	Nothing — deliver the message normally	Aggregate reports only (rua=)
`p=quarantine`	Route to spam/junk folder	Reports + forensic (ruf=)
`p=reject`	Reject the message outright at SMTP	Reports + forensic (ruf=)

p=none is not protection. It's monitoring mode. Attackers sending phishing from your domain can still land in inboxes while you're on p=none — the policy literally tells receiving servers to do nothing.

When to use p=quarantine

Quarantine is the right intermediate step when you've identified most of your sending sources in SPF but aren't fully confident you've covered everything. Legitimate mail that fails DMARC goes to spam instead of being silently dropped, which gives you a safety net while you tighten things up.

Watch out: quarantine doesn't stop targeted attacks. A sophisticated attacker sending a spear-phishing message "from" your domain will end up in the target's spam folder — still visible, still clickable, especially on mobile where spam folders aren't labeled as prominently.

Use quarantine when:

You've just added DMARC for the first time and are still auditing sending sources
You have third-party senders (marketing platforms, HR tools, ticketing systems) that you're still configuring DKIM on
You want a buffer period before full rejection to review forensic reports

When to use p=reject

Reject is the goal. It's the only policy that actually stops spoofing — messages that fail DMARC are rejected at the SMTP level and never reach any folder. This is what Google, Microsoft, and financial institutions use for their primary domains.

You're ready for p=reject when:

Your DMARC aggregate reports (rua=) show 95%+ of mail passing alignment consistently for 2–4 weeks
All your legitimate sending sources are either in SPF or signing with DKIM
You've identified and handled any forwarding scenarios (mailing lists, auto-forwarders)
You're monitoring reports and have an alert if pass rates drop

The safe migration path: none → quarantine → reject

Step 1: Start with p=none and collect reports

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Run this for 2 weeks minimum. Use a DMARC reporting tool (or check the raw XML yourself) to identify every sending source: your email provider, marketing platform, CRM, ticketing system, calendar invites, etc.

Step 2: Fix all sending sources

For each legitimate sender you find in the reports:

Add their sending IPs/includes to your SPF record
Or enable DKIM signing in their platform and add their DKIM public key to your DNS
Verify alignment — the From: domain must match either SPF or DKIM domain

Step 3: Move to p=quarantine at pct=10

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]

The pct= tag applies the policy to only that percentage of failing messages. Starting at 10% and ramping up weekly (25 → 50 → 75 → 100) limits blast radius if you've missed a sending source.

Step 4: Move to p=reject

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Once you've been at p=quarantine; pct=100 for a week with no legitimate mail dropping, flip to reject. Keep monitoring reports — especially after adding new sending tools.

Tip: Set a calendar reminder to review DMARC reports quarterly. Adding a new marketing platform or switching email providers are common causes of DMARC pass rate drops that go unnoticed for months.

Common mistakes

SPF record with too many DNS lookups

SPF is limited to 10 DNS lookups. If you include too many third-party senders, SPF evaluation fails with a "permerror" — which counts as an SPF fail for DMARC. Use a service that flattens your SPF record or audit it with dig TXT yourdomain.com and count the includes.

Relaxed vs strict alignment

DMARC default alignment is "relaxed" — the SPF/DKIM domain just needs to share an organizational domain with the From: header. Strict alignment (aspf=s; adkim=s) requires an exact match. Most domains should stay on relaxed; strict alignment breaks legitimate subdomains unless they're all explicitly configured.

Forgetting subdomain policy

Your DMARC policy covers your exact domain and its subdomains by default. But you can set a separate policy for subdomains with the sp= tag. If you only send mail from the root domain, consider sp=reject even if you're still ramping up the main policy.

How to check your current DMARC status

Run this in your terminal to see your current record:

dig TXT _dmarc.yourdomain.com

Or use EdgeIQ Inbox Shield — it grades your SPF, DKIM, and DMARC configuration, shows your policy strength, and alerts you if your configuration weakens after a DNS change.

📬 Get weekly email security alerts

EdgeIQ monitors your SPF, DKIM, and DMARC every week and alerts you if anything degrades. Catch policy regressions before attackers exploit them.

✅ You're in. Check your inbox.

Monitor your DMARC policy automatically

Inbox Shield grades your SPF, DKIM, and DMARC every week and emails you an alert if your policy weakens or a misconfiguration appears. Catch regressions before attackers exploit them.

Check Your Email Security →

Free to start · no credit card