我曾經親身體驗過 SPF 的教訓——在星期五下午將一個生產域名的 softfail 改成 hardfail，結果整個郵件流就這樣消失了。事實證明，我忘了幾個月前設定的一個事件平台。這個錯誤讓我學到一個關鍵的道理：在修改你的 SPF 記錄之前，你必須知道所有郵件的來源位置，並且要接受如果搞錯了的後果。

讓我來拆解一下真正重要的部分。SPF（Sender Policy Framework）基本上是你的域名告訴接收伺服器：這是我的 DNS TXT 記錄，列出哪些主機可以合法代表我發送郵件。當一封郵件到達時，接收端會根據 Return-Path 的域名檢查你的 SPF 記錄，評估你的機制 ip4、ip6、a、mx、include，並決定下一步。這個決策取決於一件事：你在最後設定的限定符——你選擇的模式。

這裡的核心差異常常讓人搞混。softfail (~all) 表示「這看起來未經授權，但也許沒問題——請謹慎處理。」通常會觸發垃圾郵件過濾，而不會直接拒收。hardfail (-all) 則表示「只有我列出的主機是合法的——其他全部封鎖。」這是明確的，當它與 DMARC 一起配合時，會真正拒收該郵件。

我把它比作測試階段與正式運行。softfail 就像是在測試階段的謹慎模式，還在摸索中；而 hardfail 就像是在正式環境中切斷電源，並承擔後果。

我實務上採用的方法是有條不紊的：先用 ?all 來純粹觀察，等到你開始監控 DMARC 的彙總報告後，再切換到 softfail (~all)，最後在確認每個授權發件人都經過驗證且誤判率接近零時，才轉成 hardfail (-all)。我從不急於一時。我會列出所有清單——CRM、行銷自動化、客服系統、HR、帳單，甚至奇怪的設備如印表機。我會確認哪些供應商支援 DKIM 和 DMARC 的對齊，並記錄每次變更的負責人。

一個很快會讓你吃虧的事情是：SPF 有一個硬性限制——最多 10 次 DNS 查詢。我見過有人把 include 嵌套得太深，結果突然超過限制，導致一切崩潰。縮減 include，偏好使用 IP 範圍而非深層嵌套，並清理不再使用的服務。如果大量寄件者經常輪換 IP，建議用有 SLA 的穩定 include。

轉寄也是一個陷阱。它會破壞 SPF，因為連接的 IP 會改變。如果轉寄者使用 SRS（Sender Rewriting Scheme），你就沒問題；如果沒有，softfail 可能是阻擋友善火力的唯一方法。這也是我更依賴 DKIM 和 DMARC 對齊的原因。

我逐步優化的實務清單是：映射每個郵件伺服器和工作流程，驗證每個地方的 DKIM，啟用 p=none 的 DMARC 以收集數據，將 SPF 改為 softfail (~all)，並觀察至少兩個發送週期，調查每個未授權的發件人，並授權或封鎖，最後在正式推行 reject 政策並強制執行 DMARC 之前，先進行階段性推出。這最後一步——只有在所有合法發件人都已涵蓋時，才轉成 hardfail（-all）——是絕對不能妥協的。

我還注意到：Google 和 Yahoo 已經大幅收緊標準。郵件政策的執行現在結合了 SPF 模式、DKIM 簽名、DMARC 政策、內容分析與聲譽評分。這也是為什麼我從不單獨看 SPF。沒有穩固 DKIM 支援的 SPF hardfail，即使在轉寄頻繁的環境中，也可能影響投遞率。

我常見的最大陷阱包括：將 include 嵌套到超過 10 次查詢限制、忘記季節性供應商用你的域名發送郵件、以為 DMARC 可以拯救破碎的 SPF 設定、長期依賴 softfail 而攻擊者在適應，或在 DKIM 尚未全面部署前就轉成 hardfail。尤其最後一點——對安全性有幫助，但在大量轉寄的情況下，會嚴重影響投遞。

如果你目前還在 softfail，並且在考慮是否要轉，答案是：只有當你準備好了才轉。你已經驗證了每個發件人嗎？DKIM 是否已經對齊？你的誤判率接近零嗎？如果這三個都回答是，那麼轉成 hardfail 是合理的；如果不是，請耐心等待。softfail 不是永久狀態——它只是一個檢查點。