DMARC p=none vs p=quarantine vs p=reject explained

The three DMARC policies, what each one tells receiving servers to do, and the safe migration path from p=none to p=reject without breaking legitimate mail.

DMARC has exactly three policies: none, quarantine, reject. They tell receiving mail servers what to do with messages that fail authentication. The confusion is that "failing authentication" doesn't always mean "this is spam" - which is why you can't just jump to reject on day one.

What each policy actually does

• p=none - monitor mode. The receiving server does nothing. You get aggregate reports via rua showing who's sending on your behalf. This is where every domain starts.
• p=quarantine - failing messages go to spam/junk. Recipients still see them if they go looking, but default inbox placement is denied.
• p=reject - failing messages are bounced at the SMTP layer. The sender gets a rejection; the recipient never sees anything. This is the real anti-spoofing policy.

Use the DMARC Checker to see which mode your domain is currently in.

Why you can't skip straight to p=reject

Real-world mail flows are messier than the spec. Your domain likely sends through services you've forgotten about - Mailchimp, Intercom, Stripe invoices, Zendesk, a Zapier workflow from 2021. If any of them isn't properly SPF-aligned or DKIM-signed for your domain, p=reject will blackhole those emails.

You also need to account for mailing-list forwarding (which breaks SPF) and simple misconfigurations (CNAME'd selectors that were never verified).

The safe migration path

1. Month 1 - p=none, pct=100, with rua pointing at a DMARC aggregator (Postmark, Valimail, Dmarcian, or your own bucket). Collect a full cycle of monthly reports.
2. Month 2-3 - fix alignment. Work through the rua reports. Every legitimate sending source needs either SPF alignment (Return-Path domain matches From domain) or DKIM alignment (d= matches From). Add missing SPF includes, set up DKIM CNAMEs for third-party senders.
3. Month 4 - p=quarantine pct=10. Now you're applying the policy to 10% of traffic. Watch for complaints. Bump pct up every week: 10 → 25 → 50 → 100.
4. Month 5+ - p=reject. When quarantine at pct=100 has been quiet for a few weeks, you can upgrade. This is the destination.

Gotchas people hit

• Subdomain policy (sp=): if you don't set it, subdomains inherit the parent's p=. If a subdomain sends different mail, set sp= explicitly.
• Missing rua: a DMARC record without aggregate reporting addresses is useless. You can't fix what you can't see.
• Invalid rua addresses: the receiving domain has to authorize you to send reports to it - cross-domain reporting requires a TXT record at yourdomain._report._dmarc.reportingdomain.com. Most aggregators set that up for you.
• Relaxed vs strict alignment (aspf=, adkim=): leave on default (relaxed) unless you truly need exact domain match. Strict alignment breaks more than it protects.

Run the DMARC Checker on your domain now to see the current policy and a plain-English reading of every tag.

What a properly-configured DMARC domain looks like

If you want a reference point for a strict DMARC setup, look at /d/microsoft.com - p=reject, aggregate reporting in place, and every legitimate sender properly aligned. Then run your own domain from the home page and compare.

Related reading