「DKIM署名が無効です」および「本文のハッシュが検証されませんでした」というエラーの修正方法

「DKIM署名が無効です」というエラーが表示された場合は、DKIMの設定に問題があるため、修正が必要です。こうしたエラーは通常、DKIMのDNSレコードの記述が間違っている、DNSの伝播に遅延が生じている、DKIM署名の検証中にエラーが発生した、あるいは署名後にメッセージが変更されたことなどが原因です。 

このガイドでは、各原因とその解決策について順を追って解説しています。また、密接に関連する「DKIM署名の本文ハッシュが検証されませんでした」というエラーについては専用のセクションを設けており、これは特定の問題に起因するもので、非常に簡単に解決できるものです。

DKIM署名について

DKIMはメールのヘッダーに暗号署名を追加し、受信サーバーはその署名を、送信者のDNSに公開されている公開鍵と照合します。両者が一致しない場合、「DKIM署名が無効です」というエラーが表示されます。このプロトコルの仕組みに関する詳しい説明については、当社のガイド「 DKIMとは」のガイドをご覧ください。

このエラーが発生する人のほとんどは、すでにDKIMの設定が完了しており、不具合を修正するだけで済むため、このページの残りの部分では、基礎知識よりも診断と修正方法に焦点を当てます。

「DKIM署名が無効です」というエラーが表示されるのは、どのような場合ですか？

DKIM認証チェックに失敗すると、「DKIM署名が無効です」というメッセージが表示されます。主な原因は以下の通りです：

• DKIM署名のドメインと送信者のドメインが一致していません。
• DNSに登録されているDKIM公開鍵レコードが正しくありません。
• DKIMの公開鍵レコードは、DNSには一切公開されていません。
• サーバーが送信元のドメインのDNSゾーンにアクセスして照会を行うことができません。これは、信頼性の低いホスティングプロバイダーではよく見られる状況です。
• DKIM キーの長さが不十分です。最新のプロバイダーでは 2048 ビットのキーが求められており、従来の 1024 ビットのキーは信頼されにくくなってきています。また、キーの長さが極端に短い場合は、即座に拒否されます。
• このメッセージは、自動転送の過程で変更されました。

最後のものを除き、これらはすべて、ご自身で直接解決できる技術的な問題です。転送の場合については事情が異なります。受信側のサーバーがコンプライアンス・フッターを追加したり、メッセージを書き換えたりするかどうかを、送信者が制御することはできないからです。では、自動転送されたメッセージが SPFとDKIMの両方に失敗し、かつあなたの DMARCポリシー が「拒否」に設定されている場合はどうなるのでしょうか？

これはかつて、正当ではあるが認証されていない転送メールを処理しようとする受信サーバーにとって、真の問題となっていました。現在の暫定的な対策として採用されているのが、 Authenticated Received Chain （ARC）プロトコルです。これにより、チェーン内の各メールサーバーが確認した認証結果を記録できるようになり、最終的な受信者は、転送によってメッセージが変更される前に認証されていたことを認識できるようになります。しかし、ARCはあくまで実験的な回避策に過ぎず、業界では現在、これを段階的に廃止する方向に進んでいます。2026年4月に発表された別のIETFドラフトでは、ARCの教訓が DKIM2に組み込まれているためです。DKIM2は、IETFで開発中のDKIMの新バージョン（draft-ietf-dkim-dkim2-spec）であり、別個のメカニズムを上乗せするのではなく、コアプロトコル内で転送の問題を修正するものです。 DKIM2では、受信者に仲介者が「見た」という説明を信頼するよう求める代わりに、各ホップが変更内容を「元に戻せる手順」として正確に記録します。これにより、検証者はそれらの変更を元に戻し、元の送信者の署名を再確認することができます。これはまだ標準化の過程にあるため、現時点ではARCが実用的な解決策として残っていますが、転送の問題に対して真の解決策が間もなく登場することを知っておく価値はあります。

「DKIM署名が無効です」というエラーの解決方法

DKIMレコードが設定されている場合でも、署名が無効であるというエラーが表示されることがあります。以下に、上記で挙げた各原因に応じた対処法を示します。

