域身份验证是有关消息路径的有用证据。付款批准是关于业务义务、接收者和金额的决定。将第一个视为第二个会产生差距，即使在以下情况下，该差距仍然存在： SPF, DKIM 和 DMARC 配置正确。
定义通行证所建立的内容
DMARC通行证意味着经过身份验证的域通过合格的SPF或DKIM路径与邮件的作者域保持一致。它不证明发票的准确性、银行账户所有权或个人更改付款指令的权力。 RFC 9989。有效的 DKIM签名 同样，将签名内容与签名域相关联，而不是自动批准它包含的每个请求。 RFC 6376.
攻击者可能会使用经过身份验证的相似帐户、受损的供应商帐户或合法服务。调查这些机制很重要，但支付团队可以在邮件调查继续进行时保留未经验证的更改。任何身份验证分数都不应默默地取代组织的支付控制。
使用单独的验证路径
定义谁可以请求更改、谁独立验证更改以及谁批准发布。通过已建立的渠道联系供应商，而不是仅在争议消息中提供的新号码或回复地址。使用组织批准的程序确认业务指令。 FBI 特别建议独立检查付款和账户变更。 联邦调查局指导.
记录时间、授权验证者、可信联系人来源和决策，而无需将不必要的财务标识符复制到广泛的事件日志中。将付款详细信息保存在经批准的财务系统中，并具有适当的访问权限。对于高风险变更，示例策略使用第二个授权审批者；这是提议的本地控制，而不是通用协议要求。
通过三个决定进行工作
使用提议的规则，要求对高风险变更进行独立确认和第二次授权批准。假设所有其他特定于组织的检查仍然适用。
- 案例 A：假设供应商账户受损；域传递 true；独立确认虚假；第二次批准错误。坚持改变。
- 情况B：假设经过验证的相似；域传递 true；独立确认虚假；第二次批准错误。坚持改变。
- 案例C：假设合法供应商变更；域传递 true；独立确认真实；第二次批准真实。在此示例下有资格进行进一步发布处理，而不是转账指令或所有财务控制已通过的证明。
这些标签和布尔值是规定的教学假设。没有执行任何程序、回调、账户验证或转账。在实际情况中，财务负责人需要为每项已完成的检查提供授权证据，而技术归属仍单独记录。
保持异常可见
紧迫性、资历和熟悉的签名块不应成为隐藏的旁路。如果无法联系到已建立的联系人，请将案例发送给指定的例外负责人并记录决定。不要悄悄地将电子邮件身份验证视为丢失的回调。向技术团队提供原始消息，同时将财务保留在付款所有者的控制之下。
如果已经发生可疑转移，请立即使用已知渠道联系金融机构和组织的事件响应联系人。及时联系可以让金融机构评估可用的恢复选项。不承诺资金可以被收回。保留请求、批准和时间表，并将遏制决策与未经证实的归因区分开来。