SPF、DKIM 和 DMARC 通过后仍进垃圾箱的原因

邮件身份验证：为什么配置了 SPF、DKIM 和 DMARC 仍然不够

该做的工作你都做了。你花了几个小时配置 DNS，从邮件服务商那里复制晦涩的文本记录，运行检测工具，最后所有项目都显示绿色通过。可为什么打开率还在下降？为什么密码重置、账单和提醒等事务邮件仍会进入垃圾箱，甚至彻底消失？

关于 SPF、DKIM 和 DMARC，有一个不太好听的事实：配置有效不等于信誉良好。证件是真的，也不代表醉酒的人能通过门卫检查。自 2024 年二月起，Google、Yahoo 和 Microsoft 等服务商不仅判断邮件是否像垃圾邮件，也更加严格地检查协议是否正确执行。如果控制台全是绿灯，业务收入却发出红色警报，你很可能撞上了基础身份验证之外的隐藏门槛。

群发邮件陷阱：门槛比你想象的更低

最危险的误解是：“我每天发送不到 5,000 封邮件，所以群发邮件规则与我无关。”

这句话有两处错误，而且即使 SPF、DKIM 和 DMARC 全部配置正确，也无法避开这个陷阱。首先，Google 可能按主域名汇总发送量。如果你从 news.example.com 发送 2,000 封营销邮件，从 app.example.com 发送 2,000 封事务邮件，再从 corp.example.com 发送 1,500 封内部提醒，你就属于群发邮件发送者。子域名的发送量会归入根域名统计。

其次，还要注意历史峰值。只要有一次超过 5,000 封邮件的门槛，例如黑色星期五促销或一次性数据库通知，Google 就可能长期将该域名视为群发邮件发送者。即使后来降到每天 50 封，也仍可能需要遵守最严格的要求。服务商政策会调整，实施前应查阅其最新文档。

Microsoft 的判断方式又有所不同。你的 SPF、DKIM 和 DMARC 记录可能无可挑剔，但 IP 使用时间和发送模式同样重要。刚启用新域名和新 IP 就立即发送 2,000 封邮件，Microsoft 可能用 4xx 响应限制流量，与 SPF 是否通过无关。对方还不了解这个发送者，仅这一点就足以触发谨慎处理。

SPF、DKIM 和 DMARC 的常见失效方式

许多管理员配置完 SPF、DKIM 和 DMARC，确认语法正确后便不再过问。但语法正确不等于实际有效。下面这些环节最容易出问题。

SPF：转发造成的验证黑洞

SPF 本质上是一份 IP 允许列表，例如它表示“允许 IP 1.2.3.4 代表 example.com 发送邮件”。在收件人没有设置自动转发时，它通常工作良好。

你把账单发送到 client@smallbiz.com，而客户把所有邮件转发到 client@gmail.com。Gmail 看到的是 smallbiz.com 的 IP，而不是你的 IP。Gmail 检查你的 SPF 记录时找不到 smallbiz.com，验证便会失败。如果只依赖 SPF，转发邮件可能进入垃圾箱或被拒收。邮件要顺利经过转发，DKIM 签名就必须在这一跳之后仍然有效，但这本身也不保证一定进入收件箱。完整配置方法请参阅我们的 SPF 记录指南。

DKIM：域名对齐问题

DMARC 会检查两个方面：SPF 或 DKIM 是否通过，DKIM 的标准见 RFC 6376；相关域名是否对齐。所谓对齐，是指 From 标头中的域名与技术标头中的域名一致，也就是 SPF 使用的 Return-Path 域名或 DKIM 使用的 d= 域名。

客服系统里常见这样的事故：你通过 Zendesk 或 HubSpot 等 CRM，以 support@yourcompany.com 的身份发信。退信由 CRM 处理，因此 Return-Path 是 bounces.zendesk.com，SPF 对齐失败。你又没有设置自定义 CNAME，因此 DKIM 使用 d=zendesk.com 签名，DKIM 对齐也失败。邮件在技术上已经通过身份验证，因为它确实来自 Zendesk，并由 Zendesk 签名，但 DMARC 看不到任何一个协议与贵公司的域名对齐。如果策略为 p=reject，邮件很可能被拒收。

10 次 DNS 查询上限

RFC 7208 规定，SPF 每次检查最多只能进行 10 次 DNS 查询。为大量使用 SaaS 工具的客户管理邮件系统时，这个限制尤其常见。仅 Google Workspace 在示例配置中就可能占用 4 次查询，再加入 Mailchimp、HubSpot、工单系统和人力资源工具：