解決策 1：誤った DKIM DNS エントリのトラブルシューティング

DKIM TXTレコードを作成してDNS設定に追加した後、署名が無効であるというエラーが発生した場合、その原因は多くの場合、そのレコードの設定ミスに起因しています。原因を特定するには：

• PowerDMARCの DKIMルックアップ を使用して、レコードを確認してください。

• ドメイン名とセレクターを入力するか、セレクターを空白のままにしてプラットフォームに自動検出させ、その後「確認」をクリックしてください。

• このツールは、DKIMのDNSエントリを分析し、レコードの構文に誤りがある場合はそれを強調表示します。

設定を修正するには、cPanel またはご利用の DNS 管理コンソールにログインし、「ドメイン」の下にある「詳細 DNS ゾーンエディタ」を開き、対象のドメインを選択して、「DNS レコードの編集」に進み、DKIM レコードの値を修正して、保存してください。

解決策 2：DNS の伝播遅延が解消されるまで待つ

DNS設定を変更した直後にエラーが表示されることもありますが、これは正常な現象です。DNSの反映には最大24～48時間かかることがあり、正確な時間はレコードに設定されたTTL値によって異なります。完全に反映されるまで数日お待ちください。その間、当社の DNS伝播チェッカーでステータスを確認してください。

解決策 3：DKIM 署名ドメインを送信ドメインと一致させる

検証に失敗したメッセージの「DKIM-Signature」ヘッダーを開き、 d= の値を、表示されている「From」アドレスと照らし合わせて確認してください。これらが一致しない場合、送信サービスがお客様のドメインではなく、自身のドメインで署名を行っているため、整合性が崩れ、チェックに失敗します。解決策は、そのサービスがお客様のドメインで署名するように設定することです。ほとんどのメールプラットフォームには、まさにこのための「カスタムDKIM」または「ドメインの認証」設定があります。当社のガイド DKIMの設定方法 では、その手順について解説しています。

解決策 4：短すぎるキーを再生成する

ご利用のプロバイダーが依然として1024ビット（またはそれより短い）の鍵で署名を行っている場合は、Googleやその他の主要プロバイダーが求める現在の標準である2048ビットの鍵に再生成してください。新しい鍵ペアは、ご利用のESPの管理コンソール、または当社の DKIMジェネレーターを使用して新しい鍵ペアを生成し、新しい公開鍵をDNSに公開した後、当社のDKIMレコード検索ツールを使用して正しく解決されることを確認してください。

解決策 5：接続できない DNS サーバーの問題を解決する

受信サーバーが公開鍵を検索するためにあなたのDNSにアクセスできない場合、他の設定がどれほど適切であってもDKIMは失敗します。DNS伝播チェッカーを使用して、レコードにアクセスできるかどうかを確認してください。ホスティングプロバイダーのDNSの応答が遅い、または信頼性が低い場合は、CloudflareやAmazon Route 53などの専用プロバイダーにDNSホスティングを移行することを検討してください。

修正 6：自動転送中に変更されたメッセージの処理

転送時の変更によりDKIMが破綻することがあり、送信者側で常に修正できるとは限りません。転送サーバーを管理している場合は、ARC署名を有効にし（Microsoft 365では、Defenderの「信頼できるARCシーラー」リストに信頼できる転送元を追加してください）、正当な転送メールが破棄されないようにしてください。管理していない場合、これは想定された動作であり、設定ミスではありません。あなたの DMARCの集計レポート にこれらの失敗が反映されます。適切な対応は、すべての関係者に連絡して対応を求めるのではなく、ポリシーにこれらを考慮に入れ、継続的に監視を続けることです。

Note: ARC is a temporary fix and not a permanent solution. DKIM2 is being designed to fix forwarding at the protocol level, so this whole category of failure should shrink as it rolls out. Keep any existing ARC setup running to support legacy gateways in the meantime, but there's little reason to invest heavily in new ARC engineering now.

なぜ "DKIM-Signature Body Hash Not Verified "と表示されるのですか？

