你转发给自己的邮件为什么落入垃圾箱

从旧账户设置自动转发到新账户，其中一些邮件会悄悄消失在垃圾箱里——不是因为你的提供商有问题，而是因为转发改变了谁在发送这条消息，但没有改变密码学证明。SPF 检查了错误的服务器，DMARC 判定翻转为失败，你发给自己的合法邮件被隔离了。解决方案有一个名字：ARC，在 2019 年的 RFC 8617 中定义。

转发为什么会导致我的邮件 SPF 失败？

因为 SPF 检查的是最后中继该消息的服务器，而转发会改变这个服务器。SPF（发送者策略框架）是一条 DNS 记录，列出允许为某个域发送邮件的 IP 地址。当 bank.com 向你发送收据时，接收服务器会检查：这是否来自 bank.com 授权的 IP？是的。通过。

现在将该收据从你的 Gmail 转发到新地址。谷歌的服务器中继它转发。最终接收服务器运行 SPF 检查并问：谷歌是否被授权代表 bank.com 发送？不，它不是。SPF 失败。谷歌自己的 Workspace 文档明确说明了这一点——转发的邮件会 SPF 失败，因为转发服务器不在原始域的 SPF 记录中。没有任何欺骗。检查只是在看错了一个跳跃。

那么为什么这会把它发到垃圾箱？

DMARC。单独的 SPF 失败曾经是可以接受的；DMARC 将其变成了一个判定。DMARC 将 SPF 和 DKIM 绑在一起，并告诉接收者当两者都失败时该怎么做：什么都不做、隔离或拒绝。到 2024 年，大型发件人别无选择——谷歌和雅虎开始要求任何向他们用户发送超过 5,000 条消息的人都使用 DMARC。

DKIM（另一个支柱）是烘烤在消息中的签名。理论上它能在转发时存活，因为它签署的是内容，而不是路线。实际上，任何接触消息的东西都会破坏它。邮件列表附加"你已订阅，点此退订"页脚、服务器改写主题行，甚至仅仅是行换行方式的改变——签名不再匹配，DKIM 也失败了。现在两个支柱都倒下了，DMARC 说失败，你自己的收据就在垃圾文件夹里。

什么是 ARC，它真的能解决这个问题吗？

ARC（认证接收链，RFC 8617）让诚实的转发者证明邮件在它接触之前已经通过了认证。转发服务器在消息上加盖一条密封记录，说"当这条消息到达我时，SPF 和 DKIM 是有效的——相信我对于你无法验证的这一段的证言。"最终接收者，如果它信任该转发者，可以推翻 DMARC 失败判定并投递邮件。

问题在于"如果它信任"。ARC 不是密码；它是一个信誉系统。接收者衡量 ARC 签名者是否是已知的、行为良好的运营者。谷歌既盖 ARC 标头，也从它信任的发件人那里接受它们，这就是为什么 Gmail 之间的转发通常能活下来，而通过某个古老大学中继的转发则不会。

如果你自己运行转发，有两个具体的举措有帮助。如果你的主机提供了 Server-Side Redirect / SRS 式的重写，请使用它，它会重写信封发件人，这样 SPF 检查就会针对你的转发者而不是原始域。并且优先在都支持 ARC 的提供商之间进行转发。如果你在合并账户，希望目标提供商为你处理认证方面的麻烦事，这正是 AI 邮件平台被构建来吸收的那种管道。

我什么时候应该停止责怪我的提供商？

当模式是"只有转发的邮件失败"时，提供商正在正确地履行其职责——问题在于协议。这里有个线索：打开丢失邮件的标头，查找 Authentication-Results 行。如果你看到 spf=fail 以及属于转发者而不是原始发件人的发送 IP，那就是 SPF 检查了错误的跳跃。如果 dkim=fail 出现在通过编辑邮件的列表或中继的邮件上，那是签名被破坏了，不是伪造。

令人不适的事实是，电子邮件认证在两个十年内一层一层地被加入到一个从未假定任何人会撒谎的系统上。SPF 在 2006 年推出，DKIM 在 2007 年，DMARC 在 2015 年，ARC 在 2019 年——每一个都在补上上一个打开的洞。转发是所有四个相互摩擦的接缝，而你的收件箱就是你感受到摩擦的地方。