換了郵件服務商之後 SPF 就不好用了——遷移修復方案（2026）

發布於 2026-07-08

資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。

換郵件服務商之後 SPF 通常會壞掉，原因是新服務商的記錄被加在了舊記錄旁邊。兩條 v=spf1 記錄是一個永久性錯誤——SPF 會整體作廢。根據 Defaults.Exposed 對 261 百萬個網域的普查，有 1,013,416 個網域——大約每 138 個嘗試設定 SPF 的網域裡就有 1 個——正處在這種狀態。把它們合併成一條。

修法大約十分鐘：掃描網域看清楚遷移到底留下了什麼、列出你權威網域伺服器上的每一條 SPF 記錄、把它們合併成一條只包含新服務商的記錄，再用 dig 重新驗證。這篇指南會逐步讲解，外加大多數遷移都會忘記檢查的 DKIM 和網域伺服器問題。

為什麼遷移完成後 SPF 立刻就壞了？

因為新服務商的設定指南說“新增這條 TXT 記錄”——你照做了，加在了舊記錄旁邊。而這恰恰是 SPF 標準不允許的一件事。RFC 7208（§3.2，錯誤結果見 §4.5）規定每個網域只能有恰好一條 v=spf1 記錄；接收方發現兩條或以上時，必須返回 PermError，而不是去猜哪條才是權威記錄。PermError 意味著 SPF 作廢：不是舊記錄生效，也不是新記錄生效，而是根本沒有 SPF。

而且事情不止於此。DMARC 把 PermError 當作 SPF 這條腿的失敗處理，所以你的郵件現在完全依賴 DKIM。如果新服務商的 DKIM 還沒配好——遷移過程中很常見——你恰恰是在更換基礎設施的這個時刻發著未驗證的郵件，而這正是接收方審查最嚴格的時候。

這是換服務商時會作廢你防護的那個復制粘贴動作，而且並不罕見：根據 Defaults.Exposed 對 261 百萬個網域的普查（資料截至 2026-06-29），目前有 1,013,416 個網域發布著兩條或以上的 SPF 記錄——約占嘗試設定 SPF 的 139 百萬個網域的 138 分之一。關於双記錄陷阱的完整資料有自己的報告；這一頁讲的是操作層面的修法。

遷移留下了哪些殘留？

几乎每一次遷移後的 SPF 失敗，都是這五種殘留物之一造成的。按這個順序檢查：

留下了什麼	你會看到什麼	修法
舊的 SPF 記錄還留在 DNS 裡，和新記錄並存（兩條 `v=spf1` 記錄）	檢測工具報告“多條 SPF 記錄”或 PermError；SPF 整體停止工作	合併成一條記錄，刪掉其余的——見下方步驟
你唯一那條記錄裡還留著舊服務商的 `include:`	SPF 能用，但白白浪費 DNS 查詢次數，而且舊服務商的伺服器仍然能以你的名義發信	等郵件完全從舊系統排空後再移除它
從沒新增過新服務商的 `include:`	來自新服務商的郵件在接收方那裡 SPF 失敗	把它加進現有的那一條記錄——絕不要新建一條記錄
沒有為新服務商建立 DKIM 選擇器	`dkim=fail`，或者簽名來自服務商的默認網域；DMARC 沒有第二條腿	發布新的選擇器——見下方第 6 步
記錄只在舊的網域伺服器上更新過	問不同的人得到不同答案；間歇性失敗	在權威網域伺服器上修好那個區域；切換期間兩組都要核實

我該怎麼修？遷移檢查清單