「DKIM-signature body hash not verified」というエラーは、受信サーバーが算出した本文のハッシュ値が、DKIM-Signatureヘッダーのbh=タグに格納されている値と一致しないことを意味します。簡単に言えば、受信者が確認したメールの本文が、あなたのサーバーが署名した本文と一致していないということです。その間に、何らかの要因でメッセージが変更されてしまったのです。

この点を正確に理解しておく価値があります。というのも、この現象は苛立たしいほど頻繁に発生する上、通常はDKIMの設定そのものは正しく行われていることを意味するからです。本文のハッシュチェックは完全な署名チェックの前に実行されるため、本文のハッシュチェックに失敗すると、DKIMの評価全体が失敗となり、受信側は暗号署名自体の検証に進むことさえありません。

ボディハッシュの失敗によくある原因

• DKIM署名後にメールゲートウェイやフィルターによってコンテンツが追加された場合： メッセージがすでに署名された後に送信ゲートウェイによって挿入された免責事項、法的フッター、トラッキングピクセル、配信停止ブロック、ウイルス対策バナー、およびマーケティング用フッターは、すべて本文を変更し、ハッシュを破綻させます。これが最も頻繁に見られる原因です。
• メーリングリストや転送サーバーによって本文が変更されました： メーリングリスト用ソフトウェアは、定期的に購読解除用のフッターを追加したり、件名を書き換えたりすることがあり、転送サーバーはヘッダーを削除したり追加したりすることがあります。いずれも、署名されたコンテンツを変更することになります。
• 文字エンコーディングまたは改行コードの不一致： メッセージが特定のエンコーディング（たとえば、バイト順マーク付きのUTF-8）で署名されているにもかかわらず、受信サーバーがそれを異なるエンコーディングとして解釈した場合、あるいは転送中に改行コードがCRLFからLFに変化した場合、バイトレベルのコンテンツが一致しなくなり、ハッシュ検証に失敗します。
• DKIM署名が、送信メールの処理フローにおいて早すぎる段階で実行されています： これが、上記のほとんどの問題の根本原因です。システムが、下流のコンポーネントによってメッセージが変更される前に署名を行うと、本文のハッシュ検証は毎回失敗してしまいます。
• 不正な、または回転された秘密鍵： 署名鍵がDNSに公開されている公開鍵と一致しなくなった場合、検証は失敗します。

ボディハッシュの故障を診断する方法

以下の手順に従って、変更が行われている箇所を絞り込んでください：

1. Gmail、Outlook、またはHotmail、および1つの社内メールボックスに、同じテストメッセージを送信してください。3つすべてにおいて、内容、リンク、送信経路を同一にしてください。
2. 各受信側で「Authentication-Results」ヘッダーを確認してください。3つすべてでボディのハッシュ照合に失敗する場合は、送信側に問題があります。1つだけ失敗する場合（通常はOutlookが原因です）、問題は署名設定よりも、MIME構造や文字エンコーディングにある可能性が高いです。
3. メールの送信順序を確認し、DKIM署名が送信コンテンツの変更の前に行われるのか、後に行われるのかを確認してください。
4. 当社のDKIMレコード検索ツールを使用して、DKIMのDNSレコードを確認し、セレクタと公開鍵が、署名エラーの原因となっている内容と一致しているかを確認してください。
5. 追跡機能、フッター、添付ファイルを一切含まないプレーンテキストのテストメールを送信してください。通常のメールが配信に失敗する場所で、そのメッセージが正常に配信されれば、消去法によって原因を特定できたことになります。

ボディハッシュの失敗を修正する方法

• コンテンツの変更を行うたびに、最後にメッセージに署名してください： これが最も一般的かつ効果的な対処法です。「作成、DKIM署名、免責事項の追加、送信」という順序を、「作成、免責事項の追加、DKIM署名、送信」に変更し、受信者が実際に受け取るメッセージそのものに署名するようにしてください。
• メッセージ本文を変更しないように、送信ゲートウェイを設定します： あるいは、変更処理が完了した後にDKIMで再署名するように設定します。
• エンコーディングを標準化してください バイト順マーク（BOM）なしのUTF-8に統一し、送信経路全体を通じてCRLF形式の改行を一定に保ってください。これは、ExchangeおよびMicrosoft 365環境において特に重要です。
• 緩やかな正規化を使用する (c=relaxed/relaxed): これにより、厳格な「単純」正規化では署名が破綻してしまうような、些細な空白や書式の違いが許容されます。免責事項やフッター全体が追加された場合には署名を修復することはできませんが、些細な書式変更によって引き起こされる失敗は解消されます。

