all 机制始终匹配。因此，它的限定符决定了什么 SPF 说的是到达它的连接地址。熟悉的结尾-all 、 ~all 、 ?all和+all是四种不同的身份验证语句，而不是四种有保证的传递操作。
较早的机制可能已经返回结果。在解释记录的最后一个单词之前，请阅读整个评估路径。 RFC 7208 §2.6 和 RFC 7208 §5.1 定义这些语义。
比较四个结局
使用-all ，到达所有接收的发送方都会失败。该策略表示该地址未获得评估身份的授权。对于~all ，它会收到softfail ，这是一个较弱的否定语句，而不是通过。对于?all ，它会收到中立的结果，这意味着该策略不会对该地址做出授权断言。使用+all ，它会收到通过。
在下面 RFC 7208 §4.6.2，不合格的 all 具有默认 + 限定符，因此也会通过。这使得一切成为一个必然的许可选择，而不是一个无害的终结者。一旦所有匹配，后续机制就无法提供额外的权限。
工作示例：保持授权发件人不变
使用综合策略 v=spf1 ip4:192.0.2.90 QUALIFIERall。对于来自192.0.2.90的连接， ip4 首先匹配并在每个结尾下返回 pass 。对于192.0.2.91 ，第一个机制不匹配。所选择的结局然后分别返回失败、 softfail 、中性或通过。
将~all更改为-all不会更改此装置中第一个地址的结果。它改变了尚未匹配的地址的处理方式。这就是为什么正确的准备问题是是否已识别出所有合法的发送路径，而不是公共发送者是否通过了一项测试。
政策包括 v=spf1 -all 不通过SPF授权任何地址。它可以表达非发送身份，但并不是每个接收者都必须丢弃在 From 中显示该域的每条消息的通用指令。
将结果和处理分开
SPF返回认证结果。接收者使用本地策略和其他证据来决定如何处理消息 RFC 7208 §8.4 和 RFC 7208 §8.5。失败并不能证明每个接收者都拒绝了该消息， softfail也不能保证在发送消息时会发出警告。
SPF softfail和中性不会成为通过SPF路径 DMARC。在下面 RFC 9989 §4.4.2, DMARC需要通过 结盟 其SPF路径，或单独的传递对齐 DKIM 小路。因此，尽管SPF失败，邮件仍可以通过DKIM传递DMARC 。相反， +all可以为地址生成SPF通行证，但不使其内容可信。
不要使用+all来消除错误仪表板。它授权每个到达该身份的地址并打破预期的限制。而是修复丢失的发件人、不正确的身份或损坏的依赖项。
区分政策结局和评估错误
佩默错误 和 temperror 不是失败的其他拼写。多种的 SPF记录、无效语法或超出处理限制可能会阻止正常评估。临时DNS问题可能会产生temperror 。将-all替换为~all不会修复到达结尾之前发生的错误。
在选择更改之前收集实际结果并进行跟踪。对于DNS中断，请调查依赖性和解析器路径。对于无法识别的合法发件人，请先确定其所有者和预期的信封身份，然后再授予其权限。
推出更严格的声明并提供证据
盘点常规、故障转移、 IPv6和不频繁发送路由。针对这些地址和未经授权的控制测试建议的策略。保留以前的记录，定义基于服务的回滚条件并在发布后验证收到的邮件。
如果转发是合法传送的一部分，请审查更广泛的身份验证设计，包括一致的DKIM和接收者行为。不要广泛授权未知转发器使每个间接SPF路径通过。
实用的外卖
选择您打算对其他不匹配的发件人进行的声明的限定符。首先验证库存和错误路径，然后将身份验证和交付作为单独的结果进行衡量。
记录下一个决定
对于合成赛程中的192.0.2.91 ，四种结局分别为失败/ softfail /中性/通过； 192.0.2.90仍然通过之前的 ip4 匹配。如果在正常结果之前发生语法或依赖性错误，则更改最终限定符不是修复。这些是分析控制流结果，而不是交付测试。