确定消息声称的内容
消息可以通过多种不同的方式模仿业务。它可能会将企业的确切域放在可见的发件人地址中，使用熟悉的人的显示名称和不相关的地址，或者从选择与企业相似的不同域发送。这些不是可以互换的机制。它们需要不同的证据并暴露不同的控制边界。将这三种情况称为 DMARC 失败会鼓励错误的修复，并可能隐藏需要业务验证而不是DNS编辑的事件。
RFC 9989 将DMARC范围限制为 RFC5322 .来自 域和一致的身份验证。它明确排除显示名称攻击、内容分析和域以外实体的身份验证。接收者仍然可以应用额外的保护，但这些保护不应归因于DMARC本身。本文提供了一种防御性分类的分类方法，没有对指定发件人进行真正的邮件检查或指控。
精确域使用需要精确比较
从解析的发件人地址中的实际域开始，而不是邮件应用程序显示的显示文本。将其与与请求相关的业务领域进行比较。在有限的调查记录中保留准确的拼写和证据来源。如果域相同，下一个问题是受信任的接收者证据是否显示一致的身份验证、失败、缺乏策略或不确定的结果。仅凭精确的域外观并不能告诉您发生了什么。
使用确切域的未经授权的发件人可能会失败 结盟，但受损的授权帐户或服务可能会产生一致的邮件。因此，相同的可见域可能出现在非常不同的事件中。 DMARC通行证并不能证明该邮件已被某人批准，并且失败本身也不能证明存在恶意意图。转发、配置错误和不完整的证据可能会使解释变得复杂。在指定原因之前先陈述狭隘观察到的事实。
显示名称是一个单独的身份表面
RFC 5322，第 3.4 节，区分邮箱的可选显示名称及其地址。显示名称可以向读者标识人员或角色，而无需成为DMARC评估的域。例如，一条虚构的消息可能会显示“Accounts Team”，而其地址属于不相关的示例域。熟悉的标签并不是组织所有权的证明。
小屏幕或折叠视图可能无法乍一看显示每个身份字段。防御操作是使用接收应用程序的可信接口检查完整地址，然后独立评估业务请求。不要发明通用的 UI 规则或承诺每个客户都会突出显示不匹配的情况。标准对标签和地址的区分是稳定的；呈现和保护警告取决于客户和接收者。
相似域名可以成功验证
由于拼写、标点符号或字符选择，不同的域可能在视觉上与受信任的域相似。如果其运营商合法地控制其发送设置，则来自该域的邮件可以通过 SPF, DKIM 以及该域的DMARC 。身份验证不一定发生故障。接收者对预期组织的识别失败或在不同层面被操纵。
将实际域与从可疑消息外部获取的可信业务记录进行比较。请勿仅为了确定所有权而访问所提供的网站或回复有问题的地址。将熟悉的品牌词嵌入较长的名称中是不够的。仔细保留国际化名称解释，如果显示形式和底层形式不同，请寻求合格的分析；该草案没有提供完整的 Unicode 或公共后缀分类算法。
使用可信的身份验证证据
一个 Authentication-Results 该字段仅在接收者的信任边界内有用。 RFC 8601 解释了为什么消费者必须区分受信任的身份验证断言和消息中携带的任意字段。从转发的消息或屏幕截图中复制一行表示“通过”的行并不能证明相关接收者生成了该行。记录哪个接收者评估了该消息以及调查员如何获得结果。
保持可见的 From 域， 信封发件人 域、 DKIM签名域和回复身份不同。他们的差异可能有合理的解释，不应自动归结为欺诈调查结果。对于DMARC ，确定对齐的身份验证路径，而不是将每个SPF或DKIM通行证视为足够。对于业务请求，请检查所请求的操作以及据称执行该操作的人员的权限。
身份比较工作表
准备一行，其中包含可信业务域、可见显示标签、解析的发件人地址、回复地址（如果存在）、经过身份验证的域、接收者结果、证据来源和建议的分类。添加未知内容以及哪个独立渠道可以验证请求的列。最大限度地减少任何共享版本中的个人标识符，同时保留两个域是否相同或不同。将所有值更改为一个占位符会破坏工作表应显示的关系。
使用三个临时类别：精确域使用、显示名称模仿和不同域相似性。允许组合和未解决的类别。消息可以使用误导性的显示名称和 相似域名。当一致的邮件似乎来自真实组织时，工作表还应该允许授权帐户妥协作为假设。分类是进行调查的一种方式，而不是意图或责任的最终确定。
三个消息的虚构比较
想象一下，一个虚构的财务团队收到与北桥示例相关的三个异常请求。第一个具有北桥的确切域，但受信任的接收器证据表明没有对齐的传递。第二个使用财务总监的显示名称和一个不相关的地址，该地址针对其自己的域进行身份验证。第三个使用看起来相似但不同的域，并且还对该域进行身份验证。这些是发明的观察结果，而不是在这项工作中收集的信息。
第一个案例导致身份验证和发送路径调查。第二个导致显示名称和业务权限验证。第三个导致域比较和模拟处理。没有一个仅仅因为出现熟悉的名字就保证付款，并且没有一个应该通过将不相关的发件人添加到北桥的来“修复” SPF记录。如果第四条消息使用北桥的实际域进行对齐，则帐户或服务仍然可能受到损害，并且需要其自己的证据。
验证消息之外的请求
这 IC3云电子邮件BEC咨询于 2020 年发布，建议通过已知的联系方式对可疑业务请求进行验证。它的年龄是明确的：它支持一般控制，而不是关于当前事件或特定接收器的当前接口的声明。使用已经独立记录的号码或工作流程，并验证请求的具体更改，而不是仅仅询问某人是否发送了电子邮件。
所需的经过编辑的滥用场景（包括身份证据、控制边界和独立业务验证）仍未实现。这篇手稿的虚构比较并不能满足它。没有查询任何帐户，没有访问可疑域，也没有联系任何一方。放行前，保留经授权的真实证据，由有资格的审查人员验证分类，确认来源适用性和生产路线，完成可达性审查，并获得业主批准。结果应该是对所主张的身份以及实际建立的控制措施的合理解释。