用户反馈验证码半小时后才收到，邮件头里 Received 有五行，最后一条与第一条的时间差了二十七分钟。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，投递链上某一跳队列堆积，或者接收方启用了灰名单延迟重试，重试间隔按分钟逐次拉长，看起来就像邮件丢了。
「邮件延迟排查」这类改动最怕改一半，回滚脚本先准备好，再动生产。改完顺手把文档补一句，省得下次自己重新推一遍。
grep -i '^received:' mail.eml # 从下往上读，比较相邻两跳的时间差 date -R
监控和日志的时间要对上，时区不一致会多绕很大一圈。临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。
动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
具体做法是，按时间顺序从下往上读 Received；找出耗时最长的那一跳；针对该跳换线路或加中继。
最后用这个标准收尾，定位到具体跳数后延迟降到一分钟内，验证码及时到达。