Defaults.Exposed › 修復 › Guides
“DKIM Signature Not Valid”——各種原因，按排查順序排列（2026）
發布於 2026-07-08
資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。
“DKIM signature not valid”有五個常見原因，最好按順序排查：內容在傳輸途中被修改、金鑰記錄被截斷、發布的金鑰與簽名方不一致、選擇器不對、脆弱的規範化設定。根據 Defaults.Exposed 普查（2026-06-29），在 261,086,232 個已評分網域中，只有 10,092,481 個（3.87%）同時具備 SPF + DKIM + 強制執行的 DMARC 這一完整三件套。
排查順序之所以重要，是因為最常見的原因根本不在你的 DNS 裡。先檢查是什麼在傳輸途中改動了郵件，再由外向內排查：金鑰記錄本身的完整性、它是否與郵件伺服器實際使用的簽名金鑰一致、選擇器，最後才是簽名設定。大多數無效簽名在第一步或第二步就修好了。
“DKIM signature not valid”到底是什麼意思？
每封經 DKIM 簽名的郵件都帶有一個 DKIM-Signature 標头，其中寫明網域（d=）、選擇器（s=）、郵件正文的雜湊（bh=），以及對正文雜湊和選定標头的加密簽名（b=）。接收方從 DNS 的 <selector>._domainkey.<domain> 處獲取你的公鑰，重新計算兩個雜湊，並校驗簽名（RFC 6376）。“Signature not valid”是檢測工具和標头的說法，意思是：驗證跑過了但失敗了——金鑰找到了，但數學沒對上。
最後這半句是診斷的金子。找不到你的金鑰的驗證方會說別的話——通常是類似 dkim=fail (no key for signature) 的標头——那是選擇器問題，見 DKIM“no key for signature”——選擇器與轮換的修復。而重新算出不同正文雜湊的驗證方通常會明說：body hash did not verify——Microsoft 報告為 dkim=fail (body hash did not verify)，Gmail 則常把同樣的診斷顯示為 dkim=neutral (body hash did not verify)。无論哪種，都指向內容被修改，見“body hash did not verify”——是什麼改動了你的郵件。動手之前先讀 Authentication-Results 標头裡的確切措辭：它告訴你手裡拿的是五個原因中的哪一個。
把這件事做對的網域很少：根據 Defaults.Exposed 普查，只有 51.84% 的已評分網域在 DNS 中發布了可發現的 DKIM 金鑰，而在 261 百萬個已評分網域中，只有 3.87% 同時具備 SPF、DKIM 和強制執行的 DMARC 政策——這正是大宗發件規則如今默認要求的設定。逐階段的全景見 SPF 採用成熟度模型。
五個原因按順序是什麼？
| # | 原因 | 特徵信號 | 修復方法 |
|---|---|---|---|
| 1 | 內容在傳輸途中被修改——閘道頁脚、法律免責宣告、郵件列表的主題標簽 | Authentication-Results 中出現 body hash did not verify；外部郵件失敗，直發郵件通過 | 在修改之後再簽名，或停止修改——見正文雜湊指南 |
| 2 | 長金鑰被截斷或弄乱 | 發布的 p= 明顯比你生成的金鑰短；所有接收方都失敗 | 把 2048 位金鑰以正確拆分的 TXT 字串重新發布 |
| 3 | 發布的金鑰與簽名方不一致 | 失敗恰好始於一次轮換、遷移或更換服務商之後 | 從簽名方重新復制當前公鑰；优先使用 CNAME 委托 |
| 4 | 選擇器錯誤或缺失 | no key for signature——查詢本身就失敗 | 發布簽名方實際使用的選擇器——見選擇器指南 |
| 5 | 脆弱的規範化設定或 l= 標簽 | 在被轻微重排版的郵件上間歇性失敗 | c=relaxed/relaxed；彻底刪除 l= |
原因 1 加粗，是因為它破壞的是簽得完美无缺的郵件。安全閘道追加一段免責宣告、合規頁脚在簽名之後被蓋上去、郵件列表在主題裡加上 [listname]——正文或被簽名的標头變了，雜湊就對不上了，簽名隨之無效，而你的 DNS 毫无過錯。如果失敗與經過閘道、郵件列表或歸檔節點的郵件相關聯，就從那裡查起。
“DKIM signature not valid”怎麼修？
- 動 DNS 之前，先在 defaults.exposed 執行免費掃描。 它顯示你發布的金鑰記錄是否存在、格式正確且完整——一步就把“你的 DNS 壞了”（原因 2–4）和“你的 DNS 沒問題，是郵件被改了”（原因 1）區分開。
- 讀一封失敗郵件的
Authentication-Results標头。body hash did not verify→ 原因 1，去看正文雜湊指南——常見元凶是閘道頁脚和免責宣告，解法是在修改之後簽名。no key for signature→ 原因 4，去看選擇器指南。普通的簽名失敗 → 繼續往下。 - 檢查發布的金鑰是否被截斷。 以 TXT 類型查詢
<selector>._domainkey.<yourdomain>（dig TXT selector._domainkey.example.com）。2048 位 RSA 公鑰超過單個 TXT 字串 255 個字元的上限，因此必須發布為多個帶引號的字串，由接收方拼接——而 DNS 服務商的網頁界面出了名地會悄悄截斷粘贴內容、弄乱拆分，或往p=值裡塞進空白和引號。與簽名方生成的金鑰逐字元比對；我們的 DKIM 設定逐步教程覆蓋了各服務商的怪癖。 - 確認發布的金鑰與簽名方一致。 在金鑰轮換、服務商遷移或 ESP 重新接入之後，常見的情况是簽名方已持有新私鑰，而 DNS 仍在提供舊公鑰——每個簽名都拿錯誤的金鑰去驗證，全部失敗。從服務商管理控制台重新復制當前記錄。更好的做法：只要服務商提供 CNAME 委托就用它——服務商在自己那邊轮換金鑰，這一整類故障就消失了。另外，在用舊選擇器簽名的郵件流量彻底排空之前，絕不要刪除舊選擇器。
- 修正簽名設定，而不只是記錄。 把規範化設定為
c=relaxed/relaxed，它能容忍中間伺服器合法進行的空白重排和標头重新折行；simple規範化會在人眼都看不出的改動上失敗。並且不要使用l=正文長度標簽：它本意是放行頁脚，實際却讓任何人都能在你簽名的郵件後追加內容而不破壞簽名——一個真實的攻擊途径——而且它照樣扛不住大多數閘道修改。不用l=既更安全也更可靠。 - 重新掃描，然後檢查對齊。 有效的簽名只有在
d=網域與你的 From 網域對齊時才對 DMARC 有用——一個以d=yourcompany.gappssmtp.com驗證通過的簽名，DKIM 通過，DMARC 照樣失敗。如果這說的就是你，見默認簽名陷阱，然後在修復 DKIM 頁面上處理掃描標出的其余問題。
常見問題
“DKIM signature not valid”和“body hash did not verify”是一回事嗎？ 正文雜湊那條資訊是一個特定子情形：正文在簽名之後被改動了（頁脚、免責宣告、列表改寫）。“Signature not valid”是所有驗證失敗的總稱裁決，包括壞金鑰和標头改動——這就是為什麼上面第 2 步是讀標头，也是為什麼正文雜湊情形有自己的指南。
DKIM 簽名無效是否意味著我的郵件正在被拒收？ 單凭它不會——接收方把損壞的簽名當作缺失的簽名對待。伤害經由 DMARC 落地：如果 SPF 也沒有以對齊方式通過，郵件就 DMARC 失敗，你發布的政策隨即生效。截至 2026-06-29 的普查，261,086,232 個已評分網域中只有 3.87% 同時具備 SPF、DKIM 和強制執行的 DMARC 政策——但 Gmail 和 Microsoft 現在對發件方的期待恰恰是這一套，所以 DKIM 這條腿斷了，還沒到被拒收就已經在損失送達率。
DKIM 金鑰該用 1024 位還是 2048 位？ 2048 位——1024 位金鑰已低於當前密碼學建議，部分接收方會為此扣分。麻烦純粹在操作層面：2048 位金鑰放不進一個 255 字元的 TXT 字串，必須正確拆分（上面的原因 2）。CNAME 委托給你的服務商則完全繞開拆分問題。
我的 DKIM 在檢測工具上通過，DMARC 却仍然失敗——怎麼回事？
几乎可以肯定是對齊問題：簽名驗證通過，但它的 d= 網域（比如 yourcompany.gappssmtp.com 或 yourtenant.onmicrosoft.com）與你的 From 網域不匹配，DMARC 用不上它。啟用服務商的自定義網域簽名——完整教程在默認簽名陷阱指南裡。
DKIM 老是失敗，能不能干脆關掉？ 不能——自 2024 年的大宗發件強制要求以來，Gmail 和 Yahoo 要求量大的發件方必須有 DKIM，而強制執行的 DMARC 政策實際上也离不開 DKIM，因為僅靠 SPF 在轉發場景下會失效。把簽名修好；上面的這些原因一個下午都能修完。
把報告發給老板
如果你是在替客戶或雇主修這個問題，用證據收尾。改完之後重新執行免費掃描，把評分報告轉發給企業負責人：帶日期、直白語言、DKIM 顯示綠色。這正是他們在網路保險續保和下一份供應商安全問卷時需要的凭證——“我修了個 DNS 的東西”與一份白紙黑字的前後對比、證明該網域的郵件已通過驗證，二者的區別就在這裡。
檢查你的網域 → · “Body hash did not verify”指南 → · 修復 DKIM → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。