RFC 8601《用于标示邮件认证状态的消息头字段》中文导读
非官方中文导读声明：本页为 IETF RFC 8601《Message Header Field for Indicating Message Authentication Status》 的非官方中文技术导读，按原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc8601.txt。
1. 用途与信任边界
邮件认证（SPF、DKIM、DMARC 等）通常在管理域（ADMD）的边界 MTA 上完成，而真正需要用到认证结论的是下游的过滤器和用户代理。RFC 8601 定义的 Authentication-Results 头字段就是这条信息通道：边界 MTA 把认证结果写入邮件头，下游软件读取并据此排序、过滤或向用户展示。它废止了 RFC 7601。
整套机制建立在信任边界假设之上：只有同一 ADMD 内部生成的该字段才可信。因此规范明确要求，在信任边界处必须删除随邮件从外部进入的、authserv-id 与本域相同的 Authentication-Results 头字段，否则攻击者只需自行伪造一行“pass”即可欺骗下游。
2. 字段的基本形态
字段值以认证服务标识（authserv-id）开头，用于标明是哪一个认证服务生成了这条结果；随后可选地跟一个版本号，再跟一个或多个“方法=结果”条目，每个条目后可携带若干属性三元组。
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=alice@example.com;
dkim=pass header.d=example.com header.s=sel1 header.a=rsa-sha256;
dmarc=pass header.from=example.com
若认证服务未执行任何认证，则使用特殊结果 none。多个 ADMD 依次处理同一封邮件时会各自追加一行，形成按处理顺序自上而下的记录栈。
3. 属性类型（ptype）与属性
每条结果后的附加信息用“ptype.property=value”三元组表达，ptype 说明该属性取自邮件的哪一部分：
smtp——取自 SMTP 会话（如 smtp.mailfrom、smtp.helo）；header——取自邮件头字段（如 header.from、header.d）；body——取自邮件正文；policy——表示由本地策略而非邮件内容得出的信息。
DKIM 是一个特例：其结果同样以 header 作为 ptype，但属性名对应的是 DKIM-Signature 头字段内部的标签，而非独立的头字段。例如 header.d 指签名头里 d=（签名域）标签的内容，而不是一个叫 “d” 的头字段。
4. DKIM 结果集
| 结果 | 含义 |
|---|---|
| none | 邮件未被签名。 |
| pass | 邮件已签名，签名为 ADMD 所接受，且通过了验证测试。 |
| fail | 邮件已签名、签名为 ADMD 所接受，但未通过验证测试。 |
| policy | 邮件已签名，但签名的某些方面不为 ADMD 所接受。 |
| neutral | 邮件已签名，但签名存在语法错误或因其他原因无法处理；本表未覆盖的其他失败也用它。 |
| temperror | 因可能是暂时性的错误（如临时取不到公钥）而无法验证，稍后重试可能得到最终结果。 |
| permerror | 因不可恢复的错误（如缺少必需头字段）而无法验证，重试也不太可能得到结果。 |
这里“为 ADMD 所接受（acceptable）”指通过了本地策略检查——例如策略可能要求签名域必须与 From 头字段中的 DNS 域一致，从而使第三方签名即便密码学验证通过也不被接受。
本版本相较前作新增注册了 DKIM 的 a（签名算法）与 s（选择器）两个可上报属性。上报算法尤其重要：RFC 8301 已废止 DKIM 中的 rsa-sha1，接收方需要能把这类签名与使用推荐算法的签名区分开。在 EAI 格式邮件中，d 与 i 属性的值可以是 UTF-8。
5. iprev 认证方法
文档还定义了 iprev 方法：对连接来源 IP 做反向 DNS 查询得到名字，再对该名字做正向查询，检查结果中是否包含原始 IP。它衡量的是“IP 与其 PTR 名是否自洽”，是一种弱信号——不能证明发送者身份，只能说明其 DNS 配置是否规范。规范提醒该查询会带来额外 DNS 负载，且可能被用于拒绝服务放大，需要设置超时与缓存。
6. 安全考量要点
原文安全考量部分列举的风险中，与部署最相关的几条是：伪造头字段（必须在边界删除外来同名字段）、误导性结果（结果只对生成它的 ADMD 有意义，跨域引用不可信）、字段位置（下游应只信任位于自身注入点之上的实例）、内部 MTA 列表维护不当会导致把外部主机误判为内部、以及内部主机被攻陷后可注入任意结果。
因此实现的正确姿势是：明确定义 authserv-id、在边界无条件剥离同名外来字段、只解析自身信任的实例、并把该字段视为“本域内部的处理记录”而非可跨域引用的凭证。
参考：https://www.rfc-editor.org/rfc/rfc8601.txt