北京
“我们的邮件进垃圾箱了。”这张工单是最没操作价值的报修之一，因为“垃圾箱”只是表象，背后至少对应三种互不相关的故障，而针对其中一个的修复对另两个完全无效。真正有用的是排障顺序——先排除便宜、二元、可证伪的根源，最后才去碰那些模糊的。但大多数团队的做法正好相反：他们开始重写邮件主题行时，DKIM 密钥已经坏了六周。
系统管理员梳理的排障顺序如下。第一层是认证——SPF、DKIM 和 DMARC，零成本、可以免费检查、一个下午就能修好。接收方要么能验证邮件确实是你发出的，要么不能，结果没有中间状态。第二层是信誉，反映发送 IP 和域名的近期行为，修复速度慢但可量化。第三层才是邮件内容和收件人参与度，也就是消息里写了什么以及有没有人愿意收。这一层最模糊、最容易被过度归咎，也是你最不该一开始就查的。
动手之前，拿到一封真实掉进垃圾箱的完整邮件头。不是截图，不是转发——转发会重新签名并重写你需要读的所有部分。在 Gmail 里用“显示原始邮件”，在 Outlook 里看“查看邮件源文件”，让对方把全文粘贴给你。你真正要看的是这一行：Authentication-Results，里面 SPF 通过、DKIM 通过，但 DMARC 失败。这种组合是单次投递失败中最常见的 bug，一眼望去像全绿，其实是对齐出了问题。
如果拿不到真实邮件，可以用 DMARC 检查工具从 DNS 读取域名的三条记录，看到公开发布了什么，也足够开始排查。接着查 SPF 记录：用 dig +short TXT 拉出来，两个出错模式不是肉眼扫一遍就能发现的。最关键的陷阱是 DNS 查询次数上限——RFC 7208 第 4.6.4 节把每次 SPF 评估中的查询机制数硬限制在 10 个，包括 include、a、mx、ptr、exists、redirect，并且要递归计算每一条 include 展开后的数量。你的 SPF 记录可能只有两行，但某个供应商的一条 include 自己就能烧掉 5 次查询。一旦超过 10 次，接收方返回 permerror，大多数邮件系统会直接把邮件拒收或判成垃圾。
这是一场典型的慢动作宕机：团队新增一个 SaaS 服务，SPF 记录刚好从 10 次胀到 11 次，跑了多年的邮件认证悄无声息就停了，监控系统不会有任何告警。实际上系统管理员最近清理的一个域名，查询次数已经堆到 10 次里的 7 次，其中 5 次被一个一年没用过的供应商白白消耗。移除那条死掉的 include，一下子释放了多次查询，不用改一个字主题行，投递成功率就回来了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
