From p=none to p=reject without bouncing your own customers: the staged DMARC rollout
First published 20 October 2026 · Rollout steps and timelines below are the vendors' own — Microsoft Learn and Google Workspace guidance, cited at each stage.
p=none Watching is not protecting
At p=none, anyone can still send as your domain — you just get reports about it. The protection starts at quarantine and completes at reject. This guide climbs there without taking your own mail down on the way.
p=none: spoofing still deliveredp=reject: spoofing refused
The fast answer
Three stages, with a gate before each move — never skip a gate:
Stage 1 — Monitor:p=none with aggregate reports (rua) flowing to a tool that reads them. Gate: a full reporting period where every real sender passes aligned SPF or DKIM.
Stage 2 — Quarantine, ramped:p=quarantine with pct= climbing 10 → 25 → 50 → 75 → 100 (Microsoft's documented ladder). Gate at each step: reports still clean.
Stage 3 — Reject:p=reject; pct=100, subdomains first, your main domain last.
If a sender surfaces mid-climb, you stop, authenticate it, and resume. That pause is the system working — it is exactly what the reports are for.
The rollout is a staircase, not a switch. Each stage has a gate, and the gate is read from your own reports.
One spec update to know about (2026): the current DMARC specification, RFC 9989, retires the pct tag in favour of a testing flag (t=y) and adds an np policy for non-existent subdomains (our subdomain guide covers it). The rollout in this article stays valid: pct records remain legal and are what today's major receivers and vendor ladders still operate on, and enforcement itself is unchanged. Treat pct as current practice on a spec that has begun moving — if a checker ever flags it as legacy, that is the transition arriving, not an error in your record.
Before Stage 1: the preconditions both vendors state
SPF and DKIM already running. Google's guidance: let SPF and DKIM authenticate your mail for at least 48 hours before DMARC enters the picture — DMARC judges the other two; it cannot replace them.
A mailbox or tool ready to receive reports. Aggregate reports are daily XML files. Set up the reader first (options below), or the reports pile up unread — the single most common reason rollouts stall at p=none forever.
Reports go toA mailbox or tool you have already set up to read them
Save
Do this: publish exactly this shape to start. The rua address is where your sender inventory will arrive — point it at the reader you chose below, not at an inbox nobody opens. Field map drawn by Merroway.
Stage 1 — Read the reports like an inventory
An aggregate report tells you, per sending source: the IP, the message count, the disposition applied, and — the field that matters — policy_evaluated: whether SPF and DKIM aligned, not merely passed. Microsoft's own interpretation guidance names the pattern to hunt: a source can show authentication pass with alignment fail — that sender is authorised but misconfigured, and it will break at reject. Your Stage 1 job is a complete sender inventory: every invoicing tool, shop, helpdesk, copier/scanner, website form and marketing platform that sends as you, each one passing aligned — or fixed until it does.
What one report row tells you — sample excerpt, drawn by Merroway (your tool will lay this out its own way)
Source203.0.113.87 · 1,240 messages · your billing platform's range
SPFpass — aligned
DKIMpass — aligned
Dispositionnone — delivered, as p=none instructs
The dangerous rowSPF pass but alignment fail — authorised, misconfigured, and the first thing that breaks at reject
Do this: inventory every source row like this until each one shows aligned passes — or is identified as not yours at all (that is what enforcement will stop).
Report reading option
Cost
Honest note
Cloudflare DMARC Management
Free, all plans
Only if your DNS is on Cloudflare — then it is the obvious first choice.
Postmark weekly DMARC digests
Free
Email-based digest for one domain; light, but enough to run Stage 1 for a small business.
Valimail Monitor
Free tier per vendor
Monitoring-focused; check current terms at signup.
dmarcian
Paid tiers from ~$24/mo (checked Oct 2026)
The deep tool: full source forensics when a mystery sender appears.
Report mechanics and field meanings: RFC 7489 §7.2 and Microsoft Learn's DMARC report interpretation guidance. Two honesty notes the other guides skip: report coverage is not total — Microsoft puts receiver coverage around 70–90% — and Microsoft 365 only sends aggregate reports when your MX points directly at it, and never sends forensic (ruf) reports; Gmail does not support ruf either. Plan around aggregate data.
Stage 2 — Quarantine, with the pct ramp
When a full reporting period is clean, raise the policy — and use the percentage tag as the dimmer it was designed to be:
Do this: climb exactly this ladder (it is Microsoft's documented sequence). The percentage is a dimmer on failing mail only — your passing mail is never sampled, at any step.
Stage 2, first step
Climb Microsoft's documented steps: pct 10 → 25 → 50 → 75 → 100, pausing at each to watch reports and your own inbox for fallout.
Do subdomains before the parent, lowest-volume first. A subdomain's own record overrides the parent for that subdomain — use that to de-risk the noisy senders.
Know the edge case before you need it: mail outside the sampled percentage under a stricter policy is treated as the next policy down — under p=reject; pct=50, the unsampled half is quarantined, not waved through. pct never applies to reports themselves.
KeepThe rua reporting address — reports matter more at reject, not less
Save
Do this: change only the p= value from the last ramp step. Same record, same reports, stricter instruction. Field map drawn by Merroway.
Keep the defaults working for you: leave adkim and aspf absent (relaxed alignment) unless you have a specific reason — strict SPF alignment (aspf=s) is a documented breaker of legitimate subdomain senders. And keep the reports flowing after you arrive: p=reject is a posture you maintain, not a trophy you shelve. New tool, new sender, new report line — the inventory habit is permanent.
The safety valve if a subdomain is not ready: the parent record's sp tag sets the policy subdomains inherit. If one subdomain still has a sender you cannot fix yet, publish the parent's climb with sp=none (or sp=quarantine while the parent sits at reject) so that subdomain stays monitored instead of enforced — then remove the softer sp once its own senders pass. It is a deliberate, visible exception in the record, not a silent hole: anyone reading your record can see it, including you in six months, so treat it as a loan with a repayment date.
Domains that send nothing skip the staircase. A parked or purely defensive domain goes straight to v=DMARC1; p=reject; with SPF v=spf1 -all — Microsoft's documented setup. There is no legitimate mail to protect, so there is nothing to stage.
If something breaks mid-climb: the step-back
No vendor publishes an official rollback procedure — this one is the ladder run in reverse, and we label it as practice, not documentation: drop one stage (reject → quarantine, or lower pct), find the sender the reports just revealed, authenticate it properly, then climb again. What you must not do is panic-delete the DMARC record: at that moment your domain loses both its protection and its reporting, and (as our 550 fix shows) some receivers require a DMARC record to exist at all.
The cost of a missed sender is real. Under an enforced policy, mail that fails DMARC from your own Microsoft 365 can be routed through the high-risk delivery pool even when delivered — Microsoft states there is no override for that behaviour. This is why Stage 1 exists. The reports are not paperwork; they are the map of everything that would have broken.
Prove you arrived
Your record reads p=reject; pct=100 at the parent, with reports still arriving.
Send tests from every inventoried sender; headers show dmarc=pass with alignment on your domain.
A spoof test — a message forged from an external service claiming your From domain — is rejected or quarantined by a major receiver. That refusal is the product you bought with the whole climb.
Do this: the spoof test is the receipt for the whole rollout — a forged message claiming your From domain is now refused (action=reject), not delivered, not filed to spam. If your test spoof still arrives, enforcement has not actually landed at that receiver yet. Sample values.
FAQ — the issues behind this rollout, answered
How long at p=none? I keep reading 2–4 weeks.
That figure is third-party folklore. Google's documented guidance is that one week at p=none is usually enough for reports to represent all your mail streams, and Microsoft publishes no fixed duration at all. The honest gate is completeness of the inventory, not a calendar number.
Can I jump straight to p=reject if my SPF and DKIM pass?
Your own mail passing is necessary, not sufficient. The jump is what bounces the payroll tool, the shop platform or the scanner nobody remembered. One clean reporting period is the price of certainty — pay it.
Do I need forensic (ruf) reports too?
Mostly you cannot have them: Microsoft never sends them and Gmail does not support the tag. Aggregate reports are the working tool for this rollout, and they are sufficient.
Sources
Microsoft Learn — Set up DMARC in Microsoft 365 (pct ladder, subdomain order, parked domains, high-risk pool) · Google Workspace Admin Help — Set up DMARC and rollout guidance (48-hour precondition, one-week monitoring) · RFC 7489 §§6.6, 7.2 (pct semantics, sp, aggregate report contents) · Tool pricing checked on vendor pages, October 2026. · Method cross-check (sp safety valve): Growtoro DMARC enforcement guide.
Verification note: vendor numbers on this page (the pct steps, the 48-hour precondition, the one-week guidance) are quoted from the official pages above; the step-back procedure is labelled practice, not vendor documentation, because no vendor publishes one.
Did this guide work for you?
Your reaction tells us whether this guide solved the problem it promised to solve.