攻击者不需要击败 SPF 或者 DKIM 在标题中写入“ spf=pass”或“ dkim=pass” 。当下游工具将提供的文本视为可信评估时，这些字符串就会变得危险。辩护是基于出处意识的解释，而不仅仅是一长串有利的关键词。
与评估分开提取
解析器可以可靠地显示消息包含特定字段。它无法确定所声称的身份验证服务是否生成了它。分析器应保留所有相关事件，识别可信接收证据的来源，并将不可信报告排除在安全判决之外。保留原始字段以供调查，而不是默默地从存储的原始字段中删除证据。
RFC 8601描述了伪造的风险 Authentication-Results 以及信任边界处理的需要。 authserv-id 仅在已建立的上下文中才有意义。如果发送者可以注入具有相同字符串的字段并且网关允许它作为明显可信的存在，那么匹配配置的字符串是不够的。 RFC 8601第 7 节.
测试同名冒充案例
在假设的受控测试中，输入消息包含声明 authserv-id mx.receiver.example和 dmarc=pass 的Authentication-Results dmarc=pass.真正的接收者使用相同的服务标识符，但确定不同的结果。仅仅因为名称匹配，注入的文本就不被信任。
RFC 8601第 5 节要求符合 MTA 删除已发现的Authentication-Results字段，该字段声明其信任边界，但并非直接从另一个受信任的 MTA 到达；它的例子也描述了模糊这样的主张。一起检查支持的入口处理和消费者的最终结论。本指南并未声明已配置或测试任何网关。
对于分析人员，请单独保存原始授权证据副本。证据保留并不意味着将不安全的字段作为实时可信结果转发。受控测试还应涵盖来自明确信任的上游系统的重复、折叠线和合法报告。首次头球获胜和最后一次头球获胜并不能取代该边界设计。
避免误导性的后备措施
如果没有可用的可信结果，则显示“未根据可信接收证据建立”，而不是根据外部声明合成通行证。如果进行独立验证，请将其标记为具有自己的时间、投入和限制的新评估。稍后的DNS查找可能与原始接收期间有效的记录不同，因此重建不会自动获得相同的历史结果。
ARC 相关字段也不是仅通过拼写即可信任的普通Authentication-Results替代品。分析器在依赖断言的上游历史记录之前需要适用的验证和接收者信任决策。 ARC 链验证和接收者信任仍然是独立的要求；本指南未进行ARC验证。看 RFC 8617.
为操作员提供可操作的输出
报告所选的可信来源、忽略的声明以及排除的原因。如果边界处理未知，请在建议DNS更改之前将不确定性上报给邮件管理员。保持分析师导出的原件不可变；将所需的支持入口处理应用于实时邮件并保留解释该决定的授权日志。目标不是隐藏攻击者控制的材料；而是隐藏攻击者控制的材料。这是为了防止该材料控制判决。
安全地检查判决选择
- 在分析之前保留授权证据副本。
- 仅测试具有明确范围的受控接收路径。
- 包括使用可信服务名称的伪造字段，而不仅仅是明显的外部名称。
- 确认入口移除或模糊以及下游从判决中排除。
- 报告丢失的来源，而不是将外部密码字符串转换为身份验证。