Or put another way, is using v=spf1 a mx ~all recommended over using v=spf1 a mx -all? The RFC does not appear to make any recommendations. My preference has always been to use FAIL, which causes problems to become apparent immediately. I find that with SOFTFAIL, incorrectly configured SPF records are allowed to persist indefinitely, since no one notices.
All of the examples I have seen online, however, seem to use SOFTFAIL. What made me question my choice was when I saw the Google Apps instructions for configuring SPF:
Create a TXT record containing this text: v=spf1 include:_spf.google.com ~all
发布使用 -all 而不是 ~all 的 SPF 记录可能会导致交付问题。有关 Google Apps 邮件服务器地址的详细信息，请参阅 Google IP 地址范围。
推动使用 SOFTFAIL 的例子是否过于谨慎？是否有充分的理由使 SOFTFAIL 的使用成为最佳实践？
Sha*_*den 23
好吧，使用它当然不是规范的意图 - 软故障旨在作为一种转换机制，您可以在其中标记消息而不会完全拒绝它们。
正如您所发现的，完全失败的消息往往会导致问题。例如，某些合法服务会欺骗您的域地址以代表您的用户发送邮件。
正因为如此，在很多情况下推荐使用不那么严苛的软故障作为一种不那么痛苦的方式，仍然可以获得 SPF 提供的大量帮助，而不会出现一些令人头疼的问题；收件人的垃圾邮件过滤器仍然可以将软失败作为邮件可能是垃圾邮件的强烈暗示（很多人都这样做）。
如果您确信任何消息都不应该来自您指定的节点之外的节点，那么无论如何，请按照 SPF 标准的意图使用 fail .. 但正如您所观察到的，软故障肯定已经超出了预期用。
据我了解，Google 不仅依赖 SPF，还依赖 DKIM 并最终依赖 DMARC 来评估电子邮件。DMARC 考虑了 SPF 和 DKIM 签名。如果其中一个有效，Gmail 将接受该电子邮件，但如果两者都失败（或软失败），这将清楚地表明该电子邮件可能是欺诈性的。
这是来自Google 的 DMARC 页面：
邮件必须同时通过 SPF 和 DKIM 检查才能通过 DMARC。使用任一技术的单次检查失败都允许消息通过 DMARC。
因此，我认为建议在软故障模式下使用 SPF，以使其进入更大的邮件分析算法。
小智 7
-all 应始终使用，没有例外。不使用它就是让别人欺骗你的域名。例如，Gmail 有一个 ~all。垃圾邮件发送者一直在欺骗 gmail.com 地址。标准说我们必须接受他们的电子邮件，因为 ~all。我个人不遵循这方面的标准，因为我意识到你们中的大多数人都错误地设置了 SPF 记录。我强制执行 ~all，?all，就像我会 -all 一样。 SPF 语法 SPF 错误