我们有一个包含 11 个包含的域；SPF 验证失败也是如此，因为它超出了限制。大多数查找都是针对第三方资源的，因此扁平化 SPF 记录并不理想；我们宁愿确保在第三方更新他们的记录时动态更新。
其中一个查找是我们尚未找到文档的遗留值；所以我们不确定它是否是必需的......我们在删除它之前会四处询问，但它是一家有很多死胡同和裂缝的大公司，需求所有者隐藏在其中，所以检查这些东西需要时间。
我们认为对于超过 10 次查找的记录来说，超过 10 次查找只是一个问题；即使总数更多，在此之前的所有值都应该成功。因此，如果我们可以将未知查找移到末尾，这将降低我们关心的事物受到影响的风险。
这个假设是否正确/当总共有 10 个以上的 SPF 查找时，前 10 个 SPF 查找是否有效？
如果是这样，第 11 条记录是什么 - 即查找是先计算广度，先计算深度，还是未指定因此取决于提供者？
是的，查找限制是“随时”评估的，即深度优先。虽然规范中没有明确说明，但评估算法暗示了这一点。
原则上，您提出的建议是可行的。如果前十次查找应该为合法发件人产生通过结果，则该发件人确实会获得通过结果。但是，超过这十次查找的任何内容都将评估为permerror，而不是您记录中的任何或指令要求的失败或软失败结果。
-all~all