Defaults.Exposed › 修正 › Guides
DKIM「Body Hash Did Not Verify」— メッセージを変更したものと修正方法（2026）
公開日 2026-07-08
データは 2026-06-29 時点 · メソドロジー v7。 261 百万採点済みドメインを対象とした集計センサスデータ。採点方法を参照。
「body hash did not verify」は、メッセージが送信された時点では DKIM 署名が有効だったことを意味する — そして何かがその後にメッセージボディを書き換えた。署名が壊れているのではなく、転送中にメッセージが変更された。Defaults.Exposed の 261,086,232 ドメインのセンサス（2026-06-29）によると、完全な SPF-DKIM-DMARC トライアドを完了しているドメインはわずか 3.87%（10,092,481）だ。
修正は探索、そして判断だ。メールを変更しているホップを特定する — 免責事項を付加するゲートウェイ、リンクを書き換えるアプライアンス、フッターを追加するメーリングリスト。次に、そのホップの後で署名するか、変更をやめるか、署名をその変更に対して耐性を持たせる — この順番で。
「body hash did not verify」とは実際に何を意味するか？
DKIM 署名（RFC 6376）は2つのハッシュを持つ：bh=（署名時のメッセージボディのハッシュ）と b=（ヘッダーとそのボディハッシュに対する署名）。検証者は受信したメッセージからボディハッシュを再計算する；bh= と一致しない場合、検証は誰もが検索ボックスに貼り付ける文字列で停止する — 受信者ヘッダーのような：
Authentication-Results: …; dkim=fail (body hash did not verify)
これは Microsoft の文書化された理由文字列だ；Gmail は同じ診断を dkim=neutral (body hash did not verify) として表示することが多い。いずれにせよ、この判定で問題が大幅に絞り込まれる。DNS キー、セレクター、署名設定はすべて問題ない。暗号は正しく機能した：署名と検証の間にボディが変更された — 追加された1行、書き換えられた1つの URL、再エンコードされた1つの文字で十分だ。（別のメッセージ — signature did not verify、no key for signature — は別の失敗を意味する；「DKIM signature not valid」から始める。）そして緊急だ：失敗した署名は DMARC にアライメントされた合格を与えられない：同じメッセージで SPF がアライメント付きで合格しない限り、メールは DMARC で完全に失敗する。
メッセージを変更したものは何か？よくある原因
署名者がメッセージを封印した後、配信パスの何かがボディを編集した。実際には4つのいずれかだ：
| 変更したもの | 何を変更するか | 典型的な見分け方 |
|---|---|---|
| アウトバウンドゲートウェイ / スマートホスト（Exchange トランスポートルール、Mimecast、Proofpoint、Barracuda など） | メールサーバーがすでに署名した後に法的免責事項、マーケティングフッター、または「EXTERNAL:」バナーを付加 | そのルートのすべてのメッセージが失敗；ゲートウェイをバイパスした直接送信は合格 |
| セキュリティアプライアンス / リンク保護 | URL をスキャンリダイレクトに書き換え、トラッキングラッパーを追加 | リンクを含むメッセージのみ失敗 |
| メーリングリスト（Google Groups、Mailman など） | 件名タグとリストフッターを追加し、ボディをリフローすることもある | リスト経由で送ったメールのみ失敗 |
| MIME を再エンコードする転送者 / リレー | 文字セットをトランスコード、行を再ラップ — 人間には見えないがハッシュには致命的 | 失敗が1つの受信者または転送アドレスに集中 |
太字の行から最初に確認する — メールサーバーが署名し、エッジデバイスが編集し、すべてのメッセージが30ミリ秒間だけ有効だった署名と共に送り出される。
メールを変更しているホップを特定するには？
差分診断 — 機能しているパスと失敗しているパスを比較する：
- アウトバウンドチェーンをできるだけバイパスして、管理している主要な受信者（Gmail が使いやすい）のメールボックスに直接テストメッセージを送る。
- 失敗しているパス経由で2通目のメッセージを送る — ゲートウェイ経由、リスト経由、影響を受けている受信者のドメインへ。
- 両方の完全なヘッダーで
Authentication-Results行を比較する。直接送信はdkim=pass、失敗しているパスはdkim=fail（またはdkim=neutral）とbody hash did not verify：変更者はその2つのルートの間にいる。 - 受信したボディを見る：自分が書いていない免責事項、バナー、フッター？スキャンドメインにリンクが書き換えられている？それがホップで、
Received:チェーンが失敗しているパスにのみ現れるリレーを示している。
DMARC アグリゲートレポートは同じことを大規模に教えてくれる：SPF 合格で DKIM 失敗を一貫して報告しているソースは、通常、攻撃者ではなく自分のルートでの転送中の変更だ。
修正するには？
- 何かを変更する前に defaults.exposed で無料スキャンを実行する。 公開されている DKIM キーと DMARC ポリシーが正常であることを確認し、唯一の本当の問題（変更）をデバッグするために DNS の幽霊を追わなくて済む。DKIM の修正ページがレコード側のチェックをカバーしている。
- 変更しているホップの後で署名する。 アーキテクチャ的に正しい修正：DKIM 署名をメッセージに最後に触れるデバイスに移す。Exchange + ゲートウェイの構成ではゲートウェイで署名し（Mimecast、Proofpoint とその類似製品はすべてサポートしている）、上流での署名を無効にする。Google Workspace や Microsoft 365 が最後のホップなら、そこで署名してその後は何もメールを編集しない — Google Workspace での DKIM 設定または Microsoft 365を参照。
- または変更をやめる。 トランスポートパスから編集を取り除く：トランスポートルールではなくクライアントの署名またはテンプレートに免責事項を入れる；「EXTERNAL:」バナーを受信メールのみにスコープする（自分のアウトバウンドメールを external とタグ付けするのは2重の設定ミスだ）；認証済みアウトバウンドメールをリンク書き換えから除外する。
- relaxed/relaxed カノニカライゼーションを使う（
c=relaxed/relaxed）。simpleボディカノニカライゼーションは1行の再ラップで失敗する；relaxedは空白と行末の変更に対応する。限界については正直に：relaxed が許容するのはフォーマットの変更だけで、コンテンツは許容しない — 付加されたフッターは依然として失敗し、それは正しい動作だ。 - 両方のパスを再テストし、再スキャンする。 両方のルートが
d=に自ドメインを持つdkim=passを示し、スキャンレポートがクリーンになるはずだ。
付加されたコンテンツを DKIM が無視するように l= タグを使うべきか？
いいえ — そう勧めるガイドには注意が必要だ。l= タグはボディの最初の N バイトのみをハッシュするため、付加されたフッターは署名を壊さなくなる。これは「機能する」が、メッセージの末尾が署名されていないことで実現する：正当な署名済みメッセージを持つ者なら誰でも任意のコンテンツを付加でき、有効な署名が結果に対して依然として検証される。それは修正に見せかけたなりすましの穴だ — 実際の悪用が実証されており、まさにこの理由から一部の受信側は l= にペナルティを与えるか無視する。変更を解決する；メールの一部を署名なしにしない。
メーリングリストについては？修正できるか？
ほとんどの場合、できない — そうとわかれば数週間が節約できる。件名タグやフッターを追加するリストは設計上、ボディハッシュを壊す。そしてリストをコントロールできない。2つのことが役立つ：
- この残余がまさに DMARC ロールアウトを段階的にする理由だ。
p=noneからpct=ランプ付きでp=quarantineに移行し、アグリゲートレポートを読みながら進めると、リストによって壊されたメッセージは破棄ではなくスパムフォルダ行きになり、その間に影響を評価できる — 正規メールを失わずに p=none から p=reject へのテーマだ。 - ARC は受信側のメカニズムで、あなたのものではない。 Authenticated Received Chain はリストが到着時の認証状況を証明し、受信側がそれを信頼するかどうかを決定できるようにする。送信者であるあなたが設定できることは何もない。よく管理されたリストは From ヘッダーを書き換えることで緩和する；管理の悪いリストはただあなたのメールを壊す。
転送は隣接するケースだ — SPF は確実に壊れるが DKIM は時々のみ壊れる。ボディが生き残った場合にアライメントされた DKIM が転送に耐えられるレグになる理由だ：転送メールが SPF に失敗する — 修正できない理由を参照。
なぜフルスタックを持つドメインがこんなに少ないのに DKIM はこんなに頻繁に壊れるのか？
DKIM はトライアドの壊れやすい中間の子だからだ：SPF は静的な DNS レコード、DMARC はポリシー声明だが、DKIM は旅を生き残らなければならない。Defaults.Exposed センサスによると、採点済みドメインのうち DNS に発見可能な DKIM キーを公開しているのはわずか 51.84%、そして採点済み 261,086,232 ドメインのうち SPF、DKIM、適用済み DMARC ポリシーを一緒に保持しているのはわずか 10,092,481 ドメイン（3.87%）だ（SPF 採用成熟度モデルがそのはしごを分解している）。この修正を正しく行うことが、その 3.87% に加わる最も難しい部分だ。
よくある質問
「body hash did not verify」は誰かが自ドメインをなりすましているサインか？
通常はそうではない — なりすまし攻撃者は通常、DKIM 署名を全く生成できないため、メールには署名なしか no key が表示される。body hash の失敗は、インフラが本当に署名したメッセージがその後に編集されたことを意味する。攻撃者を想定する前に自分のゲートウェイを確認する。
これらのメッセージで SPF は合格している — まだ大丈夫か？ 今のところはそうかもしれない：DMARC は1つのアライメントされた合格があれば十分だ。しかし SPF の合格は誰かがメッセージを転送した瞬間に消え、From ドメインにアライメントしていない場合は最初から DMARC に対してカウントされない。フルトライアドを保持しているドメインはわずか 3.87%（261,086,232 ドメインの 2026-06-29 センサス）だという現状で、「1つのレグが機能していない」状態は通常の状態だ — そして修正可能だ。
relaxed/relaxed カノニカライゼーションに切り替えれば免責事項の問題が修正されるか？ いいえ。Relaxed が許容するのは空白と行ラップの変更のみだ。付加された免責事項はコンテンツの変更であり、ハッシュはそれで失敗しなければならない — DKIM が正しく機能している。署名ポイントを移動するか免責事項を移動する。
ある顧客のドメインでのみ失敗する。なぜか？ その側がほぼ確実に受信メールを変更している — セキュリティアプライアンスが検証者が実行される前にリンクを書き換えたりバナーをスタンプしたり、または内部転送がボディを再エンコードしている。このページの診断セクションを送る；修正はあなたの DNS ではなく、相手のゲートウェイにある。
オーナーにレポートを送る
クライアントや雇用主のためにこれを修正している場合、証拠で締めくくる。変更しているホップを修正したら、無料スキャンを再実行し、採点レポートをビジネスオーナーに転送する：日付入りで平易な言葉で、DKIM と DMARC が1ページに立っている。それがサイバー保険更新や次の取引先アンケートに必要な成果物だ — 会社を出るメールが今や届くメールと同じであることの証明だ。
ドメインをチェックする → · 「DKIM signature not valid」ガイド → · DKIM を修正する → · 採点方法 → · 集計データのみ使用。データは EU 内で保存・処理。