Roll out DMARC policy with evidence and a recovery plan

Authentication asks whether a message provides the required evidence for its sending identity. DMARC also checks alignment with the visible From domain. A message can pass through an aligned SPF or DKIM result; a successful check for an unrelated service domain does not establish that alignment.

The domain owner's policy describes its handling preference when DMARC fails. The receiver still makes the delivery decision. Passing authentication is not a guarantee of inbox placement, and a report about a failure is not proof that a legitimate message was lost.

The current standards are RFC 9989 for DMARC, RFC 9990 for aggregate reporting and RFC 9991 for failure reporting, published in May 2026. Treat a rollout as a change to an operating mail system: name the business outcome, the affected identities and the person who can accept the impact. This guide's worksheets are a proposed review method, not an automatic approval rule.

List every From domain and sending stream in scope, including staff systems, invoices, support software, scheduled reports and outreach tools. Ask the owners about occasional and seasonal use. A quiet reporting interval cannot reveal an application that has not sent during that interval.

Record the current DMARC record and where it is published. A subdomain's explicit record and inherited parent policy can produce different boundaries. Microsoft documents separate subdomain records as a way to interrupt inheritance. Review the actual hierarchy with the DNS owner before assuming a change affects only one application.

For each stream, capture its owner, expected volume pattern, From domain, envelope-sender domain, DKIM signing identity and a recent controlled message. Record forwarding and mailing-list paths separately. The aim is to make every legitimate use discoverable and accountable, including the routes nobody remembers until a monthly invoice fails.

Start with a monitoring decision appropriate to the domain, and verify that reports arrive at a monitored destination. Aggregate reporting summarizes observations from participating receivers. Keep the reporting organization, interval and identifier with the data so duplicate reports or different time windows do not distort the comparison.

Reconcile reports with the sender inventory and selected message evidence. A source IP identifies a reported route, not the person who authorized it. Ask an owner to connect an unfamiliar source to a real application before classifying it as legitimate or unauthorized.

Keep missing evidence visible. A low-volume billing service, an untested forwarding route or an absent receiver report is an open item, even when the dashboard looks green. Set a review window that includes the relevant operating cycles and name the person who will check each gap.

Failure reports are a separate reporting mechanism. Do not make rollout readiness depend on receiving a message-level report for every failure. Record which evidence your reporting arrangement actually provides.

This fictional exercise summarizes 10,000 reported messages using mail.example.org over one defined interval. It contains four mutually exclusive source groups. The figures illustrate a review decision; they are not measurements from Inbox Leads or a promised detection rate.

The overall DMARC pass rate is 9,700 ÷ 10,000 = 97%. That attractive total hides 100 failures within a known 1,000-message CRM stream: a 10% failure rate for that stream. The other 200 failures have no confirmed owner. Do not count them as proven attacks simply because their source is unfamiliar.

In the supplied case evidence, the CRM's failing route uses a service-owned envelope domain and no aligned passing DKIM signature. The CRM owner must repair and verify that route before the change reviewer closes the defect. A successful DNS lookup alone would not demonstrate that the application now sends the corrected identity.

After the repair, request relevant new message and reporting evidence. Keep the unknown group under investigation. The 300 failures are observed authentication outcomes; they are not a prediction that exactly 300 future messages will be rejected under a new policy.

Do not copy a percentage ladder without checking its assumptions. IANA now lists pct as historic and t as the active test-mode tag. RFC 9989 removed percentage sampling from the current protocol. The Google and Microsoft rollout pages checked for this guide still show pct examples, so documentation and deployed behavior need to be distinguished.

Under RFC 9989, t=y requests one less restrictive treatment: quarantine becomes none, while reject becomes quarantine. It does not mean that a chosen percentage of traffic is protected from enforcement.

Older DMARC rules require unknown tags to be ignored. The practical compatibility risk is that a receiver without t support could ignore it and apply the declared policy. Therefore, do not describe p=reject with t=y as a universally harmless test.

Use an explicitly scoped domain, verified mail paths and a recorded change decision to bound the rollout. Where a platform recommends a legacy or new testing control, ask what its implementation supports and what evidence you will inspect. Avoid replacing one unverified assumption with another tag.

Present the reviewer with the exact current and proposed records, the domains affected, remaining exceptions and the observations required after publication. For this illustrative dedicated subdomain, the proposed step changes only p=none to p=quarantine. The reporting mailbox is assumed to exist and be monitored; replace no values in a real zone without its owner's review.

Use the DNS host's documented entry format, verify the resulting public record and record the publication time. Do not create a second competing DMARC record as a way to preserve the old value. Keep the previous value in the change record.

Reject is a separate decision. RFC 9989 cautions against it for domains whose users participate in Internet mailing lists. For such domains considering reject, it recommends at least a month of none followed by an equally long quarantine observation. A dedicated application subdomain and a general staff-email domain need different evidence.

Compare evidence from before and after the change using compatible intervals and source groups. Check legitimate application messages and receiving outcomes alongside aggregate trends. Ask the service owners about failures that their users reported; report totals alone may miss the operational consequence.

Define escalation before publication. Examples include a previously working invoice route failing after the change, an untested critical stream appearing or the reporting pipeline becoming unavailable. Specify who investigates and who can restore the previous policy. Keep unresolved decisions on hold instead of silently advancing a calendar-based rollout.

A DNS restoration does not recall messages already rejected or undo a recipient's actions. Cached records and in-flight messages also complicate immediate comparisons. After recovery, reconcile the affected queues and business tasks before anyone resubmits mail. Record the final disposition of the incident, including any corrective send that was explicitly approved.

Use this worksheet to make the next review possible without reconstructing the project from screenshots. Store sensitive report files under appropriate access controls and reference them from the decision record.

Close the change with a clear outcome: retain this policy, restore the previous value or collect more evidence. A new policy should follow a new decision when the sending inventory or supported workflows change.