测试邮件收不到时，沿证据链定位

1. 用最小用例建立基线

创建一只新的测试收件箱，复制地址后立即触发一封内容简单、主题唯一的邮件。主题可包含本次测试编号，但不要放生产密钥或真实客户资料。

记录点击业务按钮、任务入队和服务商受理的时间。若简单邮件能到而复杂模板不能到，问题更可能在模板渲染、附件或内容策略，而非基础网络。

2. 确认应用真的生成了邮件

检查业务事件是否满足发送条件，例如账户状态、环境开关、去重规则和通知偏好。日志应显示最终收件地址，而不是只显示“邮件任务已创建”的泛化信息。

核对地址逐字一致，尤其是换过测试邮箱后应用仍缓存旧地址的情况。若应用没有消息记录，先修触发与模板参数，不要继续调查 DNS。

应看到的证据

• 业务事件 ID 与模板版本
• 规范化后的收件地址
• 消息创建成功或明确错误

3. 检查队列、重试与时序

异步邮件常卡在队列连接、工作进程、计划时间或重试退避。比较入队时间、首次执行、每次重试和最终状态，确认不是任务仍在等待。

若同一事件产生多封邮件，检查幂等键是否稳定、消费者是否在成功响应前超时。不要通过无限重试掩盖确定性模板错误，否则会让接收端出现重复信。

4. 阅读发送服务商事件

HTTP 2xx 通常只代表服务商接收请求，不代表收件服务器最终接受。继续查找 queued、sent、delivered、deferred、bounced 或 rejected 等事件，并保留服务商消息 ID。

4xx 类 SMTP 响应通常表示临时延迟，可按建议退避；5xx 多为永久拒绝，应先修正地址、身份或策略。若服务商完全没有对应消息，断点仍在应用与服务商之间。

5. 验证发件域名身份

检查 SPF 是否覆盖实际发送源，DKIM 签名域与 From 域是否符合配置，DMARC 对齐和策略是否与测试环境一致。DNS 刚变更时还要考虑 TTL 与不同解析器缓存。

不要只看控制台上的绿色标志，应读取具体邮件事件或原始头部中的认证结果。共享测试域名若频繁更换发送平台，也容易出现旧记录残留和超出 SPF 查询次数的问题。

6. 隔离模板与内容策略问题

先发送纯文本基线，再逐步加入 HTML、图片、链接和附件。若加入某一项后失败，就检查 URL 信誉、附件类型、编码、消息大小和未替换的模板变量。

主题与正文不要模拟钓鱼措辞，也不要使用真实凭证。验证码测试可以使用固定测试代码，并明确标注环境，以免测试人员误把邮件当作生产通知。

7. 排除接收端状态问题

确认测试收件箱倒计时尚未归零，并核对当前工具栏地址与发送目标一致。点击手动刷新；如果刚刚换过地址，旧信箱的邮件不会迁移到新地址。

真实邮件到达后，演示行应退出列表，只显示真实数据。打开详情时同时检查主题、发件人、到达时间、HTML 正文和纯文本兜底，不要只以列表预览判定模板完整。

8. 分析延迟、乱序与重复

使用同一时区比较业务触发、入队、服务商受理和接收时间。只有一个节点明显拉长时，才能把延迟归到该段；跨时区时间戳未统一会造成错误判断。

重发测试应更换唯一事件编号，同时保留旧消息 ID。若后发先到，检查队列优先级、并发消费者和供应商重试，而不是默认接收列表排序错误。

9. 用现象矩阵缩小范围

10. 何时升级，以及提供什么

完成上述步骤仍无法定位时，把时间线、目标地址、业务事件 ID、服务商消息 ID、最终状态和已排除项整理为一份最小证据包。敏感正文应删减，只保留复现问题所需信息。

联系 MSGTMP 支持时说明信箱创建和到期时间、是否换过地址，以及发送服务商记录的最终响应。不要发送密码、登录验证码或完整私钥；支持邮箱为 support@msgtmp.com。