RFC 8601 — 身份验证结果标头字段

Proposed Standard Email Authentication Obsoletes RFC 7601 Published March 2026

ELI5: 当信件到达公司邮件室时，保安检查快递员的身份证，验证寄件地址，检查防篡改封条。然后他们在信件上贴一张便签，总结他们的发现："驾驶证已验证、寄件地址已确认、封条完整。"Authentication-Results 标头就是那张便签——这是接收邮件服务器记录所有身份验证检查结果的标准化方式，这样下游过滤器、垃圾邮件引擎和邮件客户端就可以使用这些信息，而无需重新运行检查。

此RFC存在的原因

电子邮件身份验证涉及多个独立机制：SPF、DKIM、DMARC、ARC及其他。每个都产生自己的结果。没有标准方式来记录这些结果，邮件传递管道中的每个组件——内容过滤器、垃圾邮件分类器、面向用户的客户端——都需要独立重新评估每个身份验证机制。

RFC 8601定义了Authentication-Results头字段，这是一种结构化方式，用于边界MTA（基础设施中从互联网接收消息的第一台服务器）在单个头中记录所有身份验证检查的结果。然后所有下游组件都可以使用此结果。

RFC 8601废弃了RFC 7601，后者本身废弃了RFC 5451。这些更新完善了语法、注册了其他方法关键字，并澄清了信任边界处理。

工作原理

头结构

Authentication-Results头有定义的语法：

Authentication-Results: <authserv-id>; <method>=<result> [reason=<text>] [<property>.<type>=<value>] [; ...]

真实案例

Authentication-Results: mx.receiver.com;
dkim=pass header.d=example.com header.s=mtg20240101 header.b=LjIEJLN;
spf=pass (sender IP is 198.51.100.25) smtp.mailfrom=example.com;
dmarc=pass (p=reject dis=none) header.from=example.com;
arc=pass (i=1 spf=pass dkim=pass dmarc=pass)

生成方式

边界MTA通过SMTP从互联网接收消息。
针对信封发件人和连接IP运行SPF检查。
通过查询DNS公钥验证任何DKIM签名。
评估DMARC策略和对齐情况。
验证消息上存在的任何ARC链。
在消息前面添加Authentication-Results头，总结所有结果，由其主机名（authserv-id）标识。
下游内容过滤器、垃圾邮件引擎和传递逻辑读取此头，而不是重新运行检查。

关键技术细节

authserv-id

Authentication-Results:之后的第一个令牌是authserv-id，通常是执行检查的服务器主机名。这对信任至关重要：接收系统应仅信任authserv-id与其自身行政域内服务器匹配的Authentication-Results头。来自外部服务器的头应被删除或忽略。

方法关键字

IANA维护身份验证方法关键字的注册表。最常用的是：

方法	检查内容	定义于
`spf`	信封发件人的SPF评估	RFC 7208
`dkim`	DKIM签名验证	RFC 6376
`dmarc`	DMARC对齐和策略评估	RFC 7489
`arc`	ARC链验证	RFC 8617
`auth`	SMTP AUTH（RFC 4954）凭证	RFC 4954
`iprev`	连接IP的反向DNS验证	RFC 8601

结果值

每个方法产生以下结果值之一：

结果	含义
`pass`	身份验证成功。
`fail`	身份验证明确失败。
`softfail`	身份验证失败，但发件人策略建议将其视为可疑而非拒绝（特定于SPF）。
`neutral`	发件人不做任何声明（SPF `?all`）。
`none`	未找到身份验证记录（无SPF记录、无DKIM签名、无DMARC策略）。
`temperror`	临时故障（DNS超时等）。稍后重试。
`permerror`	永久错误（格式不正确的记录、DNS查询过多等）。
`policy`	消息通过身份验证但未通过本地策略检查。

属性类型

每个结果可以包括属性/值对来提供详细信息：

属性	描述
`header.d`	DKIM签名域（`d=`标签）
`header.s`	DKIM选择器（`s=`标签）
`header.b`	截断的DKIM签名哈希（前8个字符）
`header.from`	消息`From:`头中的域
`smtp.mailfrom`	信封发件人域（MAIL FROM）
`smtp.helo`	发件人使用的EHLO/HELO主机名

多个结果

单个Authentication-Results头可以包含来自多个方法的结果，以分号分隔。或者，可以存在多个Authentication-Results头（例如每个方法一个）。两种方法都有效。

信任边界

最关键的安全考虑：切勿信任来自外部来源的Authentication-Results头。攻击者可以包含声称dkim=pass和dmarc=pass的伪造Authentication-Results头。边界MTA必须要么删除所有与其自身authserv-id匹配的现有Authentication-Results头，要么仅信任其可以验证是在其自身行政域内添加的头。

常见错误

信任外部A-R头：最危险的单一错误。如果您的邮件系统不删除或忽略来自信任边界外的Authentication-Results头，攻击者可以注入伪造结果。始终删除使用您的authserv-id的入站A-R头。
未在边界记录结果：如果身份验证检查在边界MTA上进行但结果未记录在头中，内部过滤系统无法获得身份验证数据，必须重新运行所有检查（由于网络位置改变，可能产生不同结果）。
模糊的authserv-id：使用通用主机名（如"localhost"）作为authserv-id使得无法区分来自您系统的A-R头和来自其他系统的头。使用完整的MX主机名。
误读DKIM结果：单独的dkim=pass结果并不意味着消息是安全的。检查header.d值以查看哪个域对其进行了签名。对d=attacker.com的通过对声称来自example.com的消息毫无意义。这就是为什么DMARC对齐很重要。
忽略none结果：none的结果意味着未找到记录。对于SPF或DMARC，这意味着域未发布身份验证策略。此缺失应与显式fail不同处理。

可交付性影响

诊断金矿：排查可交付性问题时，Authentication-Results头是首先查看的地方。它确切告诉您接收服务器看到的内容：哪些检查通过、哪些失败以及原因。
驱动过滤决策：主要电子邮件提供商（Gmail、Microsoft、Yahoo）使用身份验证结果作为垃圾邮件过滤的主要输入。具有spf=pass、dkim=pass和dmarc=pass的消息到达收件箱的可能性明显更高。
ARC集成：ARC中的ARC-Authentication-Results头遵循与标准Authentication-Results头相同的格式，确保跨转发跳数的一致报告。
透明度：通过在消息头中公开身份验证结果，RFC 8601使电子邮件身份验证可观察和可调试。发件人可以要求收件人转发原始头以诊断身份验证失败。
机器可读：结构化格式使自动系统直接解析和作用于身份验证结果，启用可编程的可交付性监控。