电子邮件身份验证风险登记册应解释哪些业务服务可能会受到损害以及哪些决策可以降低该风险。 “DMARC “缺失”是一项技术发现，而不是完整的风险声明。将这种情况与可信的威胁或故障路径、受影响的流程、现有的保障措施和负责任的所有者联系起来。
描述服务和场景
对于每个条目，记录服务、域、应用程序所有者、技术条件、举证时间和可能的后果。保持不确定性明确。未被观察到的发件人是证据缺口，而经过验证的未对齐合法发件人是身份验证缺陷。两者都不能自动证明攻击者已经利用了该服务。
RFC 9989 指定域身份验证和 结盟 行为。它的保护并不能确定每个经过身份验证的请求都是合法的。风险登记册必须区分直接冒充您的域名与受损的授权帐户或 相似域名 本身通过身份验证。
分离固有风险和剩余风险
描述控制措施之前的场景，然后解释每个现有防护措施的变化。对于发票指令，付款回调验证可以解决仅域身份验证无法解决的欺诈性业务请求。不要暗示书面回调政策的存在证明人们始终遵守它。
使用组织商定的可能性和影响定义。避免在没有证据的情况下呈现虚构的精确度，例如 17.3% 的年度欺诈概率。如果数据不足，请使用定性评级及其理由和审查触发点。记录谁有权接受剩余风险，而不是将邮件管理员的技术签字视为业务接受。
使用链接示例
假设假设条目 R-1 涉及工资单。该条件是在已注册的关键服务上缺少当前对齐通过证据。如果未经测试的路线在执行过程中失败，潜在的后果是错过工资单通知。这是一个有条件的场景，而不是声称员工错过了消息。财务负责该服务，邮件团队负责调查和关闭，需要当前的路由测试以及服务所有者的确认。
R-2 涵盖通过攻击者拥有的相似域进行发票支付模拟。其提议的控制是通过已经可信的联系路线进行独立验证。在受害者的域上发布更强的策略并不能满足 R-2 的封闭测试。对于每个条目，在将提议的登记册视为完整之前，需要有发现、所有者、决定和明确的结束证据。这是推荐的审查规则，而不是执行的验证或控制措施有效的证明。
保持登记册可操作
明确选择处理方法：补救、避免风险活动、在适当的情况下转移确定的风险，或通过授权的决策流程接受剩余的风险。设置截止日期并查看触发器。治疗计划并不是完成的证据；单独保留实际测试或决策记录。
这些假设的条目说明了不同的场景，而不是观察到的攻击或可接受的业务风险。完整性审查可以识别缺失的字段，但无法验证风险评级或确定真正的保障措施是否有效。将实际证据和授权接受决定与提议的治疗分开。
在迁移、新发件人、事件和业务变更后查看注册表。仅关闭其证据满足规定测试的特定场景，并保留足够的历史记录来解释关闭的原因。
NIST SP 800-30 Rev. 1 第 2.3 和 3.2 节描述了风险因素、评估方法和记录评估结果。他们支持明确可能性、影响和不确定性；上述特定于电子邮件的注册字段和示例是建议的应用程序，而不是规定的合规性清单。 风险评估指南.