Outlook および Microsoft 365 特有の本文ハッシュの失敗

マイクロソフトのサポートフォーラムにも頻繁に寄せられる、繰り返し見られるパターンとして、GmailやYahoo!ではDKIM検証に合格するものの、OutlookやHotmailでは不合格となるというケースがあります。これは通常、添付ファイルや埋め込み画像を含むメッセージで発生するものであり、これは署名設定の問題というよりは、マイクロソフトのシステムがMIME構造や文字エンコーディングをどのように処理しているかによるものです。

これを確認する最も明確な方法は、両方の受信側における同一メッセージの「Authentication-Results」ヘッダーを比較することです。成功と失敗の場合は、次のような表示になります：

なし

# Gmail（合格）

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1;
spf=pass; dmarc=pass

# Outlook では（同じメッセージで失敗する）

Authentication-Results: protection.outlook.com;
dkim=fail (body hash did not verify)
header.d=yourdomain.com header.s=selector1;
spf=pass; dmarc=fail (p=none)

DKIMの失敗が発生した際、その原因を推測するよりも、メッセージ自体の認証ヘッダーを確認するのが、状況を把握するための最も手っ取り早い方法です。

Authentication-Results ヘッダーの読み方

Gmailでメッセージを開き、3つの点からなるメニューをクリックして、「原文を表示」を選択します。「Authentication-Results」ヘッダーを見つけ、「dkim=」の結果を確認してください。そこには「pass」、「fail」、または「neutral」と表示され、その後に「body hash did not verify」、「signature did not verify」、「key too short」などの理由が記載されているのが一般的です。この理由から、どの種類の問題が発生しているかが分かり、それに応じて上記のどの解決策が適用されるかが判断できます。

ヘッダーを読んでいる際、DKIM-Signatureタグは参考になる指標となります：

v= DKIMのバージョン（例：v=1）

aa = 署名アルゴリズム（例：a=rsa-sha256）

d= 署名ドメイン（送信元アドレスと照合して一致を確認してください）

s= セレクタ。DNS内で公開鍵を特定するために使用される

h= 署名に含まれるヘッダー

bh= ボディハッシュ（「ボディハッシュが検証されませんでした」というエラーの原因となる値）

b= 暗号署名そのもの

d=の値を、表示されている「送信元ドメイン」と照合することで整合性が確認できます。s=セレクタは、どのDNSレコードを確認すべきかを示しており、bh=の不一致は、署名後に本文が改ざんされたことを示しています。

送信元が不明なものである場合は、その送信元が許可済み送信者に含まれているかどうかを確認し、 DMARCの失敗レポート と照らし合わせて、どのようなメールが送信されているかを確認し、そのIPアドレスがブラックリストに登録されていないかを確認してください。 

送信者が正当な相手である場合は、 DMARCを を正しく設定して、その送信者を承認してください。正当な送信者でない場合は、対応すべきなりすまし（スプーフィング）の兆候となります。

「DKIM署名が無効です」というエラーを修正しました。次は何をすればよいですか？

ここからDKIMの設定を強化するには：

1. 当社の ホステッドDKIM にご登録いただくと、DKIM認証の結果を長期的に監視できます。
2. セキュリティを強化し、より正確な認証を行うために、SPFとDMARCを有効にしてください。
3. 保護を強化するため、DKIMキーを定期的に更新してください。

それでもエラーが直らない

DKIM署名が無効であるというエラーが解消されない場合は、ご利用のメールサービスプロバイダーにお問い合わせいただくか、 弊社までご連絡ください メール認証に関するあらゆる専門的なアドバイスをご提供いたします。

