换句话说，正在使用v=spf1 a mx ~all推荐使用v=spf1 a mx -all ？ RFC似乎没有提出任何build议。 我的select一直是使用FAIL，这会导致问题立即出现。 我发现用SOFTFAIL，configuration不正确的configurationSPFlogging是无限期的，因为没有人注意到。
然而，我在网上看到的所有例子似乎都使用了SOFTFAIL。 是什么让我质疑我的select是当我看到Google AppsconfigurationSPF的说明：
创build一个包含此文本的TXTlogging：v = spf1 include：_spf.google.com〜all
发布使用-all而不是〜all的SPFlogging可能会导致传送问题。 有关Google Apps邮件服务器地址的详情，请参阅Google IP地址范围。
推荐使用SOFTFAIL的例子是否过于谨慎？ 是否有充分的理由使得SOFTFAIL成为最佳实践？
那么，规范的目的不是用来代替它 – softfail的目的是作为一个转换机制，在那里你可以标记消息而不会直接拒绝它们。
正如你所发现的，失败的消息往往会导致问题; 例如，某些合法的服务会欺骗您的域名地址，以代表您的用户发送邮件。
因此，在很多情况下，推荐使用不那么严厉的软法，作为一种不痛不痒的方法，仍然可以获得SPF提供的许多帮助，而不会产生一些头痛; 收件人的垃圾邮件filter仍然可以采取softfail作为强烈的暗示，一个消息可能是垃圾邮件（很多人）。
如果你确信任何信息都不应该来自你指定的节点之外，那么通过一切手段，使用失败作为SPF标准打算..但正如你所观察到的，softfail已经超出了它的意图使用。
根据我的理解，Google不仅依靠SPF，还依靠DKIM，最终DMARC来评估电子邮件。 DMARC考虑到SPF和DKIM签名。 如果两者都有效，Gmail会接受电子邮件，但是如果两者都失败（或软失败），这将清楚地表明该电子邮件可能是欺诈性的。
这是从谷歌DMARC页面 ：
消息必须通过SPF和DKIM检查才能使DMARC失败。 使用这两种技术的单个检查失败都允许消息通过DMARC。
因此，我认为build议在softfail-mode中使用SPF，以便允许它进入更大的邮件分析algorithm。
– 应该永远使用没有例外。 不使用它是打开你自己欺骗你的域名。 例如Gmail有一个〜所有。 垃圾邮件发送者一直在欺骗gmail.com地址。 该标准说，我们必须接受来自他们的电子邮件因为所有。 我个人不遵循这个标准，因为我已经意识到你们大多数人已经错误地设置了你的SPFlogging。 我强制所有，所有，就像我所有的一样。 SPF语法 SPF错误
也许softfail仍然被使用的原因是许多用户（正确或错误地）设置转发，也许从他们的工作电子邮件到家，如果硬启用，这将被拒绝