业务影响声明应该让负责任的所有者决定下一步该做什么。 “DKIM “坏了”太模糊；“所有发票都丢失了”太强，没有证据。解释什么失败了，观察了哪些路线和时间窗口，建立了什么后果，什么仍然不确定。
遵循交易路径
单独的申请生成、提交、认证、接收方受理和业务完成。一个阶段的失败并不能证明其他阶段的地位。消息可以生成但从未提交，或被接收者接受而未到达预期用户的收件箱。仅对齐的身份验证通行证并不能证明客户已对消息进行了操作。
RFC 9989 定义身份验证策略框架和接收者处理。接收者的判断力和其他过滤仍然相关。汇总反馈 RFC 9990 支持调查，但不是完整的逐条消息传递分类帐。
写四个限定句
首先陈述观察结果：哪些服务、路线、间隔和证据。下一个状态确认了业务影响（如果有）。然后描述合理的风险暴露，但不要将其称为已实现的损失。最后命名当前的操作、所有者和下一个决策时间。使用精确的单位：十个报告的消息、十个发票事件和十个客户不是可互换的群体。
在假设的场景中，在一小时内生成了十个发票通知。八个有接收者接受记录，两个有与身份验证失败相关的明确拒绝记录。两个被拒绝的事件对应于价值分别为 450 和 750 说明性货币单位的不同发票，总计 1,200 个单位。假设每个事件都与其发票和接收者结果正确相关。该金额属于延迟通知风险，并未证明收入损失；发票仍可通过其他渠道支付。
保留不确定性
示例声明如下：“在 09:00 至 10:00 UTC 之间的测试路线上，十个生成的发票通知中有两个被拒绝。他们的发票总数为 1,200 个单位；没有确定付款损失。计费操作正在通过批准的渠道验证受影响的帐户。邮件团队将在下一次授权发送之前测试更正的路线。”在没有证据支持的情况下，它不承诺恢复时间。
该示例假设已经关联的事件和结果记录。真实的陈述必须验证申请、提交和接收者证据之间的联系；它不能仅从相似的时间戳中推断出来。如果另一个事件的结果未知，请报告单独的不确定性，而不是将其算作已交付。对于这个假设的说明，没有执行日志连接、客户记录、接收器测试或付款检查。
安全地选择恢复动作
让企业主优先考虑紧急通知并批准任何替代通信。重新发送之前，请检查每个业务事件是否已完成或已通过其他路线传送。否则，恢复工作可能会发送重复的发票或使收件人感到困惑。保留原始事件标识符并单独记录每次重试。
避免扩大范围的投机性变化 SPF 或者仅仅因为业务工作流程紧急而削弱域策略。确定实际发生故障的身份路径，检查最小的适当修复并验证预期路径。当新证据改变总体或后果时更新影响陈述。保留旧版本，以便以后审查可以区分诚实的早期估计和不受支持的主张。