邮件系统可以报告 SPF 通过和 DKIM 经过一段时间 DMARC 仍然失败。这个结果并不矛盾。每种机制都以不同的身份开始，并且DMARC在传递的身份与邮件的发件人地址中的域之间添加关系测试。
调查消息的可靠方法是在更改DNS之前记录身份链。从收件人在“发件人”中看到的域开始。然后记录用于SPF域以及在 DKIM签名。只有在那之后你才应该评估 结盟 以及消息级DMARC结果。
在阅读结果之前说出三个身份的名称
考虑这个虚构的消息：
来自：计费团队 < statements@billing.example.com > Return-Path ： < bounce+739@mailer.example.net > DKIM-Signature ：... d=billing.example.com; s=outbound1; ...From 域是 billing.example.com。 DMARC将其称为作者域。这 信封发件人 在这里表示为 Return-Path 领域 mailer.example.net;对于此普通消息的 MAIL FROM 检查，即SPF评估的身份 RFC 7208 §2.4。一个单独的 HELO 检查也可以发生在 RFC 7208 §2.3; Return-Path处理在中指定 RFC 5321 §4.4。 DKIM签名域的值为 d=，即 billing.example.com 在这个例子中。
显示名称（例如计费团队）不是身份验证身份。 Reply-To 也不是作者域。这些字段对于欺诈调查可能很重要，但它们不会取代DMARC比较的域。
分别记录结果和对齐
原始SPF通行证意味着连接源已获得所评估的SPF身份的授权。原始DKIM通行证意味着经过验证的签名 d= 域和所涵盖的消息材料。这两个结果本身都表明其域与 From 具有所需的关系。
因此， DMARC每个路径需要两列：
- 路径： SPF ；认证问题：评估的信封身份SPF是否通过？对齐问题：该身份是否与作者域对齐？
- 路径： DKIM ；身份验证问题：此签名是否通过了其 d= 域？；对齐问题：d= 域与作者域对齐吗？
在下面 RFC 9989 §3.2.10.2，严格对齐需要精确的域相等。在下面 RFC 9989 §4.10.2，宽松的对齐使用适用的组织域发现关系。不要通过使用最后两个标签来近似该边界，因为公共后缀规则可能会使该快捷方式出错。
完成一次传递和误导性原始传递
以下是综合教学示例，并非客户留言。假设适用的有效策略、已完成的检查、可信的接收结果和已知的对齐模式； RFC 9989 §5.3.5 定义最终的通过/失败规则。
- 观察：来自；消息A： alerts@example.com ；消息 B： alerts@example.com
- 观察： SPF结果；消息A：传递给bounce.vendor.example.net ；消息B：传递给bounce.vendor.example.net
- 观察： SPF是否一致？；消息A：否；消息 B：否
- 观察： DKIM结果；消息A：通过d=example.com;消息 B：通过d=vendor.example.net传递
- 观察结果： DKIM是否一致？；消息A：是；消息 B：否
- 观察：消息级DMARC ；消息A：通过DKIM传递；消息 B：失败
消息 A 通过DMARC ，因为一个DKIM签名既可以验证又可以对齐。其未对齐的SPF结果不会取消该有效路径。消息 B 有两个原始身份验证通道，但两个经过身份验证的域均不与作者域对齐，因此没有传递DMARC路径。
该表也是有用的变更记录。它显示修复是否属于信封身份、签名配置或可见的 From 域。没有这些域的绿色图标不足以作为授权DNS更改的证据。
检查每个DKIM签名
一条消息可以携带多个DKIM签名。出站服务、网关和中介可以各添加一个。独立评估每个签名。即使另一个签名未对齐或失败，一个对齐的传递签名也可以提供DKIM路径。
不要推断 选择器 来自提供商名称。阅读 s= 来自实际DKIM-Signature标头的值，将其与该签名的结合起来 d= 域，并在下面查询生成的DNS名称 RFC 6376 §3.6.2.1。发布密钥仅使验证材料可用。发送系统仍必须使用相应的私钥创建有效签名。
间接邮件可以更改签名内容或信封路径。因此，转发可能会影响SPF ，而列表修改可能会影响DKIM 。将观察到的路径视为调查证据，而不是原始发件人或中介恶意的证据。
使用可信接收证据
Authentication-Results 可以总结身份和结果，但信任取决于添加标头的位置。发送者可以插入声明成功的标头。在下面 RFC 8601 §7.1，使用您管理的接收系统或您了解其处理方式的其他边界产生的结果。
当消息在传送之前被拒绝时，传送的副本可能不存在。使用拒绝响应、提供商日志和任何可用的接收遥测数据。不要仅根据错误代码来发明丢失的身份。
将身份链变成操作记录
对于每个材料发送者，保留：
- 企业主和申请；
- 授权使用的 From 域；
- 观察到的信封身份；
- 每个观察到的DKIM d= 域和选择器；
- 每个路径的认证结果；
- 对齐方式和结论；
- 具有代表性的测试日期和消息标识符。
该记录将业务授权与协议证据分开。它还可以防止一个常见错误：更改组织的根 SPF记录 解决DKIM对齐问题，或在发件人配置存在真正缺陷时更改DMARC策略。
一旦身份链清晰，就可以使用 对准故障排除指南 修复失败的路径和 发件人库存 分配所有权。
将结论保留在证据范围内
对于消息 A，将SPF通过/未对齐和DKIM通过/对齐写入单独的事实。对于 B，不要将两个不相关的原始通道转换为DMARC通道。独立保留每个签名，不要仅从显示名称推断SMTP身份。这些案例和缩写签名均为教学示例，并非有效的签名材料或已执行的验证。