A plausible DNS suggestion is not ready to execute until its scope, baseline, effect and approval agree. Validate the proposal before the write, and repeat the relevant checks immediately before execution. This prevents an apparently reviewed change from landing in the wrong tenant or overwriting a configuration that changed while the reviewer was reading it.
Capture a complete proposal
Include tenant, zone, fully qualified owner name, record type, operation, current value, proposed value, TTL where relevant and the observed revision or equivalent precondition. Distinguish adding a record from replacing an entire record set. For TXT records, retain the complete logical value and understand how the provider represents character-string chunks.
Document the affected sending flows and reason for the change. Removing an SPF include can affect more than one application. Adding a DKIM selector does not configure the application to sign with it. Changing DMARC policy does not repair an unaligned sender. RFC 7208, RFC 6376 and RFC 9989 define these separate mechanisms.
Run technical checks independently
Check syntax, record-set conflicts and the intended protocol semantics. For SPF, evaluate DNS-dependent terms and the lookup-limit rules, rather than counting only visible includes. For DKIM, validate the generated public key and selector against the actual signing configuration. For DMARC, inspect policy discovery, affected domains and report destinations. A generic text linter cannot establish that every legitimate sender is ready for enforcement.
Check ownership and authorization separately from syntax. A valid record can still send reports to an unauthorized destination or grant unwanted sender authority. Have the relevant administrator review the effect, especially when a proposal changes reporting, delegation or service access.
Bind approval to the reviewed bytes
Suppose an approved proposal replaces a specific TXT record set at revision 7, including the complete value and TTL. The provider now reports revision 8. Hold for reconciliation even if the intended policy text is unchanged: another operator may have changed a relevant property. If the requested operation instead adds a single value rather than replacing the reviewed set, that operation mismatch also requires review.
These are hypothetical preflight decisions, not an executed gate, DNS parser or SPF evaluator. The approval must cover the actual target, operation and complete payload. Technical checks, signer readiness and business acceptance remain separate from matching the approval digest. No enforcement-policy change or provider write is performed here.
Avoid the last-second race
Where the provider supports conditional updates, use its revision or compare-and-set capability to bind the write to the checked state. If it does not, serialize changes through a controlled process and recognize that a read immediately followed by a write still has a race window. Do not promise atomicity from a client-side comparison alone.
If the live state differs, stop and reconcile the new baseline. Do not rewrite the approval to make it fit. Recheck the affected flows and obtain approval for the revised proposal. The approved action should have a bounded execution window and a planned verification and rollback procedure.
Leave a reviewable decision
Save the proposal, technical-check results, approval, precondition and explicit execute-or-hold decision. A hold should identify the missing evidence and owner. This makes the difference between a safe refusal to overwrite drift and an unexplained automation failure visible to the team.