我公司的SPF记录格式如下：
“V = SPF1包括：_spf.google.com 〜所有一个MX IP4：XX0.0 / 23包括：spf.example.com所有”
因此，我们的SPF记录中间有一个“〜all”。他们在openspf.com网站上针对“所有”机制说了这一点：
此机制始终匹配。它通常在SPF记录的末尾。
因此，他们并没有说“全部”都应该放在SPF记录的末尾，而通常是在末尾。
在我们公司中，最近我们一直看到从SPF记录中列出的服务器发送的电子邮件中出现了一些软失败，但是我们的SPF记录通过了到目前为止我发现的所有验证工具。
我想知道的是，包含Google Apps（_spf.google.com）之后的“〜all”会立即导致解析停止并且无法识别SPF记录的其余部分吗？传递与软失败将取决于谁在解析它，以及它们如何处理SPF记录的特定实现？是否有任何理由拥有不在SPF记录末尾的“全部”机制？
是的，我知道我们可以更改SPF记录。这个问题更多的是要弄清这一切是如何工作的，而不一定是解决我们的具体情况。
Answers:
RFC 7208§5.1对此是明确的：all出现后，必须忽略其后的所有内容。
“ all”之后的机制将永远不会被测试。在“ all”之后列出的机制必须被忽略。当记录中存在“全部”机制时，无论术语的相对顺序如何，都必须忽略任何“重定向”修饰符（第6.1节）。
废弃的RFC 4408表示了几乎相同的内容。RFC的较新版本只是阐明了意图。
“ all”之后的机制将永远不会被测试。当存在“全部”机制时，任何“重定向”修饰符（第6.1节）均无效。
因此，符合SPF的实现将完全忽略first之后的所有内容~all。但是，这并不意味着每个实现都符合规范。特别是，这可能被认为值得澄清，恰恰是因为一个或多个实现不符合。
尚不清楚为什么在线验证工具不能捕获这种错误配置，但是如果您打算在首次all使用后不做任何事情，则应更正记录，因为正确的实现将忽略它。
“ v = spf1 include：_spf.google.com〜all a mx ip4：XX0.0 / 23 include：spf.example.com？all”
依次说：
“通过SPF记录传递的电子邮件
_spf.google.com对我们的域有效”“对该域的所有其他发件人进行软失败”
“来自我们A记录的电子邮件对我们的域有效”
“来自我们MX记录的电子邮件对我们的域有效”
“来自IP范围的电子邮件
x.x.0.0/23对我们的域有效”“通过SPF记录传递的电子邮件
spf.example.com对我们的域有效”“无法通过另一种方式验证来自我们域的所有其他发件人的电子邮件”
根据记录语法：
机制按顺序进行评估。如果没有机制或修饰符匹配，则默认结果为“中性”。
因此，对您而言，一旦它碰到了真正要解决的“其他所有问题”，它就应该忽略您指定的其余机制。
您的SPF记录应尽可能简洁。我非常怀疑您的整个/ 23网络应该为您的域发送电子邮件，也不应该为您的所有A记录发送电子邮件。也许是这样，但很可能不是。
干净的SPF记录应如下所示：
“ v = spf1 include：_spf.google.com include：spf.example.com mx -all”
基本上可以说_spf.google.com，spf.example.com和您的MX记录是您的域的唯一有效发件人...其他所有内容都应视为无效。