刪除供應商 SPF include 並不總是與撤銷該供應商通過SPF的能力相同。另一種機制可以授權相同的來源位址。相反，一個包含項目可能支援多種業務服務，因此刪除它可能會中斷仍在使用的服務。
安全退休結合了所有權審查、政策依賴性分析和訊息測試。輸出應該解釋哪些權限消失了，哪些權限消失了以及原因。
設定退休範圍
確定受影響的確切信封域以及供應商支援的業務功能。檢查發票、預定報告、帳戶通知和季節性活動，而不僅僅是最近的大量發送。取得服務擁有者確認發送器已停用或其替代品已準備就緒。
保留目前的SPF值、 DNS TTL 和提供者配置參考。記錄建議移除的機制及其目的。包含中的品牌名稱可能是一條線索，但這並不能證明只有一個應用程式依賴它。
追蹤直接和間接授權
使用標準感知評估器檢查嵌套包含和重定向。確定是否可以透過另一項包含的策略（廣泛的策略）聯繫到供應商 ip4 或者 ip6 範圍，一個 a 或者 MX 機制，或共用重定向目標。在聲明撤銷之前記錄這些替代路徑。
也要確定依賴您要編輯的任何共用策略目標的其他網域。在下面 RFC 7208 §5.2 和 RFC 7208 §6.1，從中央移除一個機制 _spf 策略可以影響許多發送身份。更改範圍是依賴項集，而不僅僅是DNS編輯器中可見的主機名稱。
不要將目前包含擴展視為供應商地址的永久清單。管理政策可能會發生變化。使用提供者支援的資訊和您目前的架構來了解該機制旨在授權什麼。
透過重疊範例進行工作
綜合政策： v=spf1 ip4:192.0.2.0/24 include:_spf.vendor.example -all。假設說明性的 include 也授權192.0.2.10 。刪除包含不會阻止192.0.2.10通過，因為顯式 /24 範圍已經與它匹配 RFC 7208 §5.6 和 RFC 7208 §4.6.2。假設語法有效、選定一筆記錄且沒有較早的錯誤。
當兩個應用程式使用同一供應商包含時，會出現相反的問題。刪除它是因為遷移一個應用程式可能會破壞另一個應用程式。這些範例使用僅文檔值並假設包含行為；它們是推理裝置，而不是觀察到的提供者配置。
準備測試和恢復決定
在編輯之前，列出預計將繼續通過的服務、預計將失去授權的退休路徑以及將故意保留的任何重疊。透過受控帳戶和收件者進行測試。如果您無法使用已退役的服務，請記錄該限制並使用配置證據，而不是發明一個成功的負面測試。
批准確切的DNS更改和恢復條件。如果供應商涉嫌洩露，盲目恢復其包含可能會重新造成暴露。同意替代路線或明確的風險決策，而不是將回滾視為自動安全。
如果 TTL 減少有用，請提前規劃：降低 TTL 不會縮短已在先前 TTL 下快取的答案的生命週期。在下面 RFC 8767 §4，合格的服務過時行為可能會在 TTL 過期後保留並提供較舊的數據，因此 TTL 不是全局撤銷期限。更改後，檢查權威DNS和代表性遞歸答案，然後驗證剩餘的合法寄件者。
將SPF清理與完全卸載分開
SPF只是一種許可證面。供應商憑證、網域驗證令牌、委託DNS 、 DKIM 密鑰、應用程式整合和用戶帳戶可能需要單獨停用。刪除SPF包含不會撤銷這些資產。協調其所有者和批准，但不要聲稱僅通過SPF更改即可完成供應商下架。
對於SPF任務，保留準確的前後策略、依賴性發現、預期結果和實際測試證據。觀察足夠長的相關發送週期以涵蓋組織的已知工作；不要選擇通用觀察期並假設它適合所有服務。
以精確的語言接近
如果仍然存在重疊機制，則表示命名的包含已被刪除，而某些來源授權仍然存在。如果測試僅涵蓋活躍的寄件者，請明確說明。有用的關閉語句描述了權限變更和證據邊界，為下一個管理員提供了足夠的上下文，以避免重新引入已退休的依賴項。
記錄決定及其限制
對於重疊範例，將閉包寫為「包含已刪除； 192.0.2.10仍由ip4:192.0.2.0/24.”如果目標是完全撤銷原始程式碼，請確定並審查該範圍，而不是聲稱文字刪除成功。將不可用的測試記錄為不可用，並將建議的復原選項與已核准或已執行的復原分開。