Defaults.Exposed

Defaults.Exposed › 修復 › Guides

DKIM "No Key for Signature"：選擇器與金鑰轮換修復指南（2026）

發布於 2026-07-08

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

“No key for signature” 意味著接收方查詢了你 DKIM 簽名指向的 DNS 記錄——selector._domainkey.yourdomain——却沒找到金鑰：它從未被發布，或在轮換過程中被刪除。把簽名方實際使用的選擇器發布出去。根據 Defaults.Exposed 對 261,086,232 個已評分網域的普查，只有 10,092,481 個網域——3.87%——完成了 SPF+DKIM+DMARC 三件套。

修復只需一條 DNS 記錄，而線索藏在一個標头裡。從一封真實郵件的 DKIM-Signature 標头讀取 s= 和 d= 標簽，弄清你的郵件是用哪個選擇器簽名的，發布（或修復）那條確切的記錄，並优先使用 CNAME 委托讓服務商替你轮換金鑰。然後按下面的操作手冊進行轮換——這個錯誤通常意味著有人過早刪除了舊選擇器。

“dkim no key for signature” 是什麼意思？

每個 DKIM 簽名都攜帶兩個標簽，告訴接收方去哪裡獲取公鑰：d=（簽名網域）和 s=（選擇器）。接收方用它們拼出一個 DNS 名稱——s._domainkey.d——去查詢金鑰。“No key for signature” 意味著這次查詢空手而歸：簽名存在，但它指名的金鑰不存在。

這段措辭出現在 Authentication-Results 標头和 DMARC 彙總報告中——確切的表述因接收方而异，但有兩種形態需要區分：

結果字串（片段，广泛觀察所得）實際發生了什麼是暂時性的嗎？
dkim=temperror (no key for signature)DNS 查詢失敗或超時——接收方根本沒拿到答案是——重試往往就能通過；只有持續出現才需要調查
dkim=permerror (no key for signature)DNS 查詢成功，但答案是”沒有這條記錄”——選擇器確實不存在不是——在你發布之前，記錄一直是缺失的

偶發一次的 temperror 是 DNS 的”天气問題”。permerror——或者跨越多天、多個接收方反復出現的 temperror——意味著簽名指向的記錄不在你的域內。這正是本指南要解決的問題。

後果是：无法驗證的簽名等同於完全沒有 DKIM，於是 DMARC 只能退而依賴 SPF——而 SPF 在轉發場景下會失效。如果簽名存在但是無效而非缺失（正文雜湊、金鑰被弄乱），那是另一種故障——見 “DKIM signature not valid”。

如何找出我的郵件是用哪個選擇器簽名的？

別從服務商文件裡猜——從一封真實郵件裡讀出來：

  1. 從出問題的系統給你自己控制的郵箱發一封郵件（Gmail 位址就很好用）。
  2. 打開原始源碼（Gmail 裡是 “Show original”，Outlook 裡是 “View message source”）。
  3. 找到 DKIM-Signature: 標头並讀取兩個標簽：s= 是選擇器，d= 是簽名網域。一個示意性的例子：DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
  4. 接收方查詢的記錄是 s._domainkey.d——在這裡就是 mail2026._domainkey.yourdomain.com。自己核實一下：dig TXT mail2026._domainkey.yourdomain.com +short。答案為空 = 這個錯誤對每一個接收方都真實存在。
  5. 對每個發送系統重復上述步驟。一封郵件可以攜帶多個 DKIM 簽名——郵箱服務商、郵件通讯工具、工單系統——各自有自己的 s=/d= 組合和記錄。修好失敗的那個，並留意它的 d=：只有 d= 與你 From 網域匹配的簽名才對 DMARC 有幫助。

選擇器記錄為什麼會缺失？

几乎所有這類錯誤都出自四個原因——按這個順序排查：

  1. 它從未被發布。 簽名方被開啟（或默認開啟）時用了一個沒人新增到 DNS 的選擇器。新工具和會意外簽名的閘道常出這種事。
  2. 它在轮換過程中被刪除。 有人在用舊選擇器簽名的郵件還在傳輸途中、排隊重試或等待轉發時就把它”清理”掉了。那些郵件已經用 s=old 簽好名；刪除 old._domainkey 會追溯性地毁掉其中每一封。
  3. 你的 DNS 界面弄乱了 CNAME 目標。 許多服務商通過 CNAME 委托（s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com），而許多 DNS 面板會悄悄把你的網域追加到目標後面——存成 s1.domainkey.u123.esp.com.yourdomain.com，解析結果為空。要核實目標：dig CNAME s1._domainkey.yourdomain.com +short。工具遷移時同樣會踩這個坑——見更換郵件工具後 DKIM 失敗。
  4. 服務商轮換了，你的域沒跟上。 把服務商的金鑰當静態 TXT 記錄粘贴（而不是用他們的 CNAME），就會被他們的定期轮換甩下——簽名方換到了一個你從未發布的選擇器。在 261 百萬個普查網域中，只有 51.84% 在掃描時展示出可發現的 DKIM 金鑰（資料截至 2026-06-29）。

