一个旧的例外是审查候选者，而不是自动证明其权限可以被删除。确定最初的需求、该需求是否仍然存在以及受影响的服务随后将如何运行。退休应该减少不必要的权力，而不会造成新的交付事件。
找回原来的原因
阅读异常的范围、所有者、批准和预期的关闭测试。确定是否涉及 SPF 机制，一个 DKIM 代表团， DMARC 策略、网关规则或报告排除。这些都有不同的效果。第三方 DKIM选择器 和SPF包含不是可互换的授予权限的方式。 RFC 6376 ，密钥管理 和 RFC 7208.
如果缺少原始原因，请将其标记为未知并指派一名调查员。不要从熟悉的提供商名称中发明业务理由。确认实际的客户服务和租户，而不仅仅是基础设施品牌。保留任何合同或运营依赖性，供责任所有者审查。
测试建议的最终状态
根据授权的测试计划确定替代路线并演练代表性流程。记录相关的身份验证身份、可信结果和业务收据。根据业务日历检查季节性和低用量的使用情况。短暂的安静期可能会错过季度活动或灾难恢复通知。
使用 汇总报告 作为一种观察源，并酌情提供发件人日志和所有者确认。报告并不涵盖所有接收者或证明服务处于非活动状态。 RFC 9990。记录观察间隔和间隙。缺乏证据必须与未使用证据区分开来。
区分准备好和允许删除
考虑三个假设的例外情况。 EX-01 拥有已确认的所有者、已验证的替代路线以及整个相关业务周期内对旧路线的书面审查；它是变更批准的候选者。 EX-02 目前没有所有者，只有一个安静的短暂报告窗口，因此归属和报道仍然开放。 EX-03 仍然服务于预定的活动，因此在测试替代品之前将其删除可能会中断合法使用。
这些是决策演练的假设输入，而不是执行的退休模型或真实的验证证据。即使 EX-01 也不会自动删除：必须检查确切的依赖性、共享用途、当前状态和批准。证据完整的声明应列出所涵盖的服务和时间间隔，而不是暗示普遍可见性。
仅删除已批准的依赖项
准备准确的变更前后和恢复计划。突变前重新检查当前状态。如果范围包括DNS ，则随后验证权威观察并测试受影响的合法流量。缓存的答案可以持续存在，因此验证周期必须符合实际的依赖关系。 RFC 1035.
仅当记录批准的移除和相关服务结果时才关闭例外。保留先前的范围、为什么退休是合理的以及任何剩余风险。如果还无法消除依赖性，则只能通过负责任的决定和具体的下一步行动来更新。在没有新证据的情况下重复更新是治理发现，而不是进步。
关闭记录前验证退休情况
批准删除后，保留确切的更改对象并验证预期的授权损失和合法连续性。如果其中一个不确定，请通过指定的下一个检查将关闭挂起，而不是删除异常历史记录。