A DMARC policy should reflect what a domain does and what the organisation can establish about its mail. A tightly controlled notification domain, a staff correspondence domain and a domain that sends nothing can require different decisions.
Begin with the domain's purpose and legitimate routes. Then assess the consequences of the requested policy, the evidence available to support it and the receiver behaviours that remain outside your control.
Describe the domain before choosing a policy
Protocol references: RFC 5321 §5.1. Operational checklists and decisions below are editorial guidance.
Record whether the domain sends employee correspondence, transactional messages, campaigns or no authorised mail. Include subdomains, acquired systems and services purchased outside central IT.
An MX record describes a receiving route. It does not inventory every system that can use the domain in From. Likewise, the absence of mailboxes does not establish that no application sends notifications.
Give each material route a business purpose and owner. An unknown source remains unknown until investigated. A familiar provider name or a large cloud network is not sufficient evidence of approval.
State what the requested policy means
Protocol references: RFC 9989 §4.7, RFC 9989 §5.4. Operational checklists and decisions below are editorial guidance.
The policy communicates the owner's assessment of messages that fail DMARC. It does not configure a sender's authentication or determine every receiver's final action.
- Policy: none; Decision context: The owner expresses no handling preference for failure
- Policy: quarantine; Decision context: Failing use is treated as suspicious in the owner's assessment
- Policy: reject; Decision context: The owner regards failing use as invalid
A receiver still combines authentication and policy with its own handling decisions. A dashboard label or a published DNS string does not establish that every failing message was rejected or that passing messages reached the inbox.
Before a change, separate the policy choice from the repair of legitimate failing senders. Moving a record between these values cannot create alignment for an application using an unrelated identity.
Assess the legitimate routes that can be disrupted
Protocol references: RFC 9989 §7.4. Operational checklists and decisions below are editorial guidance.
Test critical services, including low-volume events such as payroll, password resets and renewals. Use actual application workflows and inspect the received results after gateways or intermediaries.
General-purpose correspondence needs particular care. Current RFC 9989 cautions against reject for such domains and explains mailing-list interoperability problems. Its guidance for domains whose users post to lists includes specific observation, comparison and user-policy considerations.
Read that guidance for the applicable case. Do not replace it with an automatic seven-day or thirty-day progression applied to every domain.
Compare two different domain purposes
This is a synthetic planning example.
A dedicated receipts domain has a single approved application, a maintained DKIM configuration and no staff correspondence. Its operator can test representative receipt workflows, monitor failures and define a scoped change.
The staff domain supports conversations, role addresses and Internet mailing lists. A direct employee-mail test covers only part of that activity. Its policy review needs evidence about indirect routes and user impact as well.
The difference is not that one team values security more. The domains have different legitimate uses and different consequences when a receiver acts on a failure.
Define the evidence and recovery conditions
Prepare a decision record containing the domain scope, intended policy, legitimate services tested, unresolved routes, relevant reporting limitations, approver and verification plan.
Decide what would trigger investigation or restoration of the prior approved state. Keep the old record and change history available. Restoration is an operating decision with an owner, not an improvised reaction to the first unfamiliar report row.
Avoid a percentage threshold that hides the population. A high overall pass rate can coexist with a completely failing critical service. Use the aggregate-report walkthrough to retain the denominator and attribution context.
Record the reason and review it when the domain changes
The outcome may be a policy change, a sender correction, further observation, domain separation or a decision to retain the existing policy. Explain the reason and its evidence.
Revisit that decision when a new application, acquisition, gateway or business use changes the legitimate mail population. The sender-inventory guide provides the operating record, while quarantine versus reject examines the handling trade-off more closely.
Apply the evidence without overstating it
For the fictional receipts domain, a maintained DKIM setting alone is not enough: require received-message evidence of a passing aligned signature and the other participation checks. For the staff domain, retain unresolved mailing-list impact as an explicit decision constraint. Neither scenario authorizes a DNS change or claims an executed test.