邮件投递链路是什么
一封邮件从点击发送到进入对方信箱，要经过提交、排队、寻址、跨域传输、投递、读取六个阶段，每一段都可能单独失败。排障的关键是先把「卡在哪一段」定位清楚：客户端报错只说明提交阶段的结果，退信里的主机名与状态码才能说明后面哪一段出了问题。
基本信息
| 阶段数 | 提交、排队、寻址、传输、投递、读取六段 |
|---|---|
| 涉及协议 | SMTP、LMTP、IMAP、POP3、DNS 的 MX 查询 |
| 关键角色 | MUA 客户端、MSA 提交代理、MTA 传输代理、MDA 投递代理 |
| 常用端口 | 587/465 提交、25 中继、993/995 加密收信 |
| 排障入口 | 退信报告、邮件队列、服务端日志 |
| 规范 | RFC 5598、RFC 5321 §5 |
典型使用场景
- 用户报「没收到邮件」时，按链路分段确认卡在哪一环
- 自建邮件服务器上线前核对 MX、PTR、SPF/DKIM/DMARC 是否齐备
- 排查队列积压：区分是网络不可达、被对方限流还是本地磁盘满
- 分析退信报告：从 Remote-MTA 与 Diagnostic-Code 判断失败原因
- 邮件网关策略调整后验证投递时间是否有变化
沿链路逐段验证
沿链路逐段验证
dig +short MX example.net # ① 收件域是否有 MX，指向哪里
nc -zv mx1.example.net 25 # ② 目标 MTA 的 25 端口是否可达
mailq | tail -5 # ③ 本地队列是否积压，看失败原因
swaks --to user@example.net --server mx1.example.net # ④ 模拟一次投递看应答码
openssl s_client -starttls smtp -connect mx1.example.net:25 # ⑤ 确认是否支持 STARTTLS
dig +short TXT example.net # ⑥ 核对 SPF 等发信策略记录六阶段与故障点
| 阶段 | 协议与动作 | 常见故障点 |
|---|---|---|
| ① 提交 | MUA → MSA，587 或 465 | 认证失败、25 端口被云厂商封禁、附件超限 |
| ② 排队 | MTA 写入本地队列 | 磁盘写满、队列积压、进程重启丢队列 |
| ③ 寻址 | 查询收件域的 MX 记录 | MX 缺失或配置错误、DNS 解析超时 |
| ④ 传输 | MTA → MTA，25 端口 | 连接超时、被 5.7.x 策略拒收、灰名单延迟 |
| ⑤ 投递 | MTA → MDA 或 LMTP | 邮箱满、用户不存在、配额超限 |
| ⑥ 读取 | IMAP/POP3 客户端拉取 | 客户端配置错误、IDLE 连接断开频繁重连 |
发件方控制不了最后一跳：对方是否入库、是否被放进了垃圾箱，只有对方的日志或收件人反馈能说明。能拿到的客观证据是退信报告里的 host、Status 与 Diagnostic-Code 三个字段。
把「对方没收到」直接归因于自己的服务器，容易在错误方向上耗费大量时间：先索取退信原文或收件人的垃圾箱截图，确认邮件到底有没有到过对方系统。