DNSMentor

Runbooks

Roll DMARC out to p=reject without breaking mail

40 min to do · 2 related

How do I move a client to DMARC p=reject safely?

Publish p=none with an aggregate report address first, read the reports for at least two weeks to find every legitimate sender, fix SPF and DKIM alignment for each one, move to p=quarantine with a low percentage, then to p=reject. Skipping the reporting period is how a finance system stops being delivered.

DMARC is the only one of the three mail records with a switch that can reject real mail. Treated as a checkbox it will, and the mail it rejects is the mail nobody notices until an invoice goes unpaid.

# Phase 1 — observe

  1. Publish p=none with reporting This changes nothing about delivery. It asks receivers to tell you what they are seeing, which is the entire point of the phase.
  2. Send the reports somewhere they will be read Aggregate reports are XML and arrive daily from dozens of receivers. Point rua at a DMARC reporting service or a mailbox somebody has agreed to process. A rua address nobody reads is the most common reason a rollout stalls.
  3. Wait a fortnight Monthly senders exist. A week of reports will miss the payroll run.
Phase 1 record at _dmarc
v=DMARC1; p=none; rua=mailto:dmarc@contoso.co.uk; fo=1

# Phase 2 — fix alignment

The reports will show senders passing SPF or DKIM but failing DMARC. That is an alignment failure: the domain that authenticated is not the domain in the From header. It is the part of DMARC that surprises people.

  • For each legitimate sender, get either SPF or DKIM aligned with the visible From domain. One is enough.
  • Prefer DKIM: it survives forwarding, and SPF does not.
  • Expect to find at least one sender nobody knew about. That conversation is worth having.

# Phase 3 — enforce, gradually

StepRecordHold for
Quarantine a quarterp=quarantine; pct=25One week
Quarantine everythingp=quarantineTwo weeks
Rejectp=rejectPermanent
Do not roll out DMARC in the same change as a mail migration

A cutover week is when your DKIM signing is least consistent and your SPF record is most likely to be missing something. Let the migration settle first.

Was this helpful?

Related

Still stuck?

Raise a ticket from inside the platform and your tenant, plan and recent activity come attached automatically. A client currently offline is treated as urgent on every plan.

Last updated