DMARC · Rollout · Policy
From p=none to p=reject without bouncing your own customers: the staged DMARC rollout
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.
The fast answer
Three stages, with a gate before each move — never skip a gate:
- Stage 1 — Monitor:
p=nonewith 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=quarantinewithpct=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.
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=noneforever. - Your DMARC record, monitoring form:
v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@yourdomainStage 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.
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 | 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:
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain- 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.pctnever applies to reports themselves.
Stage 3 — Reject, main domain last
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@yourdomainadkim 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.
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.
Prove you arrived
- Your record reads
p=reject; pct=100at the parent, with reports still arriving. - Send tests from every inventoried sender; headers show
dmarc=passwith 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.
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.
Did this guide work for you?
Your reaction tells us whether this guide solved the problem it promised to solve.