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 匹配。如果在正常結果之前發生語法或依賴性錯誤，則更改最終限定符不是修復。這些是分析控制流程結果，而不是交付測試。