Skip to main content
How-to DMARC

The DMARC rollout playbook

How to safely move from p=none to p=reject without breaking real mail. The 6-12 week ramp every domain should follow.

~3 weeks elapsed · 30 min work

TL;DR

  • 1Stay at p=none for 14 days, collect rua reports, identify every legitimate sender before escalating.
  • 2Move to p=quarantine, optionally publishing it in test mode first (t=y) so receivers report on the new policy without enforcing it, then drop t=y to enforce. Watch for support tickets about spam-foldered mail.
  • 3Promote to p=reject only when every legitimate sender you've identified is aligned and passing (about 98% of known-sender mail) for two consecutive weeks, with only unknown or spoofed sources still failing.

Why a phased rollout

DMARC enforcement is a one-way ratchet. Once you publish p=reject and a major receiver caches it, every misconfigured sender immediately bounces. The phased rollout protects you from your own ESPs, CRMs, and shadow IT.

The phases use two weeks of p=none reports to discover every legitimate sender, then escalate only after you've fixed alignment for each one. Skipping the phases and going straight to p=reject is how operators end up paging on Sunday because the marketing platform stopped delivering.

Right discipline is data-driven: never escalate without aggregate reports backing the decision. The numbers will surface senders you forgot about: calendar invites from a long-departed admin's personal Gmail, a legacy CRM sending from a static IP no one re-pointed.

The 4-phase ramp

  1. 1

    Phase 1 (week 0-2): Monitor at p=none. Publish DMARC with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1. Watch the rua reports daily. List every source IP and the org it claims to belong to.

  2. 2

    Phase 2 (week 2-4): Fix the alignment gaps. For each ESP failing alignment, switch it to CNAME-delegated DKIM so it signs with your d=. Add any missing senders to SPF (mind the 10-lookup limit). Target: every known sender aligned (about 95% of known-sender mail passing) sustained for 7 days.

  3. 3

    Phase 3 (week 4-8): Escalate to p=quarantine. Optionally publish it in test mode first as p=quarantine; t=y for 7 days: receivers report on the stricter policy but still deliver normally, so you get a dry run with no risk. When reports look clean, drop t=y to start enforcing, then watch for spam-folder reports for another 7 days before escalating.

  4. 4

    Phase 4 (week 8-12): Move to p=reject. Every legitimate sender you've identified must be aligned (about 98% of known-sender mail passing) for two consecutive weeks, with only unknown or spoofed sources failing, before this step. After publish, keep watching rua reports indefinitely: new ESPs get added, sender IPs change, DKIM keys rotate.

Common pitfalls

  • Jumping from p=none directly to p=reject. Guarantees bouncing real mail. Receivers cache the policy aggressively; rolling back takes 24-48 hours during which more mail bounces.

  • Leaving t=y on and thinking you're enforcing. Test mode makes receivers apply the next-lower policy, so a domain stuck at p=reject; t=y is only quarantining, not rejecting. Remove t=y (or set t=n) once reports are clean. Note: the old pct tag was removed in DMARCbis, so don't reach for it to ramp gradually.

  • Not monitoring after p=reject. You still need ongoing rua reports. A new ESP gets added in marketing, a sender IP rotates, a DKIM key expires; any of those creates new fails that you'll only catch with continuous monitoring.

  • Forgetting subdomains. Without an sp= tag, subdomains inherit the parent policy. Sometimes that's wrong: a transactional subdomain genuinely sends from many places and needs a separate policy at _dmarc.transactional.yourdomain.

  • No coordination with bulk-mail dependencies. If marketing is mid-campaign and you flip to p=reject, every misaligned message bounces. Schedule the final escalation outside major send windows.