最近我多次遇到这个问题，一直在努力确认问题的根源。
最近，我在一个使用 Kerio 发送电子邮件的域上看到了这种情况。我们将其域称为example.com。SPF 记录example.com如下所示：
"v=spf1 include:servers.mcsv.net include:isync.io ~all"
客户端收到的退回邮件在Diagnostic-Code响应标头下指定了以下内容：
spf [exmaple.com] with ip:[207.254.17.11]=did not pass
但是，您可以清楚地看到207.254.17.11SPF 记录允许isync.io，如下所示
v=spf1 a mx a:kmail.isync.io ip4:207.254.17.0/28 ip4:209.123.15.34 ip4:207.254.16.176/28 a:dispatch-us.ppe-hosted.com include:spf.em.secureserver.net include:spf.smtp2go.com -all
我尝试过或考虑过的事情
DNS 过期缓存
我已经使用 securitytrails 检查了所有相关记录，没有发现在相关的 SPF 验证期间有任何相关的变化。
SPF 记录查找限制（10）
的 SPF 记录的总查找次数example.com为 8，低于查找限制。
转发/验证错误服务器
我发现了一个博客文章和旧的 ServerFault 问题这表明 Google 有时会错误地使用客户端 IP 进行 SPF 检查，而不是使用将消息传递给 Google 的实际服务器，但在这种情况下，退回消息指定检查了正确的服务器。我能想到的唯一可能性是退回消息根本不是真的，SPF 验证实际上是针对客户端 IP 运行的，但退回消息是基于实际发送服务器的 IP 构建的。如果没有 Google 工程团队的某个人对此做出回应，我将无法验证这一点。
DNS 查找失败/Google SPF 验证错误
排除了上述所有可能性后，我只能得出一个推测性的结论：验证 SPF 记录时，DNS 查找偶尔会随机失败，或者 Google 的（显然是非标准的）SPF 验证流程中存在其他故障。我之前引用的博客文章推测，Google 的服务器实际上并没有在收到消息时对其进行验证，而是在稍后解析标头信息以尝试验证消息。事实上，客户端 IP 有时被错误地用于验证这一事实就是证据，众所周知，Google 对其服务采取了“规格见鬼去吧”的方法（请参阅永无止境的传奇故事autocomplete=off）。
我还遗漏了什么？
我的推测答案无法得到验证，而且如果不将答案简化为“有时 Google 不会按照其应有的方式处理电子邮件”，就很难向非技术人员解释。我还可以探索其他途径，要么让我的推测答案可信，要么找到其他解释？
* 快速脚注，在这种情况下example.com没有设置 DKIM；但是，我看到来自已正确实施 DKIM 的域的电子邮件存在相同的问题，并且退回消息表明两者都失败了，即使标题的另一部分显示 DKIM 通过了验证。
答案1
我不确定是什么导致了这个错误，但自从转移到新服务器后，我遇到了同样的问题，因为新服务器有正确的 SPF 记录。但是，我注意到只有在以纯文本形式发送电子邮件时才会发生这种情况。当服务器向 GMail 电子邮件地址发送 HTML 电子邮件时，不会出现问题。有点奇怪？（我本来想将其添加为评论，但网站不允许我这样做。）