邮件故障速查思路
邮件问题几乎都能按四层排除：网络连通、TLS 协商、认证与提交、对方反垃圾策略。顺序不能颠倒——跳过前三层直接怀疑黑名单，多数时候只是浪费时间。每一层都有对应的最短验证手段：连通用 nc 或 telnet，加密用 openssl s_client，认证用一次真实提交，策略则去对方信头或本地日志里找原因。
现象与最短验证路径
| 现象 | 可能原因 | 快速验证 |
|---|---|---|
| 能收不能发 | 提交端口未配或被网络拦截 | 测 587 与 465 连通性后再测认证 |
| 发信进垃圾箱 | SPF、DKIM、DMARC 未通过或被列黑名单 | 查对方信头里的验证结果行 |
| 客户端证书报错 | 证书域名不匹配或自签 | 用 openssl s_client 看证书链与主机名 |
| POP3 报信箱被占用 | 同一账号被其他会话锁定 | 断开其他客户端或等待超时释放 |
| IMAP 频繁重连 | 长连接被中间设备掐断 | 缩短保活间隔或改用加密端口 |
| 退信提示被策略拒 | 对方反垃圾策略拒绝 | 核对正反向解析、黑名单与发信认证 |
| 连接 25 超时 | 云厂商默认封禁 25 出站 | 改用 587 或 465 提交 |
四层排除法
四层排除法
nc -zv smtp.example.com 587 # ① 网络层连通性
openssl s_client -starttls smtp -connect smtp.example.com:587 -quiet # ② TLS 协商
# 认证后给自己发一封，确认提交成功 # ③ 认证与提交
# 收件方查看信头验证结果 # ④ 策略层
openssl s_client -connect imap.example.com:993 -quiet # 收信侧同样可手工验证典型使用场景
- 用户报告「对方收不到」：先确认是提交失败还是投递被拒，两者处理方向完全不同
- 新上线域名的投递率排查：核对 SPF、DKIM、DMARC 三条记录是否生效
- 客户端配置迁移：确认端口与加密方式是否匹配（587 配 STARTTLS，465 配隐式 TLS）
- 云主机发信异常：确认出口 25 是否被封禁，改走提交端口
- 批量邮件送达率下降：从退信内容与对方信头验证结果入手定位
排障必须看服务器日志与退信原文，而不是在客户端里反复改设置。真正的拒绝原因——发信认证失败、中继被拒、策略拦截——几乎只出现在服务端日志和退信正文里，客户端给出的提示通常只是笼统的一句话。
发信侧与收信侧要分开测：能收不能发说明收信链路正常，问题在提交或出站策略；能发不能收则要检查域名解析、邮箱容量与反垃圾设置。把两侧混在一起排查，容易在两个方向上同时浪费时间。