在其范围、基线、效果和批准达成一致之前，看似合理的DNS建议尚未准备好执行。在写入之前验证提案，并在执行前立即重复相关检查。这可以防止明显经过审核的更改落入错误的租户或覆盖审核者正在阅读时更改的配置。
获取完整的提案
包括租户、区域、完全限定所有者名称、记录类型、操作、当前值、建议值、相关 TTL 以及观察到的修订或等效前提条件。区分添加 一个记录 替换整个记录集。为了 TXT记录，保留完整的逻辑值并了解提供者如何表示字符串块。
记录受影响的发送流程以及更改的原因。删除一个 SPF include 可以影响多个应用程序。添加一个 DKIM选择器 不配置应用程序来使用它进行签名。改变 DMARC 策略不会修复未对齐的发件人。 RFC 7208, RFC 6376 和 RFC 9989 定义这些单独的机制。
独立进行技术检查
检查语法、记录集冲突和预期的协议语义。对于SPF ，评估 DNS 相关术语和查找限制规则，而不是仅计算可见包含。为了 DKIM，根据实际签名配置验证生成的公钥和选择器。对于DMARC ，检查策略发现、受影响的域和报告目标。通用文本 linter 无法确定每个合法发送者都已准备好执行。
与语法分开检查所有权和授权。有效记录仍然可以将报告发送到未经授权的目的地或授予不需要的发件人权限。让相关管理员审查效果，尤其是当提案更改报告、委派或服务访问权限时。
将批准绑定到已审核的字节
假设已批准的提案替换了修订版 7 中的特定TXT记录集，包括完整值和 TTL。提供商现在报告修订版 8。即使预期的策略文本未更改，也请保留以进行协调：其他操作员可能已更改相关属性。如果请求的操作改为添加单个值而不是替换已检查的集，则该操作不匹配也需要检查。
这些是假设的预检决策，而不是执行的门、 DNS解析器或SPF评估器。批准必须涵盖实际目标、操作和完整的有效载荷。技术检查、签名者准备情况和业务验收仍然与匹配批准摘要分开。这里不执行任何强制策略更改或提供程序写入。
避免最后一秒的比赛
如果提供程序支持条件更新，请使用其修订或比较和设置功能将写入绑定到已检查状态。如果没有，则通过受控过程序列化更改，并认识到紧随其后的读取仍然具有竞争窗口。不要仅从客户端比较来保证原子性。
如果实时状态不同，请停止并协调新基线。不要重写批准以使其适合。重新检查受影响的流量并获得修订提案的批准。批准的行动应具有有限的执行窗口和计划的验证和回滚程序。
留下可审查的决定
保存提案、技术检查结果、批准、前提条件和明确的执行或保留决定。扣押应确定缺失的证据和所有者。这使得团队可以看到安全拒绝覆盖漂移和无法解释的自动化故障之间的区别。