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.
If you want the broader auth map before changing policy, start with the email authentication hub and then come back to the rollout steps below.
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. Use the free DMARC checker to confirm the published policy before changing enforcement.
The starting record
| Host | Type | Value | TTL |
|---|---|---|---|
| _dmarc.example.com | TXT | v=DMARC1; p=none; rua=aggregate-report-mailbox; ruf=forensic-report-mailbox; 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 | Report mailbox URI | Aggregate report destination |
ruf | Forensic mailbox 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=aggregate-report-mailbox - 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=aggregate-report-mailbox
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
DMARC rollout timeline
- 01
Publish reporting first
Start with p=none and rua reporting so aggregate reports expose real senders without asking receivers to quarantine or reject failures.
- 02
Label every legitimate source
Record the owner, sending stream, ESP, SPF domain, DKIM domain, and expected volume before changing policy.
- 03
Fix alignment gaps
Use aligned SPF or aligned DKIM for each important sender. Raw SPF or DKIM pass is not enough when the authenticated domain does not match the visible From domain.
- 04
Move enforcement gradually
Use quarantine before reject when evidence is still stabilizing, and keep rollback instructions ready for critical product mail.
| Stage | Evidence required | WillItInbox page |
|---|---|---|
| p=none | RUA reports arriving and parsed | /docs/dmarc-monitoring |
| quarantine | Legitimate high-volume senders aligned | /tools/dmarc-monitoring |
| reject | Unknown sender volume explained or intentionally blocked | /blog/dmarc-aggregate-reports-unknown-senders |
Use the DMARC checker for publication, SPF checker for sender authorization, and DMARC monitoring for real sender inventory before changing policy.
Continue this dmarc monitoring and sender authentication workflow with the commercial page, the core guide, the implementation docs.
Sources reviewed
- RFC 7208: Sender Policy Framework(standard)
- RFC 7489: DMARC(standard)
Factual review: June 13, 2026 by WillItInbox Editorial.
Keep reading