Defaults.Exposed › 修復 › Guides
轉發郵件 SPF 失敗——為什麼你修不好它，以及真正有效的辦法（2026）
發布於 2026-07-08
資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。
轉發郵件的 SPF 你沒辦法修好——轉發在設計上就會破壞 SPF，誠實的解法是能扛住轉發的對齊 DKIM。這是普查級別的規模問題：根據 Defaults.Exposed 對 261 百萬個網域的普查，在 138,927,207 個發布 SPF 的網域中，有 7,355,985 個單靠 Namecheap 的轉發 include 撑著，其中嚴格 SPF 的比例只有 <0.1%。
以下內容：為什麼你寫不出任何能扛住轉發的 SPF 記錄、為什麼 SRS 和 ARC 不是你能掌控的工具，以及真正管用的修法——用你自己的網域做 DKIM 簽名，作為你的 DMARC 通過項——外加唯一一種連 DKIM 也保不住的情况（會改寫郵件的郵件列表）以及該怎麼處理這部分殘余問題。
為什麼轉發會破壞 SPF？
接收方是對照 Return-Path（RFC5321.MailFrom）網域，而不是 From 標头來檢查 SPF 的。當你直接發信時，你伺服器的 IP 在你的 SPF 記錄裡，檢查通過。而當你的收件人把郵件自動轉發出去——轉到私人 Gmail、通過大學的郵箱別名、經由註冊商的轉發產品——是轉發方的伺服器在重新發送這封郵件，而它通常仍會把你的網域留在 Return-Path 上。最終接收方這時候問的是：這台轉發伺服器有沒有被授權寫進你的 SPF 記錄？
它沒有，而且永遠不會有：轉發方不是你選的，你根本不知道它的存在，同一封郵件明天經由另一個服務轉發，又會從另一個 IP 那裡失敗。SPF 只回答一個問題——“這個 IP 是不是 Return-Path 網域授權過的伺服器？”——對轉發郵件而言，真實答案就是不是。這個失敗是 SPF 按規範正常工作的結果，不是你的記錄寫錯了。
普查資料顯示這條路径有多主流：有 7,355,985 個網域授權了 Namecheap 的郵件轉發 include（spf.efwd.registrar-servers.com）——這是單個服務商的轉發產品，出自 139 百萬個 SPF 發布者——其嚴格 SPF 比例只有 <0.1%，強制執行 DMARC 的比例更是只有 0.2%。這種軟性模板不是粗心大意：轉發恰恰就是嚴格的 -all 會誤伤的地方，而這個產品本身就是轉發的服務商，自然照此發货。完整的限定符故事見我們的 ~all 與 -all 報告，各服務商的對比全景見哪家郵件服務商的 SPF 最強。
我能不能干脆把轉發方的伺服器加進我的 SPF 記錄？
不能——原因就是這整篇文章要讲的：
- 你沒法穷舉轉發方。 任何地方的任何收件人，都可以把你的郵件經由任何服務轉發出去。你的 SPF 記錄得列出你事先根本不可能知道的伺服器。
- 就算列出來也會背离初衷。 大型轉發服務為數以百萬計的客戶中轉郵件。把它們的 IP 段寫進你的記錄，它們任何一個使用者中轉的郵件——包括偽造者的——都會以你的名義通過 SPF。
同樣的邏輯也排除了“把限定符放寬以讓轉發生效”這條路：限定符根本不是轉發郵件失敗的原因，而且一旦啟用了 DMARC，它能改變的東西比大多數指南說的要少得多——見限定符資料。記錄本身不是這裡的杠杆。別再去拉它了。
SRS 和 ARC 呢——它們不是能修好轉發嗎？
它們確實在處理這個問題——但都不歸你部署：
| 機制 | 郵件被轉發時它做了什麼 | 誰掌控它 | 修好了你的 DMARC 嗎？ |
|---|---|---|---|
| SPF | 失敗：轉發方的 IP 不在你的記錄裡 | 你負責發布；轉發讓它失效 | 否 |
| SRS（發件人重寫方案） | 轉發方把 Return-Path 重寫成自己的網域，這樣它的重新發送能通過 SPF | 轉發方 | 否——SPF 的通過歸了轉發方的網域，和你的 From 對不上 |
| ARC（RFC 8617） | 轉發方對原始驗證結果加封；最終接收方可能信任這條封存鏈 | 轉發方和接收方 | 有時——由接收方自行決定，不由你決定 |
| 對齊的 DKIM | 簽名隨郵件一起傳遞，轉發之後依然能驗證通過，且帶著你的網域 | 你 | 是 |
資料與機制狀態截至 2026-06-29。
SRS 解決的是轉發方自己的 SPF 問題，不是你的：重寫 Return-Path 改變的是誰的 SPF 被檢查，而你的 From 標头——DMARC 真正保護的網域——完全沒被動過。ARC 是基礎設施運營方之間的信任決策。如果哪篇指南讓你作為網域所有者去“實施 SRS”，那它把你和轉發服務商搞混了。
我怎麼才能讓郵件扛住轉發？
讓對齊到你網域的 DKIM，成為你的 DMARC 通過項。DKIM 簽名是攜帶在郵件標头裡的密碼學證明：只要簽名內容沒被改動，不管郵件最終落到哪裡、經過多少台伺服器中轉，它都能驗證通過。DMARC 只需要一項對齊通過——SPF 或 DKIM——所以當轉發讓 SPF 這條腿失效時，對齊的 DKIM 依然能讓郵件保持已驗證狀態。
- 動 DNS 之前，先在 defaults.exposed 執行免費掃描。 它會顯示你有沒有 DKIM、是否在用你自己的網域簽名，以及你的 DMARC 現狀——這樣你修的是真正的缺口，而不是和你的 SPF 記錄較劲。
- 確認轉發確實是你的問題。 在受影響郵件的 Authentication-Results 標头裡，直發郵件通過 SPF，轉發的副本則會從轉發服務的 IP 那裡失敗。如果 SPF 和 DKIM 都通過但 DMARC 依然失敗，那你的問題其實是對齊——見 DMARC 失敗但 SPF 和 DKIM 都通過。
- 為你自己的網域啟用 DKIM 簽名，在每個發信服務上都這樣做——先是郵箱服務商，再是各個 ESP 和事務性發件服務。服務商默認往往用它自己的網域簽名，這樣對不上齊；你要的是
d=yourdomain。從如何修復 DKIM 開始，其中有 Google Workspace 和 Microsoft 365 的具體操作路径。 - 驗證的是對齊，而不只是通過。 簽名裡的
d=網域必須和你的 From 網域一致；在別人網域上的dkim=pass對你的 DMARC 毫无幫助。 - 別去動你的 SPF 記錄。 讓它對你的直發郵件保持準確——它仍然能驗證你大部分的流量，也仍然是你的第二條 DMARC 腿。只是別再想著讓它覆蓋轉發方。
- 重新掃描，然後有計劃地分階段推進 DMARC 強制執行——見下一節，以及 p=none 到 p=reject 的上線指南。
這種組合——SPF 加上靠對齊 DKIM 撑起的強制執行 DMARC——才是扛得住轉發的模式，而它很少見：在發布 ~all 的 77.5 百萬個網域中，只有 9.2%（7,116,774 個） 用強制執行的 DMARC 政策撑起了它，而在 261 百萬個已評分網域中，只有 3.87%（10,092,481 個） 完整具備 SPF + DKIM + 強制執行 DMARC 這三件套，資料來自普查（2026-06-29）。
會改寫郵件的郵件列表呢？
有一種轉發路径連對齊的 DKIM 也扛不住：會修改郵件內容的郵件列表——比如加個 [list-name] 的主題標簽、加個退訂頁脚、剥离某個附件。簽名內容一變，正文雜湊就對不上了，DKIM 也隨之失敗（dkim=fail: body hash did not verify 有它自己的專門指南）。此時 DMARC 的兩條腿都斷了，只有郵件列表自己能緩解這個問題（From 重寫、ARC 加封）。
這部分殘余問題，正是分階段 DMARC 強制執行存在的意義。帶著 pct 逐步推進 p=quarantine、同時觀察彙總報告，能讓你看清楚有多少真實郵件流量是經由會改寫內容的郵件列表——在 p=reject 政策開始把它們拒收之前看清楚。如果你的使用者重度依賴郵件列表，不要直接跳到 reject；但也別永遠停在 p=none。分階段上線指南 讲的就是怎麼逐步推進。
常見問題
轉發也會破壞 DKIM 嗎？ 普通轉發不會：簽名隨郵件一起傳遞，在最終接收方那裡依然能驗證通過。DKIM 只有在簽名內容在傳輸途中被改動時才會失敗——郵件列表的主題標簽和頁脚就是典型情形——這也是為什麼這部分郵件列表殘余問題是靠 DMARC 政策分階段來處理，而不是靠 DNS 裡的任何設定。
我要不要把限定符從 -all 換成 ~all，好讓轉發不再失敗？ 換限定符不會讓轉發方通過——限定符根本不是它們失敗的原因。有意思的是，Namecheap 的轉發 include——7,355,985 個網域，是普查中規模最大的專職轉發人群（2026-06-29）——其嚴格 SPF 比例只有 <0.1%：對轉發產品來說，軟性 SPF 可以說才是正確的模板。限定符實際會改變什麼，見~all 與 -all 報告。
為什麼我直接發信時 SPF 通過，一旦被別人轉發就失敗了？ 接收方檢查的是最後一台轉發伺服器的 IP有沒有被你的 Return-Path 網域的 SPF 記錄授權。直發：你的伺服器，在你的記錄裡，通過。轉發：轉發方的伺服器，不在你的記錄裡，失敗。你的記錄沒變——變的是發信的 IP。
我能自己搭 SRS 來解決這個問題嗎？ 只有當你就是轉發方本身時才行。SRS 執行在執行轉發的那台伺服器上，就算它真的在執行，得到的那個 SPF 通過也歸屬於轉發方的網域，和你的 From 對不上——你的 DMARC 仍然需要靠 DKIM 這條腿。
既然轉發反正會破壞 SPF，那 SPF 是不是就沒意義了？ 不是。大多數郵件都是直接送達的，在這種情况下 SPF 正如設計所愿地生效，它仍然是你 DMARC 的兩條腿之一。在普查的 261,086,232 個網域中（2026-06-29），有 138,927,207 個發布了 SPF——通過 SPF 修復頁面 讓你的記錄保持準確，剩下被轉發的那部分交給 DKIM 來扛。
把報告發給老板
如果你是在替客戶或雇主修這個問題，用證據收尾。等自定義網域 DKIM 上線、DMARC 也已分階段推進後，重新執行免費掃描，把評分報告轉發給企業負責人：帶日期、用大白話寫清楚，展示這個網域即便郵件被轉發也依然保持驗證狀態。這正是網路保險續保和下一份供應商問卷需要的凭證——一份記錄在案的前後對比，而不是一句“我打開了個什麼開關”。
檢查你的網域 → · DMARC 失敗但 SPF 和 DKIM 都通過 → · 修復 DKIM → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。