Defaults.Exposed

Defaults.Exposed › 修復 › Guides

換了郵件工具後 DKIM 失敗：CNAME 與選擇器遷移指南（2026）

發布於 2026-07-08

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

換工具後 DKIM 失敗，有兩個機械性的原因：你的 DNS 面板把新工具的 CNAME 目標弄壞了——通常是追加了你自己的區網域——或者舊工具的選擇器在其郵件排空之前就被刪除了。根據 Defaults.Exposed 對 261,086,232 個已評分網域的普查，只有 3.87% 的網域——10,092,481 個——凑齊 SPF+DKIM+DMARC 三件套。

修復順序：先掃描網域，然後用 dig 檢查每個新 CNAME 的已儲存目標——以你自己網域結尾的目標就是铁證。在權威網域伺服器上修好記錄，在把真實郵件切過去之前確認新工具能簽名並通過，並在舊工具的流量排空之前保持其選擇器發布。

為什麼換了工具 DKIM 就壞了？

DKIM 本身什麼都沒變——變的是你的選擇器。舊工具用它的選擇器簽名；新工具用另一套簽名，通常通過接入時新增的兩三條 CNAME 記錄委托。四個坑几乎解釋了所有遷移後的 DKIM 故障：

  1. DNS 面板把你的區網域追加到了 CNAME 目標上。 很多面板把任何粘贴進來的主機名當作相對名，悄悄存成 target.provider.com.yourdomain.com 而不是 target.provider.com。記錄存在，面板打著綠勾，可它什麼也解析不出來。
  2. 末尾點的困惑。 有些面板要求加末尾點（target.provider.com.）來表示“絕對名——別追加我的區網域”；另一些則把點當作非法輸入拒絕，自己處理絕對性。同一個粘贴值在這個面板是對的，在下一個面板就被弄壞。
  3. 舊工具的選擇器在切換當天就被刪了。 舊工具已簽名的郵件還會在重試隊列和轉發路径裡躺好几天；刪掉它的選擇器——或注銷舊帳戶，從而杀死其委托的 CNAME——會追溯性地弄壞那些郵件。
  4. 你在錯誤的網域伺服器上做了驗證。 如果遷移包含網域伺服器變更，修好的記錄可能只存在於一套 NS 上，而接收方還在查詢另一套。

在普查的 261 百萬個網域中，只有 51.84% 在掃描時呈現出可發現的 DKIM 金鑰（資料截至 2026-06-29）。

同一場遷移通常也會留下 SPF 殘骸——1,013,416 個網域（嘗試設定 SPF 的網域中約每 138 個就有 1 個）挂著兩條 v=spf1 記錄，這是換服務商時新增記錄而不是合併記錄的經典迹象。遷移的那一側有自己的指南：換了郵件服務商後 SPF 不工作了。

怎麼識別一條被弄壞的 CNAME 記錄？

別信面板——去問 DNS 它實際存了什麼。查詢新工具給你的每個選擇器的 CNAME 目標。一個示意例子，模仿 SendGrid 風格的委托選擇器（你的服務商的目標格式會不同）：

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

服務商要的是 s1.domainkey.u1234567.wl123.sendgrid.net——但儲存的目標以 .yourdomain.com 結尾。面板追加了區網域；那個名字什麼也解析不出來，接收方於是找不到金鑰。健康的版本：

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

（dig 輸出裡的單個末尾點是正常的——它標記完全限定名。）如果目標是對的，再往前跟一跳：dig TXT s1._domainkey.yourdomain.com +short 應當返回服務商的金鑰。CNAME 正確却答案為空，說明問題在委托的服務商那一側——完成他們的驗證步驟，或見 DKIM“no key for signature”做選擇器級診斷。

遷移操作手冊：之前、當天、之後

失敗的通常不是記錄——是順序。DKIM 遷移在切換時出事，是因為驗證發生在切換之後，那時真實郵件已經在失敗了。

階段做什麼過關條件
切換之前新增新工具的 DKIM CNAME（及退信網域記錄），然後證明它們沒問題：在你的網路之外 dig 每個 CNAME 的已儲存目標，完成工具自己的驗證步驟，並經新工具向你控制的郵箱發一封測試郵件測試郵件顯示 dkim=pass 且 d= = 你的網域——絕不把真實郵件切到未驗證的工具
切換當天把真實流量切到新工具。舊工具的一切都別碰：保留其選擇器、CNAME 和帳戶新工具的郵件在真實接收方處通過；仍流經舊工具的郵件繼續通過
排空之後盯著 DMARC 彙總報告，直到舊工具的選擇器不再出現（重試隊列和轉發會跑好几天——留出一周以上），然後再退役其記錄和帳戶舊選擇器在報告中消失 ≥ 7 天後才移除

