在云通信领域，邮件系统的“可用性”从来不是简单的服务不宕机，而是邮件最终成功送达的概率。
很多团队刚开始做邮件平台时，关注的是 SMTP 能不能发出去；而成熟的系统关注的是：
网络抖动时怎么保证不丢
下游拒收时如何自动恢复
用户投诉时能不能追溯完整链路
本质上，这是一套围绕 重试机制、补偿机制、回执机制 的稳定性工程体系。
如果只做发送，不做稳定性闭环，系统规模一上来，投递成功率一定会崩。
下面从工程实践角度拆开讲。
一、邮件稳定性的核心问题是什么？
先说一个行业事实：
邮件失败，80%不是代码错误，而是外部环境问题。
典型包括：
- 目标服务器临时限流
- DNS解析失败
- TCP连接超时
- 对方灰名单策略
- 突发网络抖动
- MX节点不可用
这些都不是“永久失败”。
它们的本质叫：
可恢复失败（Transient Failure）
如果系统没有设计恢复能力，就会误判失败，直接丢邮件。
所以邮件系统的稳定性，本质就是：
如何把“短期失败”转化为“最终成功”
二、重试机制设计（Retry）
重试不是简单的“失败再发一次”。
成熟邮件系统里的重试，是一个完整调度系统。
1）重试必须分级
工程实践里通常会分三类：
临时失败（4xx）
例如：
421 try again later
450 mailbox busy
策略：
- 必须进入重试队列
- 延迟发送
永久失败（5xx）
例如：
550 user not found
策略：
- 不允许重试
- 直接失败
网络异常
例如：
- timeout
- connection reset
策略：
- 默认按临时失败处理
2）退避算法必须存在
很多系统的错误做法：
失败 -> 立即重试
这会导致：
- 被对方封禁
- 触发反垃圾策略
- 自己队列雪崩
正确做法是：
指数退避
例如：
第1次失败 -> 5分钟后
第2次失败 -> 15分钟后
第3次失败 -> 1小时后
第4次失败 -> 4小时后
大型邮件平台通常支持：
- 最大重试周期 24~72小时
- 最大重试次数限制
因为部分服务器灰名单会要求等待数小时。
3）重试队列必须独立
千万不要把重试邮件放回主发送队列。
正确架构：
发送队列
重试队列
延迟队列
死信队列
否则高峰期重试邮件会压垮新邮件发送能力。
三、补偿机制设计（Compensation）
很多工程师以为：
重试就够了。
实际上不够。
因为有些失败不是“发送失败”，而是：
状态写入失败
回执处理失败
数据丢失
这时候需要补偿机制。
1）发送成功但状态丢失
场景：
SMTP返回成功
数据库写入失败
系统认为失败。
用户看到“发送失败”。
实际上邮件已经到了。
这是典型的数据不一致问题。
解决方案：
必须设计：
发送日志持久化优先
典型做法：
写发送日志 -> 成功 -> 才真正发送
而不是反过来。
2）回执丢失补偿
回执系统是异步的。
可能发生：
- webhook处理失败
- MQ消费失败
- 回执解析异常
如果没有补偿，就会丢失用户最关心的状态。
成熟系统一定有：
回执重放机制
比如：
回执事件保留7天
允许重复拉取
支持补偿同步
3）投递链路补偿扫描
大平台通常会做一个：
后台巡检任务
定期扫描：
发送成功但无回执的邮件
超过阈值就触发：
- 主动查询
- 标记异常
- 再次确认
这是大规模系统的常见做法。
四、回执机制设计（Delivery Feedback）
回执不是简单的“成功或失败”。
邮件系统里有多种回执类型。
1）SMTP投递结果
这是第一层：
服务器是否接收
注意：
这不代表用户收到。
只代表对方服务器接受了邮件。
2）退信回执（Bounce）
包括：
- 硬退信
- 软退信
必须解析：
- 错误码
- 错误文本
- 原始头信息
否则无法做地址质量管理。
3）用户行为回执
包括：
- 打开
- 点击
- 投诉
这些回执决定：
- 发信域名信誉
- IP健康度
- 后续送达率
成熟平台会把这些作为路由权重输入。
五、真正的工程级稳定性架构
如果用一句话总结邮件稳定性设计：
发送只是开始，状态闭环才是系统。
完整架构应该包含：
发送层
- 多IP池
- 多通道路由
- 并发控制
调度层
- 延迟重试队列
- 优先级控制
- 速率限制
状态层
- 全链路日志
- 发送ID唯一追踪
- 状态机管理
回执层
- bounce解析
- webhook重试
- 回执补偿
成熟系统里，真正复杂的部分从来不是 SMTP，而是：
状态管理系统。
六、一个行业真实经验
很多公司早期邮件系统只有：
发送接口 + SMTP客户端
等业务量上来后才发现：
- 成功率不可控
- 用户投诉查不到
- 邮件消失无法追踪
- 退信解析混乱
最后只能推倒重建。
而成熟云通信平台，从第一天就会设计：
Retry
Compensation
Feedback
因为在通信行业里：
不可恢复失败才是异常
可恢复失败是常态
结尾
邮件系统稳定性，本质不是“发得出去”，而是：
能在复杂互联网环境中，持续保证最终送达。
真正工程级的邮件平台，核心能力从来不是 SMTP 协议实现，而是：
- 重试调度系统
- 补偿数据机制
- 回执闭环体系
这三件事，决定了一个平台能不能支撑千万级甚至亿级邮件量。
