Defaults.Exposed › 修正 › Guides
「DKIM Signature Not Valid」— 原因とチェック順（2026）
公開日 2026-07-08
データは 2026-06-29 時点 · メソドロジー v7。 261 百万採点済みドメインを対象とした集計センサスデータ。採点方法を参照。
「DKIM signature not valid」には5つの一般的な原因があり、この順番でチェックするのが最善だ：転送中のコンテンツ変更、切り詰められたキーレコード、署名者と一致しない公開鍵、間違ったセレクター、そして脆弱なカノニカライゼーション。Defaults.Exposed センサス（2026-06-29）によると、採点済み 261,086,232 ドメインのうち SPF + DKIM + 適用済み DMARC トライアドを保持しているのはわずか 10,092,481（3.87%）だ。
修正の順序が重要だ。最も一般的な原因は DNS にまったく関係ない。まず転送中にメッセージを変更したものを確認し、次に内側に進む：キーレコードの完全性、メールサーバーが実際に署名しているキーと一致するか、セレクター、最後に署名設定。無効な署名のほとんどはステップ1か2で修正される。
「DKIM signature not valid」とは実際に何を意味するか？
すべての DKIM 署名済みメッセージは、ドメイン（d=）、セレクター（s=）、メッセージボディのハッシュ（bh=）、そしてボディハッシュと選択されたヘッダーに対する暗号署名（b=）を記述した DKIM-Signature ヘッダーを持つ。受信側は <selector>._domainkey.<domain> から公開鍵を DNS で取得し、両方のハッシュを再計算して署名を確認する（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 ヘッダーの正確な表現を読む：5つの原因のどれを持っているかを教えてくれる。
これを正しく行うのは稀だ：Defaults.Exposed センサスによると、採点済みドメインのうち DNS に発見可能な DKIM キーを公開しているのはわずか 51.84%、そして 261 百万採点済みドメインのうち SPF、DKIM、適用済み DMARC ポリシーを組み合わせているのはわずか 3.87% だ — バルク送信者ルールが今や前提とする設定だ。段階ごとの状況は SPF 採用成熟度モデルにある。
5つの原因とは何か、順番に
| # | 原因 | 見分け方 | 修正 |
|---|---|---|---|
| 1 | 転送中のコンテンツ変更 — ゲートウェイのフッター、法的免責事項、メーリングリストの件名タグ | Authentication-Results に body hash did not verify；外部メールは失敗、直接メールは合格 | 変更の後で署名するか、変更をやめる — body-hash ガイドを参照 |
| 2 | 切り詰められたか破損した長いキー | 公開された p= が生成したキーより明らかに短い；すべての受信側で失敗 | 2048 ビットキーを適切に分割した TXT 文字列として再公開する |
| 3 | 公開鍵が署名者と一致しない | ローテーション、移行、プロバイダー変更の直後から失敗が始まる | 署名者から現在のレコードを再コピーする；CNAME 委任を優先する |
| 4 | 間違ったまたは欠落したセレクター | no key for signature — ルックアップ自体が失敗する | 署名者が実際に使用するセレクターを公開する — セレクターガイドを参照 |
| 5 | 脆弱なカノニカライゼーションまたは l= タグ | 軽微な再フォーマットのメッセージで断続的な失敗 | c=relaxed/relaxed；l= を完全に削除する |
原因1が太字になっているのは、完璧に署名されたメッセージの署名を壊すからだ。セキュリティゲートウェイが免責事項を付加し、コンプライアンスフッターが署名後にスタンプされ、メーリングリストが件名に [リスト名] を追加する — ボディまたは署名済みヘッダーが変化し、ハッシュが一致しなくなり、DNS の問題とは無関係に署名が無効になる。失敗がゲートウェイ、リスト、またはアーカイブホップを通過したメールと相関している場合は、そこから始める。
「DKIM signature not valid」を修正するには？
- DNS を変更する前に defaults.exposed で無料スキャンを実行する。 公開されているキーレコードが存在し、正しい形式で完全かどうかを表示する — 「DNS が壊れている」（原因2〜4）と「DNS は問題ないが、メッセージが変更されている」（原因1）を1ステップで区別できる。
- 失敗しているメッセージの
Authentication-Resultsヘッダーを読む。body hash did not verify→ 原因1、body-hash ガイドへ — 通常の原因はゲートウェイのフッターと免責事項で、修正は変更後に署名すること。no key for signature→ 原因4、セレクターガイドへ。単純な署名失敗 → 続ける。 - 公開鍵の切り詰めを確認する。
<selector>._domainkey.<yourdomain>を TXT として調べる（dig TXT selector._domainkey.example.com）。2048 ビット RSA 公開鍵は1つの TXT 文字列の 255 文字制限を超えるため、受信側が連結する複数のクォート文字列として公開しなければならない — DNS プロバイダーの Web UI はペーストを黙って切り詰めたり、分割を誤ったり、p=の値に空白やクォートを挿入することで有名だ。署名者が生成したキーと一文字ずつ比較する；DKIM 設定ウォークスルーでプロバイダー固有の注意点をカバーしている。 - 公開鍵が署名者と一致することを確認する。 キーローテーション、プロバイダー移行、ESP の再接続後、署名者が新しい秘密鍵を持っているのに DNS が古い公開鍵を返し続けることがある — すべての署名が間違ったキーに対して検証されて失敗する。プロバイダーの管理コンソールから現在のレコードを再コピーする。さらに良いのは：プロバイダーがCNAME 委任を提供している場合はそれを使う — プロバイダーが自分側でキーをローテーションするため、この種の失敗全体が消える。そして古いセレクターで署名されたトラフィックが消化されるまで、古いセレクターを削除しない。
- レコードだけでなく署名設定も修正する。 カノニカライゼーションを
c=relaxed/relaxedに設定する。これは中間サーバーが正当に行う空白の再ラップやヘッダーの再折り返しに対応する；simpleカノニカライゼーションは人間にも見えない変更で失敗する。そしてl=ボディ長タグを使用しない：フッターを通すためのものだったが、署名を壊さずに誰でも署名済みメッセージにコンテンツを追加できてしまう — 実際の攻撃ベクトルだ — そして依然としてほとんどのゲートウェイ変更を生き残れない。l=なしは安全性と信頼性の両方で優れた選択だ。 - 再スキャンしてアライメントを確認する。 有効な署名が DMARC に役立つのは
d=ドメインが From ドメインとアライメントしている場合のみだ —d=yourcompany.gappssmtp.comとして検証される署名は DKIM で合格しても DMARC で失敗する。该当する場合はデフォルト署名の落とし穴を参照し、DKIM の修正ページでスキャンがフラグを立てた残りの問題を対処する。
よくある質問
「DKIM signature not valid」は「body hash did not verify」と同じか？ body-hash メッセージは1つの特定のサブケースだ：署名後にボディが変更された（フッター、免責事項、リストの書き換え）。「Signature not valid」は、不正なキーやヘッダー変更を含む、検証失敗に対する包括的な判定だ — 上記のステップ2がヘッダーを読むことであり、body-hash ケースに独自のガイドがある理由だ。
無効な DKIM 署名はメールが拒否されることを意味するか？ それ自体では意味しない — 受信側は壊れた署名を欠落している署名と同様に扱う。ダメージは DMARC 経由で来る：SPF もアライメント付きで合格しない場合、メッセージは DMARC で失敗して公開しているポリシーが適用される。2026-06-29 センサス時点で、採点済み 261,086,232 ドメインのうち SPF、DKIM、適用済み DMARC ポリシーを一緒に保持しているのはわずか 3.87% だ — しかし Gmail と Microsoft は今まさにそれを送信者に期待しているため、壊れた DKIM レグは拒否前に到達率にコストをかける。
1024 ビットと 2048 ビットの DKIM キー、どちらを使うべきか？ 2048 ビット — 1024 ビットキーは現在の暗号推奨を下回り、一部の受信側はスコアを下げる。問題は純粋に運用上のものだ：2048 ビットキーは1つの 255 文字 TXT 文字列に収まらないため、正しく分割しなければならない（上記の原因2）。プロバイダーへの CNAME 委任は分割の問題を完全に回避する。
チェッカーでは DKIM が合格しているのに DMARC が失敗する — なぜか？
ほぼ確実にアライメントの問題だ：署名は検証されるが、その d= ドメイン（例えば yourcompany.gappssmtp.com や yourtenant.onmicrosoft.com）が From ドメインと一致しないため、DMARC はそれを使えない。プロバイダーのカスタムドメイン署名を有効にする — 完全なウォークスルーはデフォルト署名の落とし穴ガイドにある。
DKIM が失敗し続ける場合、DKIM をオフにできるか？ いいえ — 2024年のバルク送信者義務化以来、Gmail と Yahoo はボリューム送信者に DKIM を要求しており、適用済み DMARC ポリシーは現実的には DKIM を必要とする（SPF だけでは転送で壊れるため）。署名を修正する；上記の原因はすべて午後1つで修正できる。
オーナーにレポートを送る
クライアントや雇用主のためにこれを修正している場合、証拠で締めくくる。変更後に無料スキャンを再実行し、採点レポートをビジネスオーナーに転送する：日付入りで平易な言葉で、DKIM が緑表示になっていることを示す。それがサイバー保険更新や次の取引先セキュリティアンケートに必要な成果物だ — 「DNS を修正した」と言う代わりに、ドメインがメールを認証していることを示す、文書化された前後の記録だ。
ドメインをチェックする → · 「Body hash did not verify」ガイド → · DKIM を修正する → · 採点方法 → · 集計データのみ使用。データは EU 内で保存・処理。