邮箱错误码排障树：先分级，再看证据，最后决定重试

邮件投递失败时，很多团队的第一反应是“收件服务器又抽风了”。真正靠谱的做法更像排障树：先分辨临时失败还是永久失败，再看对方给出的标准码、退信文本和 DSN 字段，最后才决定要不要重试、改内容、补认证或联系对方管理员。

RFC 5321 的 3-digit SMTP reply 只负责粗分：2xx 成功，4xx 临时失败，5xx 永久失败。RFC 3463 把诊断标准化成 X.Y.Z，RFC 3464 把这些信息放进 DSN；IANA 还维护了增强状态码注册表。换句话说，最能指导动作的不是“550”本身，而是“550 5.7.1”或“4.2.2”这样的组合。

一条实用的判断链

1. 先抓原始退信，别只看邮件客户端的摘要。
2. 找 3-digit reply：判断是 4xx 还是 5xx。
3. 找 enhanced status code：判断是地址、系统、网络、内容还是认证。
4. 找 DSN 字段：确认 Final-Recipient、Action、Status、Diagnostic-Code、Remote-MTA、Reporting-MTA。
5. 再看接收方原文，很多时候那句话比标准码更直接。

现象	更可能的分类	优先动作
4xx 反复出现，几分钟后又成功	临时容量或暂时繁忙	按退避重试
550 5.1.1	用户不存在或地址无效	核对地址、别名、路由
550 5.7.1	授权、策略或反垃圾拒绝	检查 SPF/DKIM/DMARC、SMTP AUTH、IP 声誉
554 5.6.0	内容或格式不符合要求	修正文案、编码、附件、HTML

为什么“先重试三次”不是好策略

重试应该按错误类型设计，而不是按习惯设计。4.2.x、4.3.x、4.4.x 适合带退避的重试；5.1.x、5.2.x、5.7.x 通常应该停下来，先修根因。把 permanent failure 继续重试，只会增加队列长度，降低信誉，还会让收件方觉得你在持续轰炸。

一个更稳妥的队列策略是：4xx 进入延迟队列，5xx 进入失败队列，5xx 里再按地址错误、策略拒绝、内容拒绝、认证失败分组。这样前台可以给用户明确反馈，后台也能做精细统计。

SPF / DKIM / DMARC 不是“装上就好”

很多退信其实卡在认证边界，但并不会直接写成“SPF fail”。转发、代发、第三方营销平台、共享 IP、域名对齐不一致，都可能让接收方用 550 5.7.1 之类的政策码来表达拒绝。SPF 关心授权 IP，DKIM 关心签名完整性，DMARC 关心对齐和策略执行；三者都需要结合发信路径来看。

如果你看到 Gmail、Microsoft 365 或其他大厂的拒收，要优先确认：发送域名、From、Return-Path、签名域、发送 IP、SMTP AUTH、TLS 是否一致。单看一个 pass / fail 不够。

可执行的排障工作流

1. 收集退信原文
2. 解析 SMTP reply 与 enhanced status code
3. 读取 DSN 的 Final-Recipient / Action / Status / Diagnostic-Code
4. 判断是地址问题、容量问题、网络问题、认证问题还是策略问题
5. 选择重试、修复或人工介入

建议把解析结果结构化后落库：

{
  "reply": "550 5.7.1",
  "action": "failed",
  "class": "5",
  "subject": "7",
  "detail": "1",
  "diagnostic": "delivery not authorized",
  "recipient": "[email protected]"
}

官方资料

排障时优先对照标准和官方帮助中心：

• RFC 5321
• RFC 3463
• RFC 3464
• IANA enhanced status codes registry
• Google Workspace SMTP errors and codes
• Microsoft Learn: 550 5.7.1 troubleshooting

把错误码理解成“可路由的证据”，排障效率会高很多：先分类，再定位，再动作。