DMARC Rollout Without Breaking Your Mail

DMARC is the record that tells receiving servers what to do when a message claiming to be from your domain fails authentication. Set it to reject and spoofed mail gets bounced at the door — which is exactly what you want. Set it to reject too early, before you've confirmed every legitimate system that sends as your domain is properly authenticated, and you bounce your own transactional mail at the door too. The difference between those two outcomes is entirely about sequence. This is a staged rollout, and rushing it is how good senders black-hole their own receipts.

DMARC at p=reject protects you from spoofers. DMARC at p=reject published too soon protects you from your own users receiving their password resets.

How DMARC actually decides pass or fail#

Before the rollout, the one mechanic you must internalise: DMARC passes if SPF or DKIM passes and aligns with the visible From: domain. You don't need both to pass — you need at least one aligned. The policy (none/quarantine/reject) only applies to messages where both fail alignment.

That's why alignment, not mere presence, is the thing that breaks rollouts. A message can pass SPF for the sending server's own domain yet fail DMARC because that domain doesn't align with your From: address. Your job during rollout is to make sure every legitimate sender — your app, your provider, your CRM, your helpdesk — produces mail that aligns on SPF or DKIM.

The staged rollout, step by step#

Step 1 — p=none with reporting (visibility, no enforcement)#

Publish a monitoring record and collect aggregate reports. Nothing is blocked; you're mapping reality.

v=DMARC1; p=none; rua=mailto:[email protected]

Leave this in place until the reports show a complete picture of who sends as your domain — commonly a few weeks to around 90 days for a real estate of senders. Use it to find every legitimate source and fix its SPF/DKIM alignment. Do not skip this. It's the only step that's free of risk and the only one that tells you what will break next.

Step 2 — p=quarantine (failing mail to spam)#

Once your legitimate senders are consistently aligning, move to quarantine. Now unauthenticated mail claiming your domain goes to the spam folder rather than the inbox — but a legitimate sender you missed lands in spam too, which is recoverable and visible in reports. Keep watching for newly surfaced senders and fix them.

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Step 3 — p=reject (failing mail rejected outright)#

When reports show all legitimate mail aligning and only unauthorised mail failing, advance to reject. Spoofed mail is now bounced at the SMTP level. Keep monitoring — new vendors, IP changes, and configuration drift can break alignment at any time and silently start rejecting real mail.

v=DMARC1; p=reject; rua=mailto:[email protected]

A whole rollout, done properly, commonly runs several months for a complex estate and can be quicker for a domain with few senders. The pace is set by your reports, not the calendar.

The DMARCbis change you need to know#

For years the standard advice was to ramp enforcement with the pct= tag — apply quarantine to 10% of failing mail, then 25, 50, 100, then repeat for reject. That advice is now out of date.

In May 2026 the IETF published DMARCbis — RFC 9989, 9990 and 9991 — which obsolete RFC 7489. Among the changes: the pct= tag is removed entirely (not merely discouraged), replaced by a testing mechanism (the t= tag), and a new np= tag governs the policy for non-existent subdomains. Existing v=DMARC1 records remain backward compatible, so nothing you've already published breaks — but if you're rolling out today, don't reach for pct=. Stage with the policy tag itself (none → quarantine → reject), lean on your aggregate reports to gate each move, and use the testing tag where you'd previously have sampled with pct.

If a competitor's guide is still telling you to set pct=25, that's your signal it hasn't been updated for the 2026 specification.

Subdomains: where transactional mail often lives#

Many teams send transactional mail from a subdomain (e.g. mail.yourdomain.com or notifications.yourdomain.com) precisely to isolate it — a good practice we cover in when to split sending domains. DMARC handles subdomains with the sp= tag: you can enforce p=reject on the parent while a subdomain runs a different policy during its own rollout, and DMARCbis's np= closes the gap for subdomains that don't exist at all (a common spoofing vector). Roll out the subdomain that carries your transactional mail on its own schedule, gated by its own reports.

Hands-on: read a report, don't just publish a record#

Publishing the record is one line. The work is reading the aggregate reports (XML) to see which sources pass and align. A minimal check with a parser:

# Aggregate reports arrive as gzipped XML at your rua address.
# Inspect which sources are passing DMARC alignment before you advance.
zcat report.xml.gz | xmllint --format - | \
  grep -E "<source_ip>|<count>|<dkim>|<spf>|<disposition>"

You're looking for legitimate sources showing pass on DKIM or SPF alignment. Any legitimate source showing fail is a sender you must fix before you tighten the policy — because the moment you reach reject, that source's mail stops arriving. In practice, most teams use a report-processing service to turn this XML into a readable dashboard; the principle is the same either way: advance only when the report says it's safe.

Example scenario: the reset emails that vanished#

(Illustrative scenario, not a customer case.) A team reads that p=reject is "best practice," publishes it directly with no monitoring phase, and moves on. Their app's password-reset mail is sent from a system that was never added to SPF and isn't DKIM-aligned to the From: domain. Overnight, every reset email fails DMARC and is rejected by receivers — users can't get back into their accounts, and nothing bounces to the app in an obvious way. The record was "correct" in isolation and catastrophic in context. A p=none monitoring phase would have shown that sender failing in the very first reports, weeks before it could hurt anyone.