Cloudflare的邮件转发功能, 最终收件方怎么做到验证spf IP啊?

wawos

比如发件人: 123456@qq.com发给cf上托管的域名邮:b@abc.com (它在CF上设置的是 转发给c@gmail.com),


qq发给abc.com后, CF收到后就是CF自己的服务连接gmail发给c@gmail.com了呀,

这时连接gmail发信的IP不就与发件方123456@qq.com的spf记录里允许的IP完全不一致了吗?


gmail为什么会信任 "发件方 123456@qq.com", 因为正在发信的IP确实与它spf记录完全不一样了啊

wawos

没搞懂邮件收件方判断spf的规则是什么?

smallnet

怎么感觉论坛没人气了，以前随便一个帖子都有人回复，现在正经提问都没人回复了。

牛魔王

当 Cloudflare 接收到来自 QQ 邮箱的邮件时，实际上是它将邮件从自己的服务器转发到 Gmail。这个过程中，原始发件人 123456@qq.com 和转发方 Cloudflare 的服务器的 IP 地址是不一致的。

SPF 如何运作？
SPF 是通过检查邮件是否来自被授权的邮件服务器来防止伪造发件人。为了 SPF 能验证通过，必须确保发件人域（在这个例子中是 qq.com）的 SPF 记录允许发送邮件的服务器 IP 地址。

你提出的困惑：
Cloudflare的转发和 SPF 校验：
由于 Cloudflare 在邮件转发过程中，邮件的 "发件人"（即 123456@qq.com）并没有变化，但是邮件实际的发送方变成了 Cloudflare 的 IP。这样，123456@qq.com 的 SPF 记录会认为 Cloudflare 的 IP 是未经授权的，因为它不在 qq.com 的 SPF 记录中。

邮件通过 Gmail 接收：
Gmail 本身在接收到邮件时会基于发件人域的 SPF 记录进行检查。但问题是，邮件并不是直接从 qq.com 服务器发送到 Gmail，而是经过了 Cloudflare 的转发。这样，Gmail 不会直接使用 qq.com 的 SPF 记录来验证邮件，而是会执行一系列验证来确保邮件的合法性。

邮件转发如何处理 SPF 问题？
很多邮件服务（包括 Gmail）采用了几种方法来处理邮件转发时 SPF 检查失败的问题：

DKIM（域名密钥识别邮件）：
在转发的过程中，原始邮件的 DKIM 签名会保留。即使 Cloudflare 的服务器发出了邮件，Gmail 会验证 DKIM 签名是否与 qq.com 域匹配。如果匹配，Gmail 会信任该邮件，因为 DKIM 签名代表了邮件的真实性。

DMARC（域名基于消息认证、报告和一致性）：
如果 qq.com 设置了 DMARC 策略，并且该策略允许邮件在没有通过 SPF 的情况下使用 DKIM，那么即使 SPF 失败，Gmail 也有可能会根据 DMARC 规则来允许邮件通过验证。具体取决于 qq.com 的 DMARC 配置。

SPF 修复（SRS - Sender Rewriting Scheme）：
许多邮件转发服务（例如 Cloudflare）通过使用 SRS 来修改邮件的发件人地址。这意味着转发服务器会修改发件人的地址，从而绕过 SPF 检查，确保邮件看起来像是从合法的服务器发送的，而不是原始的发件人。这样，邮件的 SPF 检查就会通过，因为邮件的“发件人”会被改成一个合法的发送地址。

总结：
Gmail 之所以信任 123456@qq.com，是因为它不仅仅依赖 SPF 进行验证。它也会使用 DKIM 来验证邮件的真实性，甚至在 SPF 校验失败的情况下，凭借 DKIM 或 DMARC 策略允许邮件通过。转发服务如 Cloudflare 通常会使用 SRS 或类似技术来避免 SPF 验证失败的情况。

所以，尽管邮件在转发时涉及到多个服务器，Gmail 仍然能够根据其他认证机制（如 DKIM 和 DMARC）来判断邮件的合法性，而不仅仅是依赖 SPF。

opentt

楼上ai就别闹了

SPF 记录有 include 字段的，可以把ip塞进去作为白名单的

参考rfc7208

shc

楼上没一个明白的

这个转发不是在RCPT TO阶段，而是在DATA阶段进行的，转发直接修改邮件头，因此最后收件方检测SPF用的是Cloudflare的域名和IP, 不是真实发件人的域名。

这是标准的SRS forwarding流程。