加粗那一行是遷移成敗之所在：其中每項檢查都能在切換前几天完成，對在途郵件零風險。選擇器退役的具體操作——包括為什麼用空 p= 重新發布勝過刪除——見轮換操作手冊；這張表讲的是工具切換本身的排序。

切換之後怎麼修 DKIM？

  1. 動 DNS 之前，先在 defaults.exposed 執行免費掃描。 它讀取你的在線記錄，顯示接收方實際看到的東西——包括被追加了區網域的 CNAME 目標和无法解析的選擇器。
  2. 列出新工具需要的 DKIM 記錄。 從它的管理控制台找——郵箱服務商方面，Google Workspace 和 Microsoft 365 設定指南告訴你在哪裡；簡報和 CRM 工具在網域驗證一栏列出它們的 CNAME（見 Mailchimp/Brevo/Klaviyo 郵件 DMARC 失敗）。
  3. 用 dig CNAME <name> +short 檢查每條記錄的已儲存值，與工具要求的值逐字元比對。以你自己網域結尾的目標 = 被追加了區網域；重新录入，如果面板還在追加，就加上末尾點（如果面板拒絕點，則去掉它）。
  4. 在權威網域伺服器上驗證。 dig +short NS yourdomain.com，然後帶 @<那台網域伺服器> 重復 CNAME 檢查。如果遷移改了網域伺服器，兩套都要查——在委托傳播完成之前，接收方可能還在查詢舊的那套。
  5. 重跑工具的驗證並發一封測試郵件。 Authentication-Results 標头應顯示 dkim=pass 且 d= 等於你的網域——在工具默認網域上的通過對 DMARC 不對齊。
  6. 在舊工具的郵件排空之前保持其選擇器發布，然後有計劃地退役。之後重新掃描，並把修復 DKIM 頁面標出的其余問題逐一處理。

常見問題

我的 DKIM CNAME 到底要不要末尾點？ 完全取決於面板。那個點的意思是“絕對名——別追加我的區網域”；有的面板要求它，有的替你加上，有的直接拒絕。唯一算數的測試是保存後 dig CNAME <selector>._domainkey.yourdomain.com +short 的輸出：如果目標以你自己的網域結尾，說明面板追加了區網域，你需要那個點（或換一種輸入格式）。

切換當天能刪掉舊工具的 DKIM 記錄嗎？ 不能。舊工具簽名的郵件還在重試隊列和轉發路径裡，刪掉它指向的金鑰會追溯性地弄壞那些郵件。讓舊選擇器一直在線，直到它們不再出現在你的 DMARC 彙總報告裡——一周或更久——在那之前也別注銷舊帳戶。

DNS 面板和新工具都說“已驗證”，接收方却仍然 DKIM 失敗。怎麼回事？ 兩種常見情形：工具是對著快取的檢查結果驗證的，而權威網域伺服器提供的是別的東西（用 dig @<ns> 直接查詢它們）；或者 DKIM 通過了，但通過在工具的默認簽名網域上而不是你的網域上，DMARC 對齊照樣失敗。掃描能區分這兩種。

重叠期裡兩個工具的 DKIM 記錄能共存嗎？ 能——而且應該。DKIM 沒有單記錄規則：每個選擇器是各自獨立的 DNS 名稱，兩個工具的記錄並排共存互不冲突，這讓“保留舊選擇器到排空”的規則可以零成本執行。（SPF 恰恰相反——兩條 v=spf1 記錄會讓它作廢，所以 SPF 遷移指南讲的是合併。）

把報告發給老板

如果你是在替客戶或雇主做這次遷移，用證據收尾。新工具簽名且對齊之後，重新執行免費掃描，把評分報告轉發給企業負責人：帶日期、直白語言，證明切換之後網域的驗證依然完整。這正是網路保險續保和下一份供應商安全問卷需要的凭證——它把“遷移做完了”從一句話變成一份文件。

免費檢查你的 DKIM

看看新工具的選擇器能否解析——以及到底要修什麼——私密，僅網域所有者可見。

檢查你的網域 → · 換服務商後 SPF 壞了 → · 修復 DKIM → · 在 Google Workspace 設定 DKIM → · 僅使用彙總資料。資料在歐盟境內儲存和處理。