SPF 失敗與軟失敗的優缺點
問題
在我的 SPF 記錄中使用Fail 與 SoftFail的優缺點是什麼？
我在這個話題上發現了什麼
早在 2007 年，看起來知識淵博的人似乎說過 SoftFail 只是用於測試，並鼓勵在您正確設置所有內容後將其更改為拒絕（此處和此處）
這篇論壇文章稱 SoftFail“配置錯誤”，但隨後又說 Google 使用了它。我相信Google的最佳實踐勝過隨機論壇海報！我查了一下，確實，Gmail在他們的 SPF 記錄
~all中使用了 (a SoftFail) 。在發件人方面，電子郵件送達率專家似乎鼓勵使用 SoftFail：
失敗“更具侵略性
$$ than SoftFail $$並且已知會產生比它解決的問題更多的問題（我們不推薦它）。” —郵戳 SPF 指南
那是比較模糊的。
“我通常建議
~all為我的客戶發布記錄。發布 -all 並沒有很大的好處，有時郵件會被轉發。有一次我推薦 -all 記錄是當域被偽造為垃圾郵件時。域偽造可能導致很多退回郵件。退回郵件的數量可能足以導致郵件伺服器崩潰，尤其是那些使用者群較小的郵件伺服器。許多 ISP 會在退回退回郵件之前檢查 SPF，因此 -all 記錄可以減少域的反彈數量主人必須處理。”— 電子郵件傳遞顧問Word to the Wise
然而，網站管理員如何知道是否存在大量的域偽造？為最壞的情況做好準備並提前預測偽造不是最佳做法嗎？
在接收端，從事企業垃圾郵件過濾工作的Terry Zink 為 hard Fail提供了強有力的理由，以防止網路釣魚電子郵件通過，並表示大多數人使用 SoftFail 是因為與偽造電子郵件相比，組織更害怕電子郵件失去。SPF SoftFails 的偽造網路釣魚電子郵件實際上進入某人的收件箱的可能性有多大？
桑德拉，你已經找到了一個相關的問題，但在我看來，得分最高的答案並不適合你的問題。
讓我從您的最後一個問題開始：SPF SoftFails 的偽造網路釣魚電子郵件實際上進入某人的收件箱的可能性有多大？ 巨大的！結合 DMARC 隔離/拒絕政策和 Office 365、Outlook.com、Gmail、Yahoo 或其他主要主機上的接收郵箱，可能性很小。
您的第一個問題：軟故障 SPF 記錄的故障有哪些優勢。 正如您在自己的研究中提到的，一個缺點是轉發的電子郵件將被拒絕，除非退回地址（返迴路徑）被轉發器重寫。一個優點是可以更好地保護域免受欺騙，但僅限於最簡單的嘗試。
如上所述，SPF 的警告是它檢查了保存在郵件頭欄位中的SMTP信封發件人
Return-Path。實際的收件人不會知道這個欄位，因為大多數電子郵件客戶端只會向他們展示另一個欄位，即 headerFrom。例如：我發送帶有 header 的電子郵件From: Satya@microsoft.com，但我SpoofedYou@example.com用作信封發件人。即使microsoft.com發布了失敗的SPF 策略，它也不會失敗 SPF，因為example.com沒有發布 SPF 記錄。收件人只會看到來自 的電子郵件Satya@microsoft.com。這就是 DMARC 的用武之地。DMARC 要求身份驗證與標頭中使用的域對齊
From，無論是 SPF 還是 DKIM。這意味著信封發件人 (Return-Path) 和標頭中使用From:的域應該共享一個組織域。DMARC 只關心底層身份驗證機制（SPF 或 DKIM）的 PASS 結果，因此，對於 SPF，在這方面~all的-all處理方式完全相同。Terry Zink 發表了多篇關於 DMARC 的文章，其中一篇： 在 Office 365 中使用 DKIM 和 DMARC 增強電子郵件保護
有很多關於 SPF、DKIM 和 DMARC 的知識，這超出了這個答案的範圍。DMARC 不容易實現也不是完美無缺的，但它確實可以保護您的域免受欺騙，比僅使用 SPF 好得多。此外，這一切都取決於接收方以及他們如何處理 SPF 和 DMARC（如果有的話）。