よくあるご質問

「DKIM署名の本文ハッシュが検証されませんでした」とはどういう意味ですか？ 

これは、受信サーバーが算出した本文のハッシュ値が、メッセージに署名した際にサーバーが記録した「bh=」の値と一致しないことを意味します。実際には、署名後にメール本文が変更されたものであり、その原因として最も多いのは、送信経路の後半で追加された免責事項、フッター、トラッキングピクセル、またはゲートウェイによる変更などです。

なぜDKIMの本文ハッシュは、Outlookでは失敗するのに、Gmailでは合格するのでしょうか？ 

Gmailでは正常に受信できるメッセージが、OutlookやHotmailでは受信に失敗する場合、その原因は通常、署名の設定ではなく、MicrosoftのシステムによるMIME構造や文字エンコーディングの処理方法にあります。この現象は、添付ファイルや埋め込み画像を含むメッセージで特に頻繁に発生します。両方の受信側で生のソースコードを比較し、転送エンコーディングを統一し、緩和された正規化を使用してください。

免責事項を追加した後、DKIM署名を有効にするにはどうすればよいですか？ 

送信メールの処理順序を再編成し、署名処理をコンテンツを変更する最後のステップにするようにしてください。まず署名を行ってから免責事項を追加するのではなく、先に免責事項を追加し、その後に署名を行うようにします。これを実現するには、DKIM署名処理をコンテンツフィルターや免責事項・署名サービスの後に実行するように設定し、受信者が実際に受け取る最終的なメッセージに対して署名が行われるようにします。

「ボディハッシュが検証されませんでした」と「署名が検証されませんでした」の違いは何ですか？ 

「Body hash did not verify」とは、署名後にメッセージ本文が変更されたことを意味するため、解決策は本文またはメールフローの修正となります。「Signature did not verify」はより広範なエラーであり、多くの場合、署名済みヘッダーの変更、鍵の不一致、あるいはDNSや鍵に関する問題を示しています。Authentication-Resultsヘッダー内のreason文字列を確認することで、どちらの問題であるかがわかります。

DKIMはメールをフィルタリングしますか？ 

DKIMはメールを直接フィルタリングするものではありません。DKIMは「合格」または「不合格」のシグナルを提供し、受信サーバーはこれを独自のスパムスコア判定の判断材料として活用します。信頼できるドメインから送信され、DKIMの検証に合格したメールはスパムスコアが低くなる可能性がありますが、DKIMの検証に不合格となった場合は、そのメッセージがスパムとしてマークされたり、隔離されたりする要因となる可能性があります。

DMARCがp=noneに設定されている場合、DKIMの失敗を無視してもよいでしょうか？ 

p=none の設定では、検証に失敗したメールも依然として配信されるため、DKIM の検証失敗によって直ちに配信がブロックされることはありません。しかし、これを無視してしまうと、検証の徹底に向けた取り組みの趣旨が損なわれるだけでなく、自身の認証データを信頼できなくなってしまいます。p=none の段階で検証失敗の原因を解決しておき、後で安全にp=quarantineや p=reject へと移行できるようにしておく方がよいでしょう。

DKIMキーはどのくらいの頻度で更新すべきですか？ 

一般的な慣行として、鍵は6か月から1年ごとにローテーションされます。定期的にローテーションを行うことで、万が一秘密鍵が漏洩した場合の被害を最小限に抑えることができます。重要な点は、ローテーションの一環としてDNSに登録されている公開鍵を更新することです。なぜなら、ローテーションされた鍵がDNSに反映されていないと、それ自体が署名エラーの原因となるからです。

• について
• 最新記事

ユネス・タラダ

ドメインおよびメールセキュリティの専門家（所属： PowerDMARC

ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。

最新記事 by Yunes Tarada(全て見る)

• 「DKIM署名が無効です」および「本文のハッシュが検証されませんでした」というエラーの修正方法 - 2026年7月16日
• Kit DKIM、DMARC、およびSPFの設定ガイド - 2026年7月6日
• NIST SP 800-81r3：電子メールのためのDNSセキュリティガイドライン - 2026年6月25日