Authentication-Results 让邮件系统将身份验证评估传达给下游组件。它之所以有用，正是因为过滤器或用户界面可能不会重复每个原始检查。这种有用性还产生了安全依赖性：消费者必须知道它正在阅读哪个评估者的报告以及攻击者是否可以提供该报告。
读取结果及其身份
该字段包括身份验证服务标识符，通常称为 authserv-id，后面是方法结果和属性。诸如spf=pass之类的结果需要其关联的评估标识； dkim=pass涉及特定的签名域； dmarc=pass涉及适用的作者域 结盟 评估。不要在标题中的任何地方收集“pass”一词并显示通用的经过验证的徽章。 RFC 8601第 2.2 和 2.7 节.
身份验证服务标识符在相关管理上下文中命名报告服务。这不是现场签名。发送者可以在消息中键入相同的标识符，除非边界处理防止该不受信任的字段被误认为是本地生成的字段。
定义消费者的可信来源
建立实际的接收路径，包括批准的上游网关和内部中继。记录需要哪些服务标识符、哪些组件生成结果以及如何删除外部字段或将其保留为不受信任。 RFC 8601的安全指南解决了这个信任边界问题。不要仅从合理的主机名或复制消息顶部附近出现的字段推断安全配置。 RFC 8601第 7 节.
对上游网关的配置更改可能会改变哪些结果对下游有用。检查依赖关系，而不是简单地将每个新标识符添加到可信列表中。过时的信任决策可能会使原本经过良好解析的结果产生误导。
阅读假设的特定方法报告
假设已建立的接收评估器报告 smtp.mailfrom= vendor.example的spf=pass 、标头的dkim=pass 。 d=brand.example和dmarc=pass用于标头。 from=brand.example. SPF 通过并不仅仅因为它说通过而对齐；确切的 DKIM 本示例中的签名域与作者域匹配。报道称 DMARC 因此，假设适用的政策并且没有未解决的评估错误，结果与一致的签名兼容。
现在假设另一个字段报告 spf=temperror。在未识别其评估者、跃点和评估身份的情况下，请勿覆盖第一个SPF结果。两份报告可能描述不同的评估。如果缺少该背景，请报告冲突和不确定性。这些是假设的报告值，不是独立计算的SPF 、 DKIM或DMARC结果。
有用的消费者输出会命名可信评估者并分别显示每个方法、域和结果。它不能仅仅因为其主机名类似于配置的服务而升级不受信任的同名报告。
保留判决中的细微差别
将方法结果分开，包括无、失败和错误状态（如果适用）。缺少结果并不是您观察到的故障，临时评估问题并不能证明域的永久配置是错误的。在修复之前将所选报告与消息和连接证据关联起来。最后以报告服务、其建立的信任基础、方法和身份以及结论的限度为结束。身份验证可以支持路由或过滤决策，而无需验证发送者的意图。
记录每个结果的实际含义
- 评估者：为服务命名并确定其起源的证据。
- 方法：将SPF 、 DKIM和DMARC作为单独的结果保存。
- 身份：将评估的域或属性附加到其自己的结果中。
- 不确定性：保持缺失、无、失败和错误状态不同。
- 消费者：确认网关更改并未使信任配置失效。