Moving DMARC from p=none to p=reject — the Safe Migration Path

Publishing a DMARC policy at p=none is the right first move — and the wrong place to stop. A DMARC policy of p=none tells receiving servers to authenticate your mail, send you reports, and then deliver forgeries anyway. The protection you set out to get only exists at p=reject. The problem is that jumping straight there is how teams send their own invoices and password resets to spam, so most domains freeze at p=none forever and stay spoofable.

This is the migration path that gets you to p=reject without breaking legitimate mail: monitor, inventory your senders, ramp enforcement with pct=, and know in advance what forwarders and mailing lists will do to you.

What p=none does — and what it doesn't

p=none is monitoring mode. It buys you visibility (aggregate reports) and costs you nothing, which is exactly why it's the correct first step and a useless final one. An attacker sending billing@yourdomain.com under p=none fails authentication and gets delivered anyway. If the words SPF, DKIM or alignment are fuzzy, read our SPF, DKIM and DMARC explainer first — this post assumes the basics.

One prerequisite before anything else: your legitimate mail must already pass SPF or DKIM with alignment — the authenticated domain must match your visible From domain. If your own mail can't pass, enforcement will punish you before it punishes attackers.

Phase 1: publish p=none with reporting turned on

Publish this TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

The rua= tag is the whole point of this phase — without it you're learning nothing. Receivers (Google, Microsoft, Yahoo and others) will start sending daily aggregate reports: gzipped XML files summarising every source that sent mail claiming to be your domain, and whether it passed. One note: if you point rua= at a mailbox on a different domain, that domain must publish a small authorization record before receivers will send reports there.

Let reports accumulate for two to four weeks minimum. Mail sources are bursty — your invoicing tool might only send on the 1st of the month, and you want a full cycle in the data.

Phase 2: inventory every legitimate sender

The reports will surprise you. Almost every team finds senders they forgot: the CRM, the marketing platform, the support desk, the CI system that emails failure notices, a scan-to-email printer, a WordPress plugin on a marketing site. Sort every source in the reports into four buckets:

1. Your own infrastructure — mail servers, app servers sending transactional mail.
2. Third-party services sending as you — for each one, add it to SPF and/or enable DKIM signing with your domain, per that provider's docs. DKIM is the better fix where offered (it survives forwarding; SPF doesn't).
3. Forwarders — legitimate mail you sent that was relayed onward (more on these below).
4. Everything else — this is the spoofing you're about to shut down. Don't fix it; enjoy watching it die.

Keep iterating until your aggregate reports show your legitimate sources passing DMARC at effectively 100%. If SPF failures show permerror rather than fail, your SPF record itself is probably broken — often the 10-DNS-lookup limit — and needs repair before you enforce anything.

Phase 3: quarantine, ramped with pct=

Now turn enforcement on gradually. p=quarantine sends failing mail to spam instead of rejecting it outright — recoverable if you missed a sender — and the pct= tag applies the policy to only a percentage of failing mail:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com

Hold each step for one to two weeks while watching the reports, then ramp: pct=10 → pct=25 → pct=50 → pct=100 (which is the default when pct= is omitted). If a legitimate source starts failing at pct=10, only a tenth of its mail is affected while you fix it.

Two things people get wrong here. First, pct= has no effect at p=none — there's no policy to apply a percentage of. Second, ramping is not a substitute for Phase 2: pct=10 still junks one in ten messages from any sender you missed.

What breaks: forwarders and mailing lists

Two categories of legitimate mail fail DMARC by design, and you should expect them in your reports rather than panic:

• Forwarders. When someone auto-forwards their mailbox (an alumni address, a role account relaying to Gmail), the forwarding server re-sends your message from its own IP — so SPF fails. DKIM survives forwarding as long as the message body isn't modified, which is precisely why you want DKIM on every legitimate source before enforcing. Well-behaved forwarders that rewrite the envelope sender (SRS) don't help DMARC either, because the rewritten domain no longer aligns with yours — DKIM is your safety net.
• Mailing lists. Lists commonly modify messages — a subject-line tag, a footer — which breaks DKIM, and they resend from their own servers, which breaks SPF. Modern list software copes by rewriting the From address for domains with an enforcing policy, so your users' posts appear as user=yourdomain.com@list.example. Ugly, but functional. Receivers may also use ARC to recover authentication results across forwarding hops, but that's their call, not something you can configure.

Neither of these should stop you. They're a small, identifiable slice of traffic, and the trade — a mangled From header on mailing lists versus an unspoofable domain — is one every security team takes.

Phase 4: reject

Once quarantine has run clean at pct=100 for a couple of weeks, finish the job:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; sp=reject

The sp= tag applies the policy to subdomains explicitly — attackers who can't spoof yourdomain.com will happily try mail.yourdomain.com. (Subdomains inherit p= by default, but being explicit prevents a later "temporary" subdomain carve-out from silently weakening you.)

Keep rua= reporting on permanently. It's how you'll notice the next new SaaS tool sending as you before its mail gets rejected.

Timeline expectations

For a small organisation with a handful of senders: roughly 6–10 weeks end to end — 2–4 weeks monitoring, 2–4 weeks fixing senders and ramping quarantine, 2 weeks proving it clean before reject. Larger organisations with dozens of sending services should budget 3–6 months. What the timeline is not is an afternoon: every DMARC horror story starts with someone publishing p=reject on day one.

Don't let it drift back

The quiet failure mode after all this work: someone drops the policy back to p=none during an incident "just for now", or a new tool starts sending unauthenticated and nobody notices until customers complain. CompleteStatus monitors your SPF, DKIM and DMARC records continuously — it flags p=none, alerts on record changes, and watches the rest of your stack (uptime, SSL, DNS, security headers) from the same dashboard.

Check where your domain stands right now with the free DMARC / SPF / DKIM checker, then start monitoring free so a weakened policy pages you, not a phishing victim. The free tier allows commercial use.