或者换句话说，使用v=spf1 a mx ~all比使用 更值得推荐吗v=spf1 a mx -all？RFC 简介似乎没有提出任何建议。我一直倾向于使用 FAIL，这会导致问题立即显现出来。我发现使用 SOFTFAIL，错误配置的 SPF 记录可以无限期地保留，因为没有人会注意到。
然而，我在网上看到的所有例子似乎都使用了 SOFTFAIL。让我怀疑自己的选择的原因是，我看到了Google 应用说明配置 SPF：
创建包含以下文本的 TXT 记录：v=spf1 include:_spf.google.com ~all
发布使用 -all 而非 ~all 的 SPF 记录可能会导致传送问题。有关 Google Apps 邮件服务器地址的详细信息，请参阅 Google IP 地址范围。
这些示例是否过于谨慎，大力推行 SOFTFAIL 的使用？是否有充分的理由使 SOFTFAIL 的使用成为最佳实践？
答案1
嗯，这当然不是规范的目的——软失败旨在作为一种过渡机制，你可以标记消息而不直接拒绝它们。
正如您所发现的，直接失败的消息往往会导致问题；例如，一些合法服务会伪造您的域地址，以便代表您的用户发送邮件。
正因为如此，在很多情况下，建议使用不太严厉的软失败，作为一种不太痛苦的方式，仍然可以获得 SPF 提供的大量帮助，而没有一些麻烦；收件人的垃圾邮件过滤器仍然可以将软失败视为邮件可能是垃圾邮件的强烈暗示（许多人确实如此）。
如果您确信不会有任何消息来自您指定节点之外的节点，那么请务必使用 fail 作为 SPF 标准。但正如您所观察到的，softfail 肯定已经超出了其预期用途。
答案2
据我了解，Google 不仅依赖 SPF，还依赖 DKIM 和最终的 DMARC 来评估电子邮件。DMARC 同时考虑了 SPF 和 DKIM 签名。如果其中一个有效，Gmail 将接受该电子邮件，但如果两者都失败（或软失败），这将清楚地表明该电子邮件可能是欺诈性的。
这是来自Google 的 DMARC 页面：
邮件必须同时未通过 SPF 和 DKIM 检查，才会未通过 DMARC 检查。使用任一技术，只要有一项检查未通过，邮件就可以通过 DMARC 检查。
因此，我认为建议在软失败模式下使用 SPF，以便使其进入更大的邮件分析算法。
答案3
答案4
也许软故障仍在使用的原因是许多用户（无论正确与否）设置了转发，可能是从工作邮箱到家里，如果启用了硬故障，这将被拒绝