验证邮件迟到时，最自然的反应就是再点一次“重发”。这往往让事情更乱：几封邮件同时到达，只有最新验证码有效，而你已经分不清哪次请求对应哪封邮件。
更好的方法是把投递看成一串节点。先确定最后一个肯定成功的节点，再检查紧接着的下一步。
先把现场记录下来
再次请求之前，先记下：
- 完整收件地址；
- 点击提交的时间；
- 服务或发件方名称；
- 页面是否提示发送成功；
- 这是第一次请求还是重发；
- 页面显示的有效期。
暂时不要关闭发送方页面。两分钟后发现地址拼错时，原表单里的提交值比记忆可靠得多。
核对地址，不要相信印象
把提交的邮箱和 GPTMail 当前显示的地址逐字比较。检查前缀、每一个数字、每一个点以及域名后缀。打开多个收件箱标签页或刚切换过域名时，最容易复制错地址。
然后到域名页面确认该域名仍然启用。地址格式正确，不代表域名当前一定能路由到 GPTMail。
如果网站在发送前就拒绝地址，那还不是投递故障。生成另一个受支持的地址再提交即可。
确认发送方真的开始投递
有些网站显示“发送成功”，实际只创建了后台任务。发送方可能仍在排队、限速或重试。
先等几分钟再重发。服务提供操作记录时，查看是否真的生成了验证请求。如果这是你自己维护的产品，应检查应用队列和邮件服务商事件，而不是只盯着收件箱刷新。
手动刷新一次，再找正确的邮件
按到达时间排序，并根据预期发件人和主题查找，不要只看预览里出现的品牌名。通知邮件和营销邮件可能来自完全不同的子域名。
几封验证码一起到达时，只使用最新请求。很多系统在生成新码的同时就会让旧码失效。
区分发送方问题和域名问题
换一个无关的邮件服务，向同一地址发送一封简短纯文本测试邮件。
- 测试邮件能到，说明接收域名正常，原发送方可能延迟、过滤了地址，或者根本没有完成交接。
- 两边都不到，应检查域名状态和 MX 配置。
- 某个服务商一直能到、另一个一直不到，应记录发件人、时间和退信信息后再报告。
自定义域名请按不靠猜测完成自定义域名 MX 设置检查。测试过程中不要随意修改 DNS，每改一次都会重新制造传播窗口。
理解常见 DNS 异常
解析器超时、权威服务器结果不一致、DNSSEC 验证失败或记录传播，都可能让一次 MX 查询暂时没有结果。“没有检测到记录”只是某个时间点的一次查询结果，并不证明记录从未存在。
直接查询权威 DNS，把实际目标和 GPTMail 显示的要求比较。两者一致就等待并重试；不一致则修改权威记录。
邮件到了，但验证码仍然失败
投递和验证是两个系统。验证码可能因为这些原因失败：
- 新验证码已经替代旧验证码；
- 邮件途中延迟，验证码已过期；
- 验证码属于另一个浏览器会话或账号；
- 复制时带上了空格；
- 目标页面与发送邮件的环境不同；
- 发送方自身状态或时间有误。
只请求一次新验证码，等待对应的新邮件，然后使用一次。仍失败时，把请求时间和邮件到达时间一起报告。
写一份简洁但有用的报告
有价值的信息包括收件地址、发件地址、主题、UTC 时间、第二个发送方能否到达，以及发送页面显示的准确错误。公开分享日志前删除验证码和私密链接。
“没收到邮件”很难排查；“14:03 UTC 请求，第二个发送方 14:05 到达，原发件方到 14:15 仍无邮件或退信”则能快速定位责任边界。
什么时候不该继续等
账号很重要而服务又提供其他验证方式时，直接使用替代方式。低风险注册则可以换一个新地址重新开始。不要把临时收件箱变成长期账号唯一的找回入口。
更完整的选择方法见临时邮箱怎么用才合适。