入站消息可以通过域身份验证，但仍然要求收件人执行危险操作。由于合法路由中断，它也可能导致身份验证失败。将身份验证视为消息的一项可测量属性，然后应用接收系统的其他控制和组织的业务验证流程。瓦解这些步骤会产生虚假的保证和不必要的干扰。
确定三个决定
第一个决定是技术性的：经过身份验证的标识符是否与适用的作者域一致 DMARC 规则？第二个是可操作的：考虑到政策和其他信号，接收环境应该如何处理消息？第三个是特定于业务的：所请求的操作是否合法且授权？ RFC 9989 定义基于域的身份验证和策略；它不会将传递的消息转化为支付发票的批准。 DMARC规范.
将这些决定记录在不同的字段中。对于发票变更请求，认证字段可能已通过，处理字段隔离待审核，业务字段未验证。这些价值观是兼容的。收件人可以使用DMARC外部的信号，并且即使邮件已通过身份验证，员工也应遵循独立的审批工作流程。
使用来自可信边界的结果
一个 Authentication-Results标头 仅当了解其出处时才有用。攻击者可以将标题文本插入消息中。接收组织必须区分其受信任的身份验证服务生成的结果和不受信任的断言。 RFC 8601描述了该信任边界。 认证结果.
保留原始消息和可信接收系统的日志。将可见的 From 域与每个已验证的域进行比较 DKIM 签名域和 SPF 身份实际评估。避免将显示名称、回复字段或转发的屏幕截图视为经过身份验证的作者域。如果消息被转发，请记录原始评估点和后续转换，然后再决定应用哪些证据。
比较三个综合请求
考虑三个假设的付款更改消息。第一个声称是brand.test，但只有一个通过的evil.test签名，没有SPF通过；假定的唯一经过身份验证的标识符严格失败 结盟。第二个在 From 及其传递的DKIM身份中使用 Brand-pay.test，因此尽管存在相似问题，其建模身份验证仍会通过。第三个方法一致地使用brand.test并且也通过了，从而导致帐户滥用或未经授权的请求成为可能。
针对每种情况建议的业务行动是：保留变更并独立验证。这些是发明的身份验证输入，而不是加密或接收器结果。书面案例假设所述身份是唯一可用的经过身份验证的标识符，隔离严格的精确域匹配，并且不实现完整的DMARC发现。未执行消息、签名或接收者测试。它演示了为什么不能仅根据身份验证布尔值来计算业务操作。
不绕过审查的设计处理
为每个控制路径选择授权的测试消息，并记录系统是否拒绝、隔离、传送或稍后修复它们。供应商的功能标签并不是您配置的行为的证据。在测试中包括例外和允许规则，因为它们可以改变有效结果。避免仅仅为了让一条破损的合法路线通过而进行广泛的许可名单。
对于财务请求，请使用之前建立的联系渠道。联邦调查局建议独立验证付款请求和帐户详细信息的更改。请勿使用可疑消息引入的联系方式作为该独立渠道。 FBI 商业电子邮件泄露指南.
结束对所有三个决定、每个决定以及任何未解决问题的证据的审查。这使得邮件团队可以在财务部门保留付款保留的同时修复身份验证，或者安全部门可以调查传递但可疑的邮件，而不会声称DMARC有缺陷。
源和执行边界
RFC 9989第 4.4、5.3.5 和 5.4 节 区分认证、对齐和处理；通行证并不认可消息内容。这里的运营决策是范围内的建议和明确的假设示例，而不是对客户、提供商或历史固定装置的新测试。任何真正的改变都需要有自己的授权范围、保留的证据和负责任的决定。