先在 defaults.exposed 執行免費掃描。 它會讀取你實時的 DNS，告訴你是否有多條 SPF 記錄、缺少 include，或存在 DKIM 缺口——先診斷，再動手。
列出權威網域伺服器上的每一條 SPF 記錄。 dig +short NS yourdomain.com，然後針對其中一台跑 dig +short TXT yourdomain.com @<nameserver>。數一數有多少條以 v=spf1 開头的字串。唯一安全的數字是 1。
合併成一條記錄。 一條記錄，以 v=spf1 開头，包含你新服務商的 include 和你仍在用的任何其他發信方（開票工具、CRM、通讯平台），以一個 -all 或 ~all 結尾。舉例——舊的是 Google Workspace，新的是 Microsoft 365，正處在排空階段：
```
之前：  "v=spf1 include:_spf.google.com ~all"
        "v=spf1 include:spf.protection.outlook.com -all"

之後：  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
後續：  "v=spf1 include:spf.protection.outlook.com -all"
```
服務商的具體值和 DNS 面板的各種坑，見 Google Workspace 和 Microsoft 365 的設定指南。
刪除多余的記錄。 只合併不刪除等於沒修——PermError 是因為記錄條數導致的。
只在舊系統仍在發信時才保留舊服務商的 include——比如定時報表、一個舊的 CRM 連線器、一個被遗忘的郵箱。排空完成後就移除它：一個殘留的 include 會讓舊基礎設施繼續擁有以你名義發信的權限，而且每一個 include 都會消耗 DNS 查詢次數，逼近 SPF 硬性上限 10——至少已有 797,263 個網域因為超出這個上限而作廢了自己的 SPF（普查資料，2026-06-29）。
設定新服務商的 DKIM——但先別刪舊的選擇器。 新的選擇器負責簽新郵件；舊的選擇器必須繼續發布，直到所有用它們簽名的郵件都已送達，轉發也都處理完。完整操作見換工具之後 DKIM 失敗。
如果你連網域伺服器也換了，兩邊都要檢查。 DNS 遷移常常和郵件遷移一起進行。直接查詢新舊兩組網域伺服器（dig TXT yourdomain.com @old-ns 和 @new-ns）——在註冊商的委托完全傳播完成之前，一些接收方仍會問舊伺服器，所以修好的記錄必須在被查詢到的那一組伺服器上都存在。
重新執行掃描，確認 SPF 顯示為一條有效記錄且通過檢查。

SPF 實際檢查的是哪個網域？

接收方是對照 Return-Path（RFC5321.MailFrom）網域——也就是退信位址——來評估 SPF 的，而不是收件人看到的 From 標头。遷移之後這一點會有双重影響：在你設定自定義退信網域之前，新服務商可能會用它自己的退信網域；而且 SPF 在一個不屬於你的網域上“通過”，對 DMARC 毫无對齊意義。這個問題的修法是新服務商的 DKIM，用你的網域簽名。

同時在遷移和改名？

既換了服務商又換了網域？ 把它們當成兩項獨立的工作。新網域從第一天起就需要完整的一整套——SPF、DKIM、DMARC；用新網域郵件設定清單。舊網域要在轉發或回復流量還經過它的這段時間裡保持驗證，一旦停放，就要明確地鎖死它（而不只是放著不管）。一個帶著殘留、半壞 SPF 的舊網域，就是一個顶著你舊名字的偽造靶子。

常見問題

遷移期間我能不能同時保留兩條 SPF 記錄？ 不能。標準裡沒有寬限期這回事——從第二條 v=spf1 記錄出現的那一刻起，就是 PermError，而根據普查（2026-06-29），目前有 1,013,416 個網域正處於這種狀態。遷移安全的做法是：在過渡期用一條記錄同時攜帶兩個服務商的 include。

舊服務商的 include 該保留多久？ 保留到沒有任何郵件再經舊服務商發出為止——通常就是你的過渡窗口長度，几天到几周不等。留意任何仍經舊系統到達的郵件的 Return-Path；那部分流量一停，就移除 include，並重新核對你的查詢次數。

為什麼我修好之後，檢測工具還是顯示我的舊記錄？ DNS 快取會遵守記錄的 TTL，如果你換了網域伺服器，一些解析器可能仍在查詢舊的那組。直接在權威網域伺服器上用 dig TXT yourdomain.com @<ns> 核實——如果那裡的答案是對的，修復就已經完成，快取會慢慢跟上。如果某一組網域伺服器上的答案就是錯的，見 “SPF 記錄未找到”——真正的原因。

換服務商時需要改 DMARC 嗎？ 記錄本身通常不需要改——它寫的是你的報告郵箱和政策，不是你的服務商。但你的 DMARC 結果取決於你剛遷移的 SPF 和 DKIM：切換期間報告量可能會下降，先確認兩條腿都通過了再收紧政策。如果掃描顯示 SPF 這條腿仍在失敗，從修復 SPF 開始。

把報告發給老板

如果你是在替客戶做這次遷移，用證據來收尾。合併生效後重新執行免費掃描，把評分報告轉發給企業負責人：SPF、DKIM 和 DMARC 在新服務商上全部通過，用大白話寫清楚，帶日期。這是他們要歸檔用於網路保險續保和下一份供應商安全問卷的凭證——證明這次遷移讓網域的驗證水平比之前更好，而不是更差。

檢查你的網域 → · 換工具之後 DKIM 失敗 → · “SPF 記錄未找到”——真正的原因 → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。