Defaults.Exposed › 報告
SPF ~all 與 -all：軟失敗還是硬失敗——139 百萬條記錄的選擇（2026）
發布於 2026-07-03
數據截至 2026-06-29 · 方法論 v7。 覆蓋 261 百萬個已評級域名的普查彙總數據。所有數據均為彙總——我們從不公佈任何單個企業的記錄。參見我們如何評級。
每一條 SPF 記錄都以某個 “all” 機制結尾——它是對來自你名單之外任何地方的郵件所下的裁定——而整個互聯網壓倒性地選擇了溫和的那個：在發佈 SPF 的 139 百萬個域名中，55.8% 以 ~all（軟失敗）結尾，相較之下只有 39.3% 以 -all（硬失敗）結尾。 一個字符之差，就把”拒絕偽造郵件”和”很可能是偽造郵件——但還是投遞吧”區分開來。哪一個適合你，取決於第二項設置——一項大多數域名所有者從未配置的設置。**
~all 和 -all 到底在告訴接收方什麼？
-all（硬失敗）： “拒絕來自其他任何地方的郵件。” 一個堅決的”不”。~all（軟失敗）： “來自別處的郵件很可能不合法——接收它，也許標記一下。” 一個聳肩。?all（中立）： “沒有意見。” 被 3.0% 的發佈者選用；徒有保護之名。+all： “任何人都可以冒充我發送。” 由 36,014 個域名發佈，比沒有記錄還糟——這個”歡迎門墊”問題有專門的報告。
那麼 ~all 就是錯的嗎？只有在它孤軍奮戰時才是——而它幾乎總是孤軍奮戰
軟失敗在現代有一個站得住腳的理由：Google 的發件人指南，以及大多數與之一致的投遞實踐，都匯聚到 ~all 搭配一條強制執行的 DMARC 策略（p=reject） 上。這種搭配在每一個評估 DMARC 的接收方——如今這包括所有主流郵箱服務商——都能提供與 -all 同等的保護，同時又不會硬性退回合法的轉發郵件，而那正是 -all 的典型受害者。在這種配置下，那個聳肩就有了牙齒：DMARC 提供了 SPF 拒絕下達的裁定。
但關鍵就在於這種搭配，而普查在這裡補充了配置指南給不出的信息：在互聯網上的 77,484,057 條軟失敗記錄中，只有 7.1 百萬條——約 11 分之一——背後有一條強制執行的 DMARC 策略。 對於其餘的 70.4 百萬個域名，~all 就是它字面上的意思。它們的記錄識別出了偽造郵件，然後揮手放行。
2024 年的強制規定難道沒有解決這個問題嗎？
沒有——而且這個區別比大多數報道所暗示的更為重要。Google 和 Yahoo 於 2024 年 2 月開始要求批量發件人進行身份驗證，Microsoft 隨後於 2025 年 5 月跟進：需要通過且對齊的 SPF 或 DKIM，外加一條 最低為 p=none 的 DMARC 記錄。這些強制規定並未走到要求強制執行那一步——一個擁有 ~all、一條 p=none 記錄和對齊 DKIM 的域名就完全合規，卻仍然可以被完全偽造。這些強制規定使文書工作變成了常態，而非保護。 那個未強制執行的中間地帶——合規、已發佈、可偽造——正是本次普查所測量的缺口，也是電子郵件安全領域中規模最大的群體。
那麼你的記錄應該以什麼結尾？
- 你會發送郵件且轉發很重要（新聞通訊、郵件列表、別名）：
~all搭配 DMARCp=reject在其背後——即上文推薦的搭配。 - 你從一個嚴格受控的環境中發送郵件：
-all可行，並且在記錄本身中就聲明瞭策略。請先梳理清楚你的發件方——在一條未梳理的記錄上使用嚴格結尾會破壞真實郵件，甚至更糟。 - 該域名從不發送郵件： 今天就用
-all加p=reject。沒有任何合法郵件需要保護，因此也就沒有什麼會被破壞。
無論你選擇哪種結尾，普查那一句話的教訓都成立：限定符的意義，只取決於是什麼在強制執行它。 你處在這個階梯的哪一級是可測量的。
常見問題
SPF ~all 和 -all 哪個更好？
沒有一個普遍更好。~all 搭配一條強制執行的 DMARC 策略是 Google 指南推薦的模式——在評估 DMARC 的接收方提供同等保護，又不破壞轉發郵件。-all 適合嚴格受控的發件方。單獨的 ~all——除了 11 分之一以外所有軟失敗域名所處的狀態——才是薄弱的選擇。
SPF 軟失敗是什麼意思？
~all 告訴接收方，來自未列出服務器的郵件很可能不合法，但仍應接收，通常帶著疑慮。只有當一條 DMARC 策略對失敗採取行動時，它才成為真正的保護；參見沒有 DMARC 的 SPF。
硬失敗 -all 會破壞我的轉發郵件嗎？
有可能：轉發會從轉發方的服務器重新發送你的郵件，而你的 SPF 並未列出該服務器，硬失敗會招致在 DKIM 或 DMARC 參與判定之前就被拒收。這種風險正是 ~all + p=reject 搭配存在的原因。
Google 和 Microsoft 現在要求 -all 嗎？
不要求。批量發件人強制規定要求對齊且通過的身份驗證，以及一條最低為 p=none 的 DMARC 記錄——不要求強制執行，也不指定具體的限定符。Google 對不合規批量郵件的拒收已經生效；Microsoft 一直在將失敗郵件投入垃圾箱，並正朝著徹底拒收邁進。合規不等於保護。
檢查你的記錄以什麼結尾——以及背後有什麼在支撐
兩次查詢，免費，30 秒內就能同時告訴你這兩點。如果你是那 70.4 百萬個未強制執行的”聳肩”之一，修復的方法是一條 DNS 記錄，而不是一筆購買。
檢查你的域名 → · 修復 SPF → · 修復 DMARC → · SPF 成熟度模型 → · +all 地圖 → · 僅彙總數據。數據在歐盟境內存儲和處理。