High-impact authentication changes need agreement across business, messaging, DNS and security teams. The key control is not the number of approvals: it is the connection between an approval and the exact change that is executed. Bind the target, baseline and proposed state, then stop when any of them differs.
Define who decides what
The business owner confirms which flows may be affected and how their outcome will be tested. The mail administrator explains authentication and routing dependencies. The DNS operator verifies the zone and available change mechanism. Security reviews authority, exceptions and residual risk. One person can hold multiple roles in a small organisation, but the decision responsibilities should remain explicit.
DMARC policy changes affect treatment of messages that fail aligned authentication; receivers retain their own handling decisions. RFC 9989. This is why approval should cover critical-flow evidence rather than promise universal delivery or universal blocking. Record unresolved dependencies as conditions, not as assumed success.
Bind approval to the exact operation
Create a stable representation containing tenant or account, zone, record name, type, value and TTL. Hash the baseline and proposed payload using a documented serialisation. The approval record should name those hashes, the authorised operator or workflow, expiry and scope. A hash is an integrity reference, not proof that the signer had authority.
Immediately before a write, verify the actual target and compare its current state with the approved baseline. Recalculate the proposed payload digest. Stop on changed state, an unapproved difference, expired approval or the wrong tenant. Use the provider's version guard or equivalent atomic update mechanism where available. A separate read followed by an unguarded write has a race window; local comparison alone does not prevent another actor changing the record between them.
Walk through approval failures before implementation
Suppose a hypothetical approval covers tenant A and a specific baseline, proposed payload and expiry. The current TTL differs from the approved baseline, while all other values match. This recommended gate stops for review rather than treating the difference as harmless. A request aimed at tenant B also stops even if its payload digest matches. Neither equality nor a copied approval proves authority over another account.
At or after the stated expiry, this proposed workflow requires renewed approval. Define that boundary explicitly using validated timestamps and account for clock uncertainty. These are decision examples, not executed code or a tested provider integration. If an eventual approved change passes preflight but the observed result differs from the intended state, leave verification failed and investigate through the approved recovery process. Matching configuration still leaves business acceptance tests to complete.
Complete the approval chain
Retain the approved request, operator identity, provider audit event and observed result. Check representative legitimate flows, reporting continuity and any relevant delayed observations. Do not reinterpret a failed test as a harmless delay without supporting evidence. If the scope changes during implementation, obtain approval for the revised operation rather than reusing the old digest.
Close the record with a precise result: implemented and verified, rolled back and verified, or unresolved with an owner and next action. Keep emergency authority separately scoped. This makes approval usable during an incident without turning it into open-ended permission for future changes.
The change workflow above is an operational recommendation, not a protocol requirement. NIST SP 800-53 Rev. 5 controls CM-3 and CM-5 provide a general basis for reviewing, approving and restricting changes; the exact payload binding, roles and handoff fields here are the proposed implementation. NIST control catalogue.