RFC 7372《邮件认证增强状态码》中文导读
非官方中文导读声明：本页为 IETF RFC 7372《Email Authentication Status Codes》 的非官方中文技术导读，按原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc7372.txt。
1. 为什么需要专门的认证状态码
当接收方因 SPF、DKIM 或反向 DNS 校验不通过而拒收邮件时，如果只回一个笼统的 5.7.1（“不允许投递”），发送方运维人员很难判断到底哪一环出了问题。RFC 7372 注册了一组增强状态码，让拒绝或延迟的原因可以被机器精确识别，从而缩短排障链路。
由于其中若干码位取代了 RFC 7208（SPF）原先推荐使用的码位，本文档同时更新了 RFC 7208。
2. 两个前置定义：passing 与 acceptable
文档在定义 DKIM 相关码位前先澄清两个概念，二者的区别是理解 X.7.20/21/22 的关键：
- passing（通过）：签名通过了 RFC 6376 定义的基本 DKIM 验证算法。
- acceptable（可接受）：在通过基本验证算法之外，还满足接收方所有本地策略要求——例如要求某些头字段必须被纳入签名覆盖范围、不接受部分签名（l= 限长）等。
也就是说，一个签名可能“通过”了密码学验证，却因不满足本地策略而“不可接受”。
3. DKIM 相关码位
| 码位 | 示例文本 | 关联基本码 | 触发条件 |
|---|---|---|---|
| X.7.20 | No passing DKIM signature found | 550 | 邮件中不存在任何通过验证的 DKIM 签名。 |
| X.7.21 | No acceptable DKIM signature found | 550 | 存在一个或多个通过验证的签名，但没有一个满足本地策略。 |
| X.7.22 | No valid author-matched DKIM signature found | 550 | 存在通过验证的签名，但没有一个的标识与 From 头中的作者地址匹配。这是 X.7.21 的一个特例。 |
原文注明，返回这三个码位意味着拒收行为与 RFC 6376 第 6.1 节的建议相悖——DKIM 本身并不主张“无签名即拒收”，因此使用这些码位属于接收方的本地策略选择。
4. SPF、反向 DNS 与多重失败码位
| 码位 | 示例文本 | 关联基本码 | 触发条件 |
|---|---|---|---|
| X.7.23 | SPF validation failed | 550 | SPF 校验产生 fail 结果且与本地策略要求相悖。用于取代 RFC 7208 第 8.4 节所述的 5.7.1。 |
| X.7.24 | SPF validation error | 451/550 | SPF 求值过程出错。用于取代 RFC 7208 第 8.6、8.7 节所述的 4.4.3 或 5.5.2。 |
| X.7.25 | Reverse DNS validation failed | 550 | SMTP 客户端 IP 的反向 DNS 校验未通过且与本地策略要求相悖。 |
| X.7.26 | Multiple authentication checks failed | 550 | 多项认证检查同时失败，接收方不希望或无法指明具体是哪一项。 |
5. 使用注意
这些码位描述的是接收方策略判定的结果，而不是协议本身的强制行为：是否因认证失败而拒收，完全取决于接收方策略。选择在何处（MAIL FROM 之后、RCPT TO 之后还是 DATA 结束后）返回这些码，也由实现决定；在 DATA 结束后拒绝可以获得最完整的判定信息，但会浪费传输带宽。
对发送方而言，把这些码位纳入退信解析规则，可以把“域配置问题”与“内容或信誉问题”快速区分开，是自动化排障的重要抓手。
参考：https://www.rfc-editor.org/rfc/rfc7372.txt