“no key for signature” 怎麼修？

  1. 動 DNS 之前，先在 defaults.exposed 執行免費掃描。 它讀取你現網的 DKIM、SPF 和 DMARC 記錄，展示接收方實際看到的樣子——包括選擇器是否可解析、CNAME 目標是否被弄乱。
  2. 發布簽名方實際使用的選擇器——是標头裡那個 s= 值，不是舊操作手冊裡寫的那個。從服務商的管理控制台獲取記錄（Google Workspace DKIM 設定 · Microsoft 365 DKIM 設定），並新增到精確的 s._domainkey.yourdomain.com 位置。
  3. 优先用 CNAME 委托，而不是粘贴 TXT 金鑰。 如果服務商提供 DKIM CNAME，就用它們：金鑰存在他們的域裡，轮換時你无需再碰 DNS——原因 4 從此不可能發生。郵件通讯平台几乎全都是這種方式；見 Mailchimp/Brevo/Klaviyo 郵件 DMARC 失敗。
  4. 在你的面板之外驗證。 在你網路之外的機器上執行 dig TXT s._domainkey.yourdomain.com +short（委托型選擇器則用 dig CNAME …）。面板顯示有這條記錄不代表什麼——域實際對外提供的可能是別的東西。
  5. 重新掃描並重發測試郵件。 Authentication-Results 現在應該顯示 dkim=pass。然後逐項處理掃描在修復 DKIM 頁面標記的其他問題——簽名通過但與你的 From 網域不對齊，DMARC 照樣失敗。

如何轮換 DKIM 金鑰而不触發這個錯誤？

轮換正是好端端的設定出問題的地方。防止出錯的規則是：只有在最後一封用某選擇器簽名的郵件排空之後才能刪除它——絕不在切換時刪。 已簽名的郵件比你想的活得久：重試隊列會跑好几天，轉發的郵件每次流轉都會被重新驗證。

步驟操作進入下一步前的關卡
1. 新增在舊選擇器旁邊發布新選擇器（s2._domainkey…）dig 確認它從外部可解析
2. 切換把簽名方指向新選擇器測試郵件顯示 s=s2 且 dkim=pass
3. 等待讓舊選擇器保持發布狀態，等在途、排隊和轉發的流量排空≥ 7 天；盯著 DMARC 彙總報告，直到舊選擇器不再出現
4. 退役移除舊金鑰——或者更好：用空的 p= 標簽重新發布它：“已退役”，而不是”從未存在”絕不在切換當下就開始這一步——過早刪除是 “no key for signature” 的头號原因

用 CNAME 委托的話，服務商會在自己的域內跑完這套完全相同的手冊，而你全程无感——這是委托方案最有力的論據。

常見問題

“no key for signature” 是 temperror 還是 permerror？ 兩種字串都存在：temperror 是 DNS 查詢失敗或超時——暂時性的，重試往往就沒了——而 permerror 意味著 DNS 明確回答”沒有這條記錄”。跨多個接收方反復出現的 temperror，最後通常也被證實是記錄確實缺失。用 dig 檢查，相信查詢結果，而不是標簽。

這個錯誤是否意味著有人在冒充我的網域？ 不是——冒充者不會用你的選擇器簽名。它意味著你自己的郵件帶著一個接收方无法驗證的簽名，於是被當作未簽名處理，DMARC 只能依賴 SPF。完整、對齊的驗證很罕見：在 Defaults.Exposed 普查的 261,086,232 個網域中，只有 10,092,481 個（3.87%）完成了 SPF+DKIM+DMARC 三件套（資料截至 2026-06-29）。

新選擇器一生效，我能直接刪掉舊的嗎？ 不能马上刪。用它簽名的郵件還在重試隊列和轉發路径上；刪除金鑰會追溯性地毁掉它們。舊記錄至少保留一周，盯著 DMARC 報告直到舊選擇器不再出現，然後再讓它退役——最好是改成空的 p=，而不是直接刪除。

服務商的檢查器說 DKIM 已設定好，可接收方還是報沒有金鑰。怎麼回事？ 几乎總是 CNAME 目標的坑：你的 DNS 面板把你的網域追加到了目標後面（…esp.com.yourdomain.com），於是記錄存在却指向空處。dig CNAME selector._domainkey.yourdomain.com +short 會原樣顯示儲存的目標——逐字元與服務商要求的做對比。

把報告發給負責人

如果你是在替客戶或雇主修這個問題，用證據來收尾。選擇器可解析之後重新執行免費掃描，把評分報告轉發給企業負責人：有日期、說人話、DKIM 已在正常驗證。這正是網路保險續保和下一份供應商安全問卷需要的材料——一項有效控制措施的證明，而不只是一張已關閉的工單。

免費檢查你的 DKIM

查看你的選擇器是否可解析——以及確切要修什麼——私密進行，僅網域所有者可見。

檢查你的網域 → · “DKIM signature not valid” → · 修復 DKIM → · 在 Google Workspace 設定 DKIM → · 僅使用彙總資料。資料在歐盟境內儲存和處理。