DKIMで「body hash did not verify」が出る
メールのヘッダーやメールセキュリティ製品のログを確認していると、DKIMの検証結果に次のようなエラーが表示されることがあります。
body hash did not verifyあるいは製品によっては、単純に
DKIM: Failと表示されます。
DKIM Failを見ると、
「送信元が偽装されたメールでは？」
「迷惑メールとして隔離した方がいいのでは？」
と思うかもしれません。
しかし、正常なメールでもDKIM Failになることがあります。
実際にメールを調査してみると、送信元では正常にDKIM署名されていても、配送途中でメール本文が変更されたため、受信側でDKIM検証に失敗するケースがありました。
この記事では、body hash did not verify が何を意味するのか、なぜ正常メールでも発生するのかを説明します。
DKIMのbody hashとは
DKIM（DomainKeys Identified Mail）では、送信側がメールに電子署名を付けます。
DKIM-Signatureヘッダーを見ると、例えば次のような情報があります。
DKIM-Signature: v=1;
a=rsa-sha256;
d=example.com;
s=selector1;
bh=xxxxxxxxxxxxxxxxxxxx;
b=xxxxxxxxxxxxxxxxxxxx;この中の、
bh=が本文（body）のハッシュ値です。
大まかな仕組みは、
送信側
↓
メール本文からハッシュ値を計算
↓
DKIM-Signatureの bh= に記録
↓
メール送信
↓
受信側
↓
受信した本文から再びハッシュ値を計算
↓
bh= と比較となります。
一致すれば本文がDKIM署名後に変更されていないことを確認できます。
逆に、
署名時の本文
↓
ハッシュ A
受信した本文
↓
ハッシュ B
A ≠ Bとなれば、DKIM検証に失敗します。
これが body hash did not verify の基本的な意味です。
正常メールなのになぜDKIM Failになるのか
重要なのは、
DKIM Fail = なりすましメール
ではないことです。
メールは送信者から受信者へ直接届くとは限りません。
例えば、
Microsoft 365
↓
メール中継サービス
↓
メールセキュリティ製品
↓
受信メールサーバーのように複数のシステムを通過することがあります。
DKIM署名した後に、途中のシステムがメール本文を変更すると問題が発生します。
例えば、
送信サーバー
本文：
こんにちは。
↓ DKIM署名
bh=ABC123...だったメールに、中継システムが、
こんにちは。
--------------------
このメールは外部から送信されています。
--------------------などを追加すると、受信側で計算する本文ハッシュが変わります。
その結果、
DKIM body hash
↓
不一致
↓
body hash did not verify
↓
DKIM Failとなります。
メール自体は正規の送信者から送られたものでも発生します。
よくある原因
body hash did not verify が発生した場合は、次のような処理が配送経路にないか確認します。
- メーリングリストによる本文・フッターの追加
- メールセキュリティ製品による警告文の挿入
- URLの書き換え
- MIME構造の変更
- 文字コードやContent-Transfer-Encodingへの影響
- メールゲートウェイによる本文加工
- その他、DKIM署名後に行われるメール本文の変更
特にメーリングリストでは注意が必要です。
例えば、
送信者
↓
DKIM署名
↓
メーリングリスト
↓
本文へフッター追加
↓
受信者となれば、元のメールが正常でもDKIM検証に失敗する可能性があります。
DKIM Failだけでメールを拒否するのは危険
ここが運用上かなり重要です。
例えばメールセキュリティ製品を、
DKIM Pass → 配信
DKIM Fail → 隔離という単純な設定にすると、正常メールまで隔離してしまう可能性があります。
DKIM単独ではなく、SPFやDMARCを含めて判断することが重要です。
例えば、
DKIM FAIL
しかし
SPF PASS
+
SPFで使用したドメインと
Header FromのドメインがAlignment PASS
↓
DMARC PASSとなる場合があります。
DMARCでは、原則としてSPFまたはDKIMのどちらか一方が認証とアライメントの条件を満たせばPASSできます。
そのため、
SPF PASS
DKIM FAIL
DMARC PASSは矛盾した結果ではありません。
逆に、
SPF FAIL
DKIM PASS
DMARC PASSとなることもあります。
調査するときはメールヘッダーを確認する
DKIM Failが発生した場合、まずメールヘッダーの認証結果を確認します。
例えば、
Authentication-Results:
spf=pass
dkim=fail
dmarc=passなら、
「DKIMは失敗しているが、DMARCとしては認証できている」
という重要な情報になります。
さらに DKIM-Signature の、
d=
s=
bh=も確認します。
d= はDKIM署名ドメイン、s= はDNSから公開鍵を取得するためのセレクターです。
配送経路を示す Received: ヘッダーも確認し、
送信元
↓
中継A
↓
中継B
↓
メールセキュリティ
↓
受信サーバーと経路を追います。
途中にメーリングリストやメールセキュリティサービスなどが存在する場合、そこで本文が変更されていないか確認します。
「署名そのものの異常」と「本文変更」を分けて考える
DKIM Failを調査するときは、単に、
DKIM Failだけを見るのではなく、
「なぜFailしたのか」
まで確認することが重要です。
特に、
body hash did not verifyなら、
DKIM署名時と受信時で本文から計算されたハッシュが一致しなかった
という方向から調査できます。
これは「DKIM公開鍵が取得できない」「署名自体の検証に失敗した」といった問題とは切り分けて考える必要があります。
まとめ
DKIMの body hash did not verify は、DKIM署名時の本文と受信側で検証した本文のハッシュが一致しなかったことを示します。
しかし、それだけで悪意あるメールとは判断できません。
DKIM署名
↓
メール配送
↓
中継システム等が本文を変更
↓
本文ハッシュが変化
↓
DKIM Failという正常メールも存在します。
そのためメール運用では、
DKIM Fail
↓
即拒否・即隔離ではなく、
SPF
DKIM
DMARC
Alignment
配送経路
メールヘッダー
↓
総合的に判断することが重要です。
特にDMARCを導入している環境では、DKIM単独のPass/Failだけを見るのではなく、最終的なDMARC判定まで確認するのがおすすめです。
コメント