在SPF记录中使用SOFTFAIL over FAIL是否被视为最佳实践？

或换一种说法，v=spf1 a mx ~all建议使用而不是使用v=spf1 a mx -all？RFC似乎没有提出任何建议。我一直偏爱使用FAIL，这会导致问题立即变得明显。我发现使用SOFTFAIL，由于没有人注意到，允许错误配置的SPF记录无限期地保留。

但是，我在网上看到的所有示例似乎都在使用SOFTFAIL。当我看到有关配置SPF 的Google Apps指导时，使我产生疑问的是：

创建包含以下文本的TXT记录：v = spf1 include：_spf.google.com〜all

发布使用-all而不是〜all的SPF记录可能会导致传递问题。有关Google Apps邮件服务器的地址的详细信息，请参见Google IP地址范围。

通过推动SOFTFAIL的使用，示例是否过于谨慎？是否有充分的理由使SOFTFAIL成为最佳实践？

好吧，当然，使用它不是规范的意图-softfail旨在作为一种转换机制，您可以在其中标记消息而不会完全拒绝它们。

如您所见，完全失败的消息往往会引起问题；例如，某些合法服务会欺骗您域的地址，以便代表您的用户发送邮件。

因此，在许多情况下，建议使用不那么苛刻的软失败，这是一种不那么痛苦的方式，仍然可以得到SPF提供的很多帮助，而不会有些头痛。收件人的垃圾邮件过滤器仍然可以将softfail作为强力暗示，表明邮件可能是垃圾邮件（很多人这样做）。

如果您确信没有消息会来自指定节点之外的任何其他节点，那么请务必使用fail作为SPF标准。.但是正如您所观察到的，softfail肯定超出了预期范围使用。

-应始终使用NO EXCEPTION。不使用它是在向欺骗您域名的人开放。例如，Gmail有一个〜all。垃圾邮件发送者的欺骗gmail.com一直在地址。该标准规定，由于〜all，我们必须接受来自他们的电子邮件。我个人不遵循此标准，因为我意识到你们中的大多数人都错误地设置了SPF记录。我会像我一样强制执行所有，全部。 SPF语法 SPF错误

据我了解，Google不仅依靠SPF，而且还依靠DKIM以及最终的DMARC来评估电子邮件。DMARC同时考虑了SPF和DKIM签名。如果其中一个有效，则Gmail会接受该电子邮件，但是如果两个都失败（或软失败），则将明确表明该电子邮件可能是欺诈性的。

这是从Google的DMARC页面：

一条消息必须同时通过SPF和DKIM检查，才能使DMARC也失败。使用这两种技术的单次检查失败都会使邮件通过DMARC。

因此，我认为建议在软失败模式下使用SPF，以使其进入更大的邮件分析算法。

也许仍然使用softfail的原因是许多用户（正确或错误）设置了转发，例如从他们的工作电子邮件转发到家庭，如果启用了hardfail，这将被拒绝