# DMARC rollout: from p=none to reject

Plan a DMARC rollout from monitoring to reject: inventory senders, inspect SPF and DKIM alignment, review reports and validate each enforcement change.

Canonical: https://tamperbox.dev/guides/dmarc-monitoring-to-reject

Updated: 2026-10-18

Reviewed: 2026-10-17

A DMARC rollout is a sender-inventory and alignment task. A syntactically valid reject policy can still block legitimate mail if those senders are not aligned.

## Start with observation

Use [DMARC Checker](https://tamperbox.dev/dmarc-checker) to inspect the exact published record. Begin with monitoring while collecting and reviewing aggregate reports using a reporting system you control. The checker does not analyze those reports or verify domain existence and external report authorization.

For a synthetic example, a domain sends ordinary mail through one service and invoices through another. Both can pass their own authentication while only one aligns with the visible From domain. Inventory both before changing policy.

## Repair each legitimate sender

Check the envelope-domain authorization with [SPF Checker](https://tamperbox.dev/spf-checker). Read the signing domain and selector in a delivered message, then inspect that key with [DKIM Checker](https://tamperbox.dev/dkim-checker). Compare trusted receiver results in [Email Header Analyzer](https://tamperbox.dev/email-header-analyzer); its exact-domain comparison does not evaluate relaxed alignment.

Do not require every message to pass both SPF and DKIM. DMARC can pass through an aligned successful result from either, under the domain's applicable alignment policy.

## Increase enforcement deliberately

Once reports show legitimate senders aligned, draft quarantine and then reject in the builder. Review the full record and your reporting destination before publishing. Observe receiver outcomes after each change and keep a rollback record. RFC 9989 receivers ignore pct. Use monitoring and review reports before enforcement; t=y requests one level below the declared policy.

## Validate the rollout

Test representative workflows, including forwarded mail and third-party senders. Compare subsequent reports with delivery failures before increasing enforcement. There is no universal number of days that makes a rollout safe.

## Worked example: two senders, one alignment failure

Consider this synthetic monitoring record:

```text
v=DMARC1; p=none; rua=mailto:reports@sender.example
```

Your reporting system shows 1,000 legitimate messages: 800 ordinary messages pass DKIM with `d=sender.example`, while 200 invoices pass SPF and DKIM only for `billing-provider.example`. The invoice messages use `From: accounts@sender.example`, so those 200 have no aligned authentication result. Enforcing now could affect **20% of legitimate messages** in this example.

Configure the invoice service to sign with `d=sender.example`, publish its supplied key under its exact selector, and send fresh tests. Suppose subsequent representative reports show 800 ordinary messages and 200 invoices all passing aligned DKIM. The observed legitimate pass count changes from **800/1,000 to 1,000/1,000**. That supports reviewing enforcement; it does not prove future mail will all pass.

After reviewing forwards and other traffic, a draft can become `v=DMARC1; p=quarantine; rua=mailto:reports@sender.example`, and later `p=reject`. Keep the monitoring record for rollback. The addresses and counts are invented for this worked example; the tool does not collect or analyze these reports.

## Reference

[DMARC policy and alignment, RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) and [aggregate reporting, RFC 9990](https://www.rfc-editor.org/rfc/rfc9990), which obsolete RFC 7489.