An enforcement decision needs an evidence threshold that the team can explain before the change happens. Otherwise a healthy percentage, an arbitrary waiting period or a green DNS result can become a substitute for knowing which legitimate messages are at risk.
Define the criteria around the business flows and domain being assessed. The result should be a decision record that says why a particular change is justified, what remains uncertain and who will act if an important message stops arriving.
Define the decision precisely
Write down the exact domain, its purpose and the policy change being considered. A decision about a dedicated receipt domain does not automatically apply to employee mail or a newly acquired brand.
Identify the approving owner and the operational consequence of a mistake. A failed critical notification may matter more than thousands of passing low-risk messages. Put those important flows in the evidence criteria, even when their volume is small.
Use the policy-selection guide to assess suitability. Stronger assessment is not an automatic destination for every domain: The interoperability guidance in RFC 9989 §7.4 is particularly relevant to general-purpose mail and Internet mailing-list participation.
Build criteria that can fail clearly
The following acceptance framework is an original operating recommendation. It is not a protocol-mandated checklist or a claim that every organisation has the same risk tolerance.
- Criterion: Important services are known and owned; Evidence that can support it: Inventory linked to approved accounts, routes and business owners; A reason to keep the decision open: A critical service has no owner or unexplained route
- Criterion: Intended identities work; Evidence that can support it: Received-message evidence from each affected route, with authentication and alignment recorded; A reason to keep the decision open: Only DNS status or an unrelated raw pass is available
- Criterion: Periodic flows are covered; Evidence that can support it: Representative samples or a documented test covering the relevant business cycle; A reason to keep the decision open: A monthly or annual service has not been examined
- Criterion: Indirect use is assessed; Evidence that can support it: Known forwarder and mailing-list cases with route-specific findings; A reason to keep the decision open: Staff list participation is ignored
- Criterion: Observations are interpreted correctly; Evidence that can support it: Reporters, periods, errors and known gaps described alongside service evidence; A reason to keep the decision open: A percentage is treated as a complete sent-mail ledger
- Criterion: Recovery can be executed; Evidence that can support it: Named owner, previous record, decision trigger and verification steps; A reason to keep the decision open: Nobody can change the affected DNS or recover the service
Each failed criterion should produce an owner and a next action. Avoid a checklist that can be marked green with no attached evidence or that rewards the team for writing “not applicable” without an explanation.
Examine identity evidence at message level
For each critical flow, retain the From domain, SPF-evaluated identity, relevant DKIM signing domains and receiver results. Show which passing identity aligns under the applicable policy. A raw pass for a service's own domain can coexist with a DMARC failure for the organisation's From domain.
Also distinguish a passing message from the domain owner's full participation. Under RFC 9989 §5.3.5, one passing aligned mechanism can establish the message-level DMARC pass condition when an applicable policy exists. The participation requirements in RFC 9989 §8 cover aligned SPF and DKIM, reporting, policy publication and other actions. Under RFC 9989 §7.4, a domain publishing reject must not rely solely on SPF and must apply valid DKIM signatures.
Record what was actually tested. A demonstration through a provider's default sender does not establish that the production application uses the same identity or account. Where a provider supports several routes, name the route in the evidence.
Use a synthetic decision example
Imagine a dedicated service domain with three known flows: receipts, account alerts and quarterly tax statements. Receipts and alerts have current received samples and clear owners. The quarterly service is approved but its production signing state has not been checked.
The aggregate report shows a high pass rate dominated by receipts. That observation is useful but does not satisfy the critical-flow criterion for tax statements. The correct next action is to obtain a representative test and confirm its intended identity path.
Suppose a later authorised test supplies the missing evidence and the owner confirms the production configuration. The reviewer can now reconsider the change using that new evidence. This is a synthetic progression; no actual test, measured pass rate or approval is asserted here.
State observation limits openly
Report structure and receiver participation are described in RFC 9990 §3.1 and RFC 9989 §5.3.8. A quiet reporting window may reflect low sending volume, incomplete receiver participation or successful authentication. It cannot establish which explanation applies without supporting evidence.
A fixed number of days is therefore not a general readiness test. The relevant period depends on the domain's business cycles and the applicable guidance. For domains with potential Internet mailing-list use contemplating reject despite the caution, RFC 9989 gives specific monitoring and quarantine comparison guidance; it should not be replaced by a generic seven-day promise.
Use the monitoring-policy guide to define what the observation period is expected to reveal. Keep absence of evidence separate from evidence that a service does not send.
Make approval and recovery concrete
The approval note should link each criterion to its evidence and record unresolved risks. Preserve the previous DNS value and the exact proposed difference. Name the person who can act, the verification plan and the conditions that would trigger review or recovery.
Recovery is a decision process, not a promise of instant propagation. DNS caches can retain previous information, including qualifying stale-answer use after TTL expiry under RFC 8767 §4. Have a plan for communicating with affected service owners and retesting the specific route while configuration observations converge.
After the approved change, inspect actual DNS and legitimate-flow results and review the reporting periods that cover the change. Record findings and corrective action. A completed approval form before deployment does not substitute for this later verification.
The evidence threshold is met when the team can account for important legitimate communication, justify the chosen policy for the domain and recover from an unexpected result. Keep the criteria with the service inventory so the next application or supplier change can be assessed against the same standard.
Record a decision that can be reviewed
In the three-flow example, keep the tax-statement criterion open until representative evidence arrives, even if receipts dominate a healthy percentage. The decision can be delay, a narrower justified scope, or an explicitly accepted limitation with an accountable owner. These are editorial governance options, not automatic protocol approval, and this article does not approve any real change.