每个 include: 都会触发一次 DNS 查询，而且被引用的记录还可能继续引用其他记录。总数超过 10 后，收件服务器会返回 PermError，实际效果相当于 SPF 未通过。原本想把所有发送服务都列完整，反而可能让身份验证失效。

SPF、DKIM 和 DMARC 之外的隐藏门槛

除了三大身份验证机制，还有一些没有醒目名称的技术要求，同样可以迅速阻断邮件。

FCrDNS，正向确认反向 DNS

每个发信 IP 都需要一条指向主机名的 PTR 记录，也就是反向 DNS；该主机名又必须有一条指回原始 IP 的 A 记录。这种闭环验证可以证明你控制着相关基础设施。如果在云端虚拟机上安装 Postfix，却没有设置 PTR 记录就开始发信，Gmail 可能把它视为可疑来源并立即返回 550 5.7.1。具体结果仍取决于服务商策略和发送信誉。

RFC 8058：一键退订

自 2024 年六月起，对于营销邮件，仅在正文底部放置退订链接可能无法满足大型服务商的要求。邮件还需要包含两个特定标头：

HTTPS 端点必须接受 POST 请求，而不是 GET。反垃圾邮件机器人会通过“点击”链接来扫描邮件。如果退订使用 GET，机器人可能误将真实用户退订。用户若找不到便捷的退出方式，则更可能点击“举报垃圾邮件”，使发送者逐渐接近 0.3% 的投诉警戒线。

0.3% 警戒线：信誉背后的经济账

即使 SPF、DKIM、DMARC、FCrDNS 和邮件标头都配置得十分完善，只要用户不喜欢你的内容，这些技术措施也无济于事。

最关键的指标之一是垃圾邮件投诉率。参考上限为 0.3%，也就是 3 次投诉对应每 1,000 封邮件。超过这一水平后，Google 可能严重限制投递，甚至屏蔽域名。具体计算方式和处置结果应以服务商当前政策为准。

Yahoo 的收件箱分母陷阱

Yahoo 可能按照进入收件箱的邮件数量计算投诉率，而不是以总发送量为分母。假设你发送了 1,000 封邮件。由于域名信誉已经不稳，其中 900 封进入垃圾箱，只有 100 封进入收件箱。只要一人投诉，计算结果就是 1/100 = 1.0%，相当于上述执行阈值的 3x。一次投诉就可能加剧恶性循环，而且很难恢复。

共享 IP 的“吵闹邻居”问题

即使 SPF、DKIM 和 DMARC 配置完全正确，在普通共享主机或廉价的“不限量”邮件平台上，你的邮件仍可能与数千名其他客户共用同一个 IP。只要其中一人发送加密货币诈骗邮件，Spamhaus 就可能把该 IP 列入阻止名单，你的邮件也会被拦截。你没有做错任何事，却要与有问题的邻居共同承担基础设施信誉。

周五检查清单：修正 SPF、DKIM 和 DMARC

1. 检查标头： 向个人 Gmail 邮箱发送一封邮件。打开邮件，点击三个点，然后选择“显示原始邮件”。找到 Authentication-Results。SPF 是否通过？DKIM 是否通过？dkim= 的域名是否与 header.from 的域名一致？如果不一致，就存在对齐问题。

2. 检查 FCrDNS： 运行 dig -x <your-sending-ip>。是否返回主机名？再运行 dig <that-hostname>。是否返回原始 IP？如果无法形成闭环，请先停止发送并修正 DNS。

3. 分离邮件流： 不要用主要企业域名发送营销邮件。人与人之间的通信使用 team@company.com，群发营销邮件使用 newsletter@marketing.company.com。如果营销子域名触及 0.3% 警戒线，主域名受到的直接影响通常较小，但子域名并不能在所有服务商处实现完全的信誉隔离。

4. 继续阅读： 如需了解修复信誉的具体方法，请阅读我们的邮件发送者信誉指南和关于邮件域名信誉的深入说明。

TrekMail 套餐

所有付费套餐：14 天试用，需要银行卡。Free：无需银行卡。价格和功能可能变化，购买前请核对当前方案。

结语

SPF、DKIM 和 DMARC 不是配置一次就能忘掉的任务，而是持续的运营要求。通过身份验证只是入场条件。要让邮件真正留在收件箱，还需要严格的域名对齐、良好的网络基础设施管理，包括 FCrDNS 和一键退订标头，以及能够降低共享 IP 邻居影响的信誉策略。不要只依赖默认设置，应持续掌控并检查自己的发信基础设施。

SPF、DKIM 和 DMARC 全部显示绿色通过，只代表你拿到了入场券。免费试用 TrekMail，真正掌控邮件身份验证。