How to Move from DMARC p=none to p=reject Without Losing Legitimate Emails

Moving from DMARC p=none to p=reject is the most important step in email authentication — but doing it wrong can block legitimate emails. Here is the safe, phased approach.

DMARC policy enforcement is what separates monitoring from protection. A p=none policy tells receivers to monitor but take no action. A p=reject policy tells receivers to block emails that fail authentication — stopping phishing and spoofing attacks at the server level.

Why p=none Is Not Enough

Most ESPs like Mailchimp only require p=none, but p=none provides zero protection. It's observation mode. Spoofers can still send emails pretending to be your domain, and receivers will deliver them. p=none generates reports (rua) that let you see who is sending as you — but it doesn't stop abuse.

The Safe Migration Path

Phase 1: Monitor with p=none (4-6 weeks)

Start with v=DMARC1; p=none; rua=mailto:your@email.com. Analyse aggregate reports to identify all legitimate sending sources. Include third-party services (Mailchimp, Salesforce, Google, etc.).

Phase 2: Authorise All Legitimate Senders

Ensure every legitimate sender has valid SPF and DKIM records. Add missing services to your SPF record or configure DKIM signing for them. Test each source passes DMARC alignment.

Phase 3: Move to p=quarantine (2 weeks)

Tighten policy to p=quarantine. Monitor for false positives. Check if any legitimate emails are being flagged. Fix remaining authentication gaps.

Phase 4: Enforce p=reject

Once you've confirmed no false positives, publish v=DMARC1; p=reject; rua=mailto:your@email.com. Continue monitoring reports to catch any new unauthorised senders.