Skip to main content
Migration

p=none Escape Plan — 4-Week DMARC Migration Wizard

Stuck at p=none? Enter your domain to get a personalised four-week plan that walks you from monitoring to p=quarantine to p=reject — with the exact DNS record at every step and the criteria for advancing.

Why p=none is not protection

A DMARC record at p=none is a paperwork control. It ticks the compliance box on Microsoft, Google, and Yahoo bulk-sender requirements; it gives auditors a record to point at; it does not stop anyone from spoofing your domain. The whole reason DMARC exists is the policy verb in p= — quarantine and reject are the only values that tell receivers to do something with failing mail. Validate the current record on the DMARC Record Checker before you start; once the migration is underway, use the DMARC Report Analyzer to watch the aggregate reports at each step.

Industry-wide telemetry shows roughly half of all domains that adopted DMARC after the Feb 2024 Google/Yahoo enforcement are still stuck at p=none. The 27 Nov 2025 Gmail escalation — moving repeat-offender bulk senders to permanent rejection regardless of policy — narrowed the safety margin further. The wizard above turns the move from monitoring to enforcement into a four-week checklist instead of a wing-and-prayer flip.

How the plan is built

The tool scans your domain's current DMARC and SPF posture client-side via Cloudflare DoH, derives the starting state (missing record / p=none / p=quarantine / p=reject), and renders the migration timeline from that point forward. Each step lists:

  • The goal for the step — what state your DMARC ends in by the end of the dwell time.
  • The exact DNS record to publish, with your domain pre-filled, ready to paste into your DNS provider.
  • Monitoring & actions — what to watch in your aggregate (rua) reports and what to fix before advancing.
  • Advance criteria — the measurable signal that says the step is done and you can move to the next one.

Why the dwell times matter

The most common reason a p=none-to-p=reject migration fails is moving too fast. The dwell times in this plan exist because aggregate reports arrive on a daily cadence — you need at least one full reporting cycle at each enforcement level before you can confidently say "no critical sender is being blocked." Most of the famous "DMARC blocked all our invoices" stories trace back to a 24-hour transition that did not give the reports time to surface the failing sender.

When to bend the plan

The four-week timeline assumes a domain with 1-5 sending sources and someone watching the reports. Slow down if your domain has 30+ sources or your aggregate reports show drift week-over-week. Speed up only if you have battle-tested DMARC monitoring already in place and complete coverage of every authorised sender. The pct= ramp in Week 3 exists specifically to dial the risk before going to full enforcement — never skip it.

What this tool does not replace

Reading the aggregate reports is the entire job during the migration. This tool gives you the plan and the DNS records; the DMARC Report Analyzer turns the daily XML into a sender-by-sender view you can act on. If you want the reports to ingest automatically with alerts on alignment drift, that is what the paid tier does.

Get the full picture with DMARCguard

Continuous monitoring, aggregate report parsing, and actionable insights for all your email authentication protocols.

Start Free