异常寄存器应解释为什么控件与所需状态不同以及如何结束这种差异。标记为豁免的域列表是不够的。将每个异常与业务服务、责任所有者、有限范围、审查日期和基于证据的关闭测试联系起来。
记录实际的异常情况
描述预期控制、当前偏差和业务原因。记录相关的发件人、信封和签名身份、受影响的提供商或租户、重要性、批准和到期。区分广泛的政策放松和狭窄的未解决的发送者路线。 DMARC 结盟 可以通过一致的成功来取得成功 SPF 或者 DKIM 结果，因此实际异常可能与团队最初的诊断不同。分别地， RFC 9989 第 7.4 节和第 8 节要求 p=reject 域来应用有效的DKIM签名，而不仅仅是依赖SPF 。消息级传递并不放弃该部署义务。 RFC 9989.
包括补偿性保障措施及其限制。例如，业务验证过程可以降低支付风险，但不会使未经身份验证的消息得到身份验证。不要将监控订阅或仪表板描述为异常安全的证据。保留支持批准的证据，并将不必要的消息数据保留在寄存器之外。
将到期定义为决策点
与指定的升级负责人一起设置审核日期和到期日。到期应触发明确的决定：关闭、使用新证据续订或升级。它不应该默默地删除DNS权限或中断关键邮件。续签必须重新审视原因和范围，而不是无限期地复制先前的批准。
使用混凝土封闭测试。在替换路由经过身份验证和业务接收测试、旧服务已确认在相关周期内未使用并且批准的删除已得到验证后，旧中继例外可能会关闭。汇总报告可以支持这一评估，但不完整的报告人群中的沉默不能确定不使用。 RFC 9990.
在宣布的审查日期比较三个例外情况
在 2026 年 11 月 8 日的假设审查中，EX-01 是一个工资单过渡，有指定所有者，替换测试仍需要验证。 EX-02 是继承路线，目前没有所有者，有效期至 2026 年 11 月 1 日。EX-03 是季度活动，尚未观察到下一次计划使用情况。 EX-02 在所述日期下逾期七个日历日；该算术不批准续订或删除。
接下来的操作有所不同：获取工资单替换证据，分配继承路线的决策所有者，并计划授权的活动周期检查。 EX-02 的零观测并不能填补其所有权或覆盖范围的空白。这些是发明的登记条目和手工数据推理，而不是执行的程序、风险接受或实时邮件测试。在做出任何实际决定之前，准确记录受影响的权限和身份。
查看寄存器作为操作队列
按业务后果、逾期状态和缺失所有权进行排序，而不仅仅是年龄。为每个未解决的项目分配下一步行动和截止日期。保留最初的原因和以后的更改，以便审阅者可以区分仍然有效的约束和被遗忘的解决方法。
使用定义的群体来衡量逾期异常、无主异常和关闭进度。不要仅从这些计数中得出合规结论。有用的每月审查可以确定做出了哪些决定、哪些证据发生了变化以及业主仍需要在哪些方面采取行动。保留封闭记录及其验证证据，而不是删除历史记录。
将评审变成决策队列
对于每个逾期或即将到期的条目，记录所需的具体证据、决策所有者和下一步行动。将逾期批准、未解决的所有权和技术测试失败作为不同的发现，以便下一个审阅者知道要解决什么问题。