SPF 回答一個狹窄的問題：連接伺服器是否被授權使用特定SMTP身分中提供的網域？它不以收件匣中顯示的寄件者姓名開頭。這種差異解釋了為什麼更改錯誤的DNS記錄不會影響身份驗證問題。
For a normal non-empty reverse path, the relevant identity is the domain in SMTP 郵件來自。該地址可以是提供者管理的退回地址，而不是可見的作者。一個單獨的 HELO 檢查也可能發生。當 MAIL FROM 為空時， SPF會使用HELO網域和本機部分郵局管理員建構其 MAIL FROM 身分。這些身分規則定義在 RFC 7208 §2.3 和 RFC 7208 §2.4.
按照信封完成一次交付
想像一個應用程式發送發票。 SMTP連線來自192.0.2.44 ，其 MAIL FROM 為receipts@bounce.example.com ，郵件標頭顯示 From: billing@example.com 。這些是為文件保留的綜合值，而不是部署方案。
接收方根據bounce.example.com上的SPF策略評估連線 IP。它不會因為該網域出現在「寄件者」中就選擇example.com的SPF策略。父級的政策不會自動授權其子級。
假設bounce.example.com發布 v=spf1 ip4:192.0.2.44 -all。 ip4機制匹配，結果通過。如果連接位址是192.0.2.45 ，則不符；評估將達到-all並返回失敗。這兩種結果都表明發票是否真實或發送發票的帳戶是否已洩露。
確定您可以信任的證據
要求提供原始收到的訊息，而不是其顯示名稱的螢幕截圖。記錄接收者、接收時間、連線IP、評估的SMTP身分和SPF結果。在下面 RFC 8601 §7.1，接收者的可信身分驗證結果或日誌比任意發送者提供的標頭更有力的證據。
在下面 RFC 5321 §4.4, a delivered Return-Path 可以幫助揭示信封寄件人，但它是傳遞的痕跡，而不是您可以安全地編輯以更改SPF命令。網關、重新提交和轉送可能會建立另一個SMTP事務。診斷失敗接收方執行檢查的事務。
保留簡短的身分識別工作表：從網域中可見；來自網域的郵件； HELO名稱；連線IP； SPF記錄 當時觀察到的；結果;和任何對齊的 DKIM 結果。重点是要防止 一個記錄 編輯器成為診斷的第一步。
分別處理退回郵件和轉發
對於某些送達通知來說，空的反向路徑是正常的。不要將其視為缺失證據並替換可見的 From 域。捕獲HELO並套用空路徑規則。
轉發引入了不同的問題。下一個接收者看到轉發器的連接 IP，該 IP 可能未得到原始信封域的授權。重寫信封可以改變正在檢查的身份。重寫身分的通行證不會自動與可見作者對齊。調查完整路線和任何倖存的路線 DKIM簽名 而不是將每個貨運代理添加到您的保單中。
將SPF與業務決策連結起來
DMARC 新增身份比較：通過的SPF結果必須與作者域對齊以滿足其SPF路徑。即使SPF不滿足，單獨對齊的DKIM通行證也可以滿足DMARC 。 RFC 9989 describes that relationship.
對於發票範例，評估 結盟 根據適用的模式和組織域發現規則；不要假設共享文字後綴可以證明每個名稱空間中的對齊。嚴格的SPF對齊需要精確的域相等 RFC 9989 §3.2.10.2;寬鬆的組織域發現在中指定 RFC 9989 §4.10.2.
在批准更改之前，請詢問服務所有者該產品支援哪個信封身分以及誰控制其DNS 。保留先前的記錄，進行最小的授權更改，並透過受影響的路線發送新的代表發票。僅當觀察到的身份、結果和所需的一致性滿足預期結果時才關閉問題。
實用的外賣
從SMTP信封和連接 IP 開始。編輯SPF從未評估過的網域並不是修復，即使記錄檢查工具變綠也是如此。
保持決策的可重複性
對於發票固定裝置，將連接 IP 192.0.2.44 、MAIL FROM 域bounce.example.com和可見的作者域example.com保留為單獨的欄位。父級TXT編輯並不是已修復子級檢查的證據。對於轉送的副本，擷取新的事務行而不是轉送原始 IP。這些是假設的輸入，不是執行的SPF或交付觀察結果。