密码重置、登录验证和账单通知不是“发出去了就算完成”。应用收到发送 API 的成功响应，只表示服务商接受了请求；收件服务器是否接受、用户能否完成下一步，仍需要单独观察。
这篇文章讨论事务邮件的最小可靠链路，不提供某个邮件服务商的配置值，也不承诺任何收件箱位置或送达率。
先画出一封关键邮件的状态
为每类邮件记录可解释的状态，而不是一个 sent: true：
业务事件 → 待发送 → 服务商已接受 → 已投递 / 延迟 / 退信 / 投诉 / 抑制“已投递”也不等于“已读”或“一定在收件箱”。对登录验证码、重置密码等关键路径，更有意义的问题是：用户能否安全地重发、能否看懂等待状态、失败时是否有适当的支持或替代入口。
重发必须有频率限制和审计记录，不能变成枚举账户或滥发邮件的接口。不要为获得打开率而在所有事务邮件中加入侵入式追踪。
让发件身份可验证、可负责
先确定一组明确的发件域名、From 地址和退信处理路径；测试环境不得向真实用户批量发信。将营销、人工支持和产品通知分开，是为了能定位责任与影响范围，不是绕开收件方策略。
认证记录的具体值应以域名服务商和发送服务商的官方说明为准。Google 的发件人要求会随发送量和收件方规则变化；它说明了 SPF、DKIM、DMARC 的用途及发件域对齐要求，但不应被外推为所有邮箱服务的完整规则。
改 DNS 前，记录现有记录、变更人和回退时间；参阅《域名与 DNS 变更：先明确记录，再计划切换》。生产 API 密钥、重置令牌和完整收件地址不应出现在前端、仓库、截图或普通日志里。
把邮件服务的事件接回产品事实
每封关键邮件都应能关联回一个业务事件与模板版本。例如：
| 业务事件 | 用户期待 | 应保留的最小证据 |
|---|---|---|
| 请求重置密码 | 获得安全且有时限的操作路径 | 请求时间、过期时间、发送状态 |
| 支付失败 | 理解影响与可恢复动作 | 账单标识、订阅状态、通知状态 |
| 邀请成员 | 识别邀请者与目标工作区 | 邀请标识、接受或过期状态 |
存事件 ID、模板版本、发送域和状态类别即可开始排查；不要为图方便保存完整正文、令牌或邮箱地址。订单更新重试时，同一个业务事件也不该向用户重复发送多封成功通知，因此“需要发送”和“已提交给服务商”应分开保存，并在可重试的后台边界处理。
故障时先恢复用户的下一步
错误突然增加时，按最近变化缩小范围：发送服务状态、认证记录、模板版本、域名变更、退信类别和单一业务事件。不要先替换服务商或放宽所有验证规则。
用户看到的邮件要能回答三件事：这是哪个产品发的、为什么收到、下一步怎么做。真正紧急的安全提醒给出可识别的官方入口；不要要求回复密码或验证码，也不要用无法解释的短链催促点击。
发布后的复查
- 用受控测试地址检查邮件头与认证结果，不把一次成功当作长期结论；
- 确认退信、投诉与抑制状态不会继续触发同类邮件；
- 为关键流程演练“邮件没到”时的安全重发与支持路径；
- 将本次域名、模板或事件变更写入发布记录，并保留观察结果。
把事务邮件当作一条用户任务，而不是一次 send() 调用。这样即使接收方策略或外部服务变化，团队也有证据和恢复路径可用。