一个 SPF pass 回答发送 IP 是否被授权用于评估的SPF身份。 DMARC 问一个额外的问题：经过身份验证的身份是否与 From 中的域一致？一个 汇总报告 因此可以显示原始SPF通过和 SPF 相关的DMARC失败，而不会自相矛盾。
识别经过SPF验证的域
参考： RFC 9990 §3.1.1.13, RFC 7208 §2.4, RFC 9989 §4.4.2.
一起读取 auth_results/spf/domain 和 result。检查标识符/header_from、任何envelope_from 和报告的范围。不要假设SPF检查了可见的发件人域。 RFC 7208定义 邮件来自 身份，同时 RFC 9989 使用该身份来实现SPF对DMARC的贡献。
对于空反向路径， SPF使用邮局管理员定义 MAIL FROM 身份 HELO 领域。这种特殊情况不应成为任何独立HELO通行证都满足DMARC规则。当前的 RFC 9990 报告允许 mfrom 作为SPF范围；遗留报告格式可能会暴露不同的字段并需要明确的解释。
应用正确的对齐模式
参考： RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.
严格的SPF 结盟 要求经过身份验证的域与作者域完全匹配。宽松的对齐允许通过适用的组织域规则定义关系。不要仅仅通过删除固定数量的标签来计算它：公共后缀和策略发现细节很重要。
row/policy_evaluated 下的SPF值表示 DMARC 相关结果，而不是原始SPF结果的重复。仅仅因为域名彼此相似，原始失败或错误不能成为成功的SPF路径。身份验证必须成功并且一致。
处理两个对比鲜明的行
参考： RFC 9989 §5.3.5.
假设brand.example和vendor.example适用有效的策略、已完成的检查和不相关的组织域。合成行 A 使用 header_from= brand.example 、MAIL FROM= vendor.example和原始SPF =pass。不相关的身份不对齐，因此需要policy_evaluated/ spf=fail 。将供应商 IP 添加到brand.example的SPF不会更改此路由实际评估的身份。
合成行 B 使用 header_from= brand.example和 MAIL FROM= bounce.brand.example以及原始SPF =pass。假设适用的组织域发现将它们放在一起。宽松的SPF对齐可以通过，而严格的SPF对齐则因名称不同而失败。这些是说明性的现场装置，而不是观察到的交通。
对于任一行，检查是否对齐 DKIM 然后得出DMARC整体失败的结论。一个传球对齐 DKIM签名 可以独立于SPF提供成功的DMARC路径。
选择更改失败层的修复
参考： RFC 7208 §10.3.
如果原始SPF失败，请调查实际评估域的授权和连接路径。如果原始SPF通过但未对齐，请调查受支持的自定义 MAIL FROM 配置或其他对齐的身份验证路径。不要继续将 IP 添加到不相关的域中 SPF记录.
通过受控接收的邮件和随后的报告证据确认更改，保留原始结果和一致结果。转发可能会改变连接IP，因此请测试相关路由，并避免仅将SPF视为传递的保证。使用评估的身份、对齐模式和展示的结果结束调查。
保留原始到对齐的测试用例
四个部分合成地图共享 header_from= brand.example 、policy p=reject 和纪元间隔 1704067200–1704153600。 A 使用 MAIL FROM= vendor.example与原始SPF通过且没有DKIM签名：对齐的SPF和DMARC失败。 B 使用 MAIL FROM= bounce.brand.example与原始SPF通行证且无DKIM ：在明确假定的共享组织域下，宽松模式通过SPF对齐和DMARC 。严格模式下相同的 B 输入都会失败。第四种情况恢复了 A 不相关的SPF身份，但添加了brand.example传递DKIM例如 /selector billing1： DMARC通过DKIM传递。
提供的本地身份练习再现了所提供的身份、结果和对齐模式的所有四个结果。它使用显式的组织域映射，而不是DNS树遍历实现。它也不测试真正的空反向路径消息；上面的零路径指导是基于规范的。实际的提供者和接收者行为仍然需要收到的消息证据。
将练习保持在范围内
这些示例是部分字段投影，而不是架构有效的报告或测量的流量。本地检查使用明确提供的身份验证结果和组织关系；他们不执行DNS发现、 SPF评估、加密验证、报告摄取或接收器传送测试。在进行生产更改之前保留原始报告和可信消息证据。