DMARC rollout: from p=none to p=reject without breaking mail
The exact six-week schedule for moving from monitoring-only DMARC to full enforcement, with the report-reading checkpoints that keep you safe.
DMARC enforcement is the single most consequential email change you'll ever make. Done right, you eliminate domain spoofing forever. Done wrong, you reject your own legitimate mail. The difference is entirely about how patient you are with the rollout.
What DMARC actually does
DMARC sits on top of SPF and DKIM. It does two things: tells receivers what to do when authentication fails, and asks them to send aggregate reports. Crucially, DMARC requires that the From-header domain align with either the SPF authenticated domain or the DKIM signing domain. Either passing is enough.
The starting record
| Host | Type | Value | TTL |
|---|---|---|---|
| _dmarc.example.com | TXT | v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r | 3600 |
- `p=none` — monitoring only. Receivers report failures but don't act on them.
- `rua=` — aggregate report destination. Daily summaries from each receiver.
- `ruf=` — forensic report destination. Per-message failure details (most receivers no longer send these for privacy reasons).
- `fo=1` — forensic on any failure (vs default
0, which only reports if everything fails). - `adkim=r` / `aspf=r` — relaxed alignment. Subdomains of the From domain count as aligned.
Tag reference
| Tag | Values | What it does |
|---|---|---|
v | DMARC1 | Required version tag |
p | none / quarantine / reject | Policy for the main domain |
sp | Same as p | Policy for subdomains (defaults to p) |
rua | mailto: URI | Aggregate report destination |
ruf | mailto: URI | Forensic report destination |
pct | 0–100 | Percent of failing mail to apply policy to |
adkim | r (relaxed) / s (strict) | DKIM alignment mode |
aspf | r / s | SPF alignment mode |
fo | 0 1 d s | Forensic reporting trigger |
The six-week rollout
From monitoring to enforcement
- 01
Week 1 — Publish p=none
Set up an inbox or DMARC report processor (free options: dmarcian, EasyDMARC, Postmark DMARC Digests). Publish the monitoring record. Verify with
dig +short txt _dmarc.example.com. - 02
Week 2 — Read the reports
Aggregate reports arrive daily. You'll discover senders you didn't know existed: SaaS tools, marketing automation, that one Cron job from 2019. Make a list. For each, decide: legitimate (fix auth), illegitimate (block at source), or shadow IT (have a conversation).
- 03
Weeks 3–4 — Fix every legitimate sender
Add their IPs to SPF or get them DKIM-signing. Verify each fix in the next week's reports. Do not move forward until every legitimate sender is producing aligned passes.
- 04
Week 5 — Move to quarantine with pct=10
Change to
p=quarantine; pct=10. Only 10% of failing mail will be quarantined; the rest passes through with anoneaction. Watch reports for any dropped legitimate sender.v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected] - 05
Week 6 — Ramp pct to 100
If reports look clean, raise
pct=to 25, then 50, then 100, in 3-day intervals. After a week atpct=100; p=quarantine, you can move top=rejectfor full enforcement.v=DMARC1; p=reject; rua=mailto:[email protected]
Reading aggregate reports
Aggregate reports are gzipped XML files emailed daily by each receiver. Manually reading XML is masochism — use a processor. The data you care about: which IPs are sending as your domain, what their auth result was, and whether they're aligned.
| Result | What it means | Action |
|---|---|---|
| SPF pass + aligned, DKIM pass + aligned | Healthy sender | None |
| SPF fail, DKIM pass + aligned | Forwarded mail | Usually fine; DKIM survives forwarding |
| SPF pass but unaligned | Sender uses your IP but their own domain | Fix their config or remove from SPF |
| Both fail | Either spoof or misconfigured legitimate sender | Investigate immediately |
Frequently asked questions
Keep reading