Guide

How to Move from DMARC p=none to p=reject Safely

Moving from p=none to p=reject takes 4-8 weeks if you do it right. Rush it and you block legitimate email. Skip it and your domain stays unprotected indefinitely. Here's the exact sequence.

Updated April 1, 2026

You already have a TXT on _dmarc. The question is whether you'll ever leave p=none. This roadmap pairs with the full DMARC guide, policy stages, and DMARC Report Analyzer. Check live DNS anytime on domainpreflight.dev.

Why Most Domains Never Leave p=none

The data is clear — roughly 40% of domains with DMARC are still at p=none. Most were set up under deadline pressure and never upgraded.

The reason is always the same: no clear next step. The record is live, the green tick is showing, and nothing is visibly broken. So nothing changes.

This page is the next step. Read why p=none still leaves you exposed.

The Complete Roadmap

Stage 1 — Monitoring (Week 1-2)

Goal: collect reports, identify all senders.

Stage 2 — Fix Alignment (Week 2-4)

Fix every failing sender in your reports. Use DomainPreflight DMARC Report Analyzer. See alignment and aggregate reports.

Stage 3 — Partial Enforcement (Week 4-5)

Goal: test enforcement on 10% of mail.

Stage 4 — Full Quarantine (Week 5-6)

Goal: all failing mail goes to spam.

Stage 5 — Full Enforcement (Week 6-8)

Goal: all failing mail blocked. DMARC policy reference.

The Checklist — Before Each Stage

Before moving to p=quarantine:

• □ At least 2 weeks of p=none reports collected
• □ All legitimate senders identified
• □ No unexplained IPs in reports
• □ SPF alignment passing for all senders
• □ DKIM alignment passing for all senders
• □ Aggregate reports showing 95%+ pass rate

Before moving to p=reject:

• □ At least 1 week at p=quarantine
• □ No legitimate email in spam folder
• □ DMARC reports showing 99%+ pass rate
• □ All third-party senders verified aligned
• □ rua= email being monitored regularly

How to Read Your Reports

Paste your DMARC XML into DomainPreflight DMARC Report Analyzer.

Green rows = aligned, passing.

Orange rows = partial failure — fix before proceeding.

Red rows = both fail — investigate before proceeding.

If you see red rows from IPs you don't recognise — that's spoofing. That's exactly what p=reject will stop.

Fixing Alignment Failures

Most failures come from third-party senders using their own domain for Return-Path or DKIM.

Fix by provider:

• SendGrid → 3 CNAME records in Sender Auth — SendGrid DMARC fix
• Mailchimp → domain verification + DKIM CNAMEs — Mailchimp
• Microsoft 365 → selector1/selector2 CNAMEs — Microsoft 365
• Google Workspace → google._domainkey TXT — Google Workspace

See the DMARC provider fix guides for exact steps per provider.

After p=reject — What Changes

Spoofed emails from your domain are blocked before they reach inboxes. Legitimate email from aligned senders is completely unaffected.

You'll continue receiving aggregate reports. Check them monthly to catch any new senders that need alignment.

Step by step