DMARC rollout: from p=none to p=reject without breaking mail

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

• `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

An evidence-led rollout

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.

Quarantine vs reject: when to graduate

After quarantine, some domains face a choice: stay there or consider reject. RFC 9989 says general-purpose email domains should not deploy reject without weighing mailing-list and forwarding interoperability. Non-sending and tightly controlled domains have a clearer path; every domain still needs evidence that legitimate mail will not be lost.

One nuance on quarantine: most major receivers honor it, but some smaller hosts treat it as tag-and-deliver to the inbox. Reject is honored more uniformly because the action is unambiguous — which is exactly why it belongs at the end of the rollout, not the start.

The graduation gate

Read your last 30 days of aggregate reports. For every source that sent mail with your From domain, ask: is this expected, and does SPF or DKIM align? Move from quarantine to reject only when the answer is yes for effectively all of your volume, sustained across multiple stable reporting cycles. If unexpected sources are still showing up, attribute and fix them first — the guide to unknown senders in aggregate reports walks through that process.

When to stay at quarantine

• You carry mailing-list traffic — forwards break SPF and often DKIM, so reject would bounce real conversations.
• Third-party billing or CRM senders are not authenticated yet.
• Reports still show unexplained sources you cannot attribute to an owner.
• Reporting has only been clean for one cycle — give it more time at p=quarantine before concluding.

Two things hold at every stage. Keep the rua= address published even at p=reject, because new senders pop up forever. And set sp=reject for unused subdomains early — spammers love subdomains that have no explicit policy, and you can run p=quarantine on the org domain while subdomains are already at reject. DMARC monitoring keeps the source inventory labeled so the next policy decision is evidence-based too.

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.