投递排查

测试邮件未到达：先找证据，再决定重发

“没收到”只描述结果，不能指出故障层。有效排查应从地址有效性开始，沿发送任务、服务商响应、收件轮询和正文渲染逐层推进。

2026 年 9 月 15 日 · 8 分钟阅读

先冻结现场，不要连续点击发送

连续重发会生成多个任务和消息编号，使“哪一封对应哪次操作”变得模糊。先记录当前收件地址、触发时间、测试环境、模板版本和应用日志中的任务 ID。

统一时间基准也很重要。浏览器、队列与服务商面板可能使用不同时区，最好换算成 UTC，并保留原始时间值。

从收件页面重新复制地址，不要凭历史记录手输。检查 @ 前后的字符、隐藏空格，以及测试脚本是否仍引用上一轮已经更换的地址。

临时邮箱具有有效期。若地址已经到期或换箱，旧令牌无法证明新邮件应该出现在当前页面；先新建地址发送一封最小邮件更可靠。

页面提示成功，不代表邮件任务已经执行。查看应用是否正确创建任务、消费者是否在线、重试是否耗尽，以及收件人变量是否在模板渲染前被覆盖。

如果任务停留在队列，收件系统无从观察。此时应修复消费者或配置，而不是在收件页面反复刷新。

找到消息 ID、接受响应、拒绝码或退信事件。“已接受”通常只表示下一跳接收了请求，并不等于最终进入目标收件箱。

遇到 4xx 临时错误，应按退避策略等待；遇到 5xx 永久错误，应先修正域名、收件地址、认证或内容策略。保留原始响应，不要只写“发送失败”。

等待一个轮询周期后手动刷新，并观察浏览器网络请求。若列表出现主题和发件人，说明邮件已经抵达；详情为空则应继续检查正文数据，而不是再查 DNS。

邮件详情可能提供 html_body 或 text_body。HTML 模板被隔离、远程图片不加载或脚本被清理，均不等于邮件未到达；要比较纯文本兜底和原始字段。

新建临时地址，发送固定主题、唯一事件编号和一句纯文本，不带图片、附件或复杂变量。如果最小邮件能到，再逐步加入 HTML、品牌资源和业务数据。

对照组能快速区分基础投递和内容策略问题。每次只改变一个变量，否则即使恢复成功，也无法知道真正原因。

结论至少包含故障层、直接证据、修复动作、复测样本和仍未解释的限制。不要只留下“重试后好了”，那无法防止同类问题再次出现。

如果正在处理当次故障，可使用投递排查实验台根据四项事实生成优先检查方向。