DKIM failの原因と対処法：診断と修正の手順

Samuel Chenard著2026年11月5日7分で読了

AIに解説を依頼

要旨

DKIM failは受信したメールから診断します。セレクタ、公開鍵、ボディハッシュ、署名経路を確認し、DNSを変更する前に該当する送信元で再テストします。

DKIM fail（DKIMの失敗）とは、受信側がメールのDKIM署名を検証できなかったことを意味します。直すには、DNSを変更する前に、受信したメールの認証結果と署名の詳細から、問題が鍵の参照、署名の設定、メールの処理のどれにあるかを見極めます。

まず、影響を受けたアプリケーションから、失敗したメールを一通用意します。Webサイトのフォーム、従業員のメールボックス、請求サービスは、Fromアドレスのドメインが同じでも、別々の送信経路を使うことがあります。

失敗したメールから集める情報

役に立つDKIM診断は、「DKIM authentication failed」と表示されたスクリーンショットではなく、受信した元のメールから始まります。ソース全体を非公開で保存し、次の情報を記録します。

受信システムのAuthentication-Results（DKIMの正確な結果と理由を含む）。
DKIM-Signatureヘッダーの署名ドメイン（d=）とセレクタ（s=）。
送信アプリケーション、受信システム、タイムスタンプ、中継や転送の経路。
同じ送信元が常に失敗するのか、1つの経路だけで失敗するのか。

自社の受信サービスが付けた結果を使います。メールには他のシステムの認証ヘッダーが含まれることがあり、Authentication-Resultsと書かれているだけでは信頼できません。この信頼の境界はRFC 8601で定義されています。

ヘッダーの証拠を確認するには、メールヘッダー解析が役立ちます。共有する前に、コピーから個人のアドレスや無関係の機密項目を削除し、元のメールは診断用に非公開で保管します。黒塗りすると証拠が変わるため、編集したコピーを暗号学的な検証テストに使ってはいけません。

DKIMの結果ごとの対処法

次に何を確認するかは、DKIMの結果で決まります。none、fail、temperror、permerrorはそれぞれ別の状態を表し、受信側が添える説明でさらに絞り込めます。RFC 8601のDKIM結果の定義をご覧ください。

受信メールの証拠	次の確認
`dkim=none`で、DKIM署名がない	その送信サービスとドメインで署名が有効か確認します。署名のないメールには、検証する署名がありません。
`dkim=temperror`で、DNSタイムアウトなど一時的な参照の理由がある	示された参照先とDNSの可用性を調べます。一時的な状態が解消してから再テストします。タイムアウトだけでは鍵を交換する理由になりません。
`dkim=permerror`、または鍵がない、形式が不正、使用できないと明示されている	該当するセレクタのレコードと送信元の設定を確認します。恒久的なエラーには複数の原因がありうるため、エラー全文を保存します。
明示されたボディハッシュ不一致	body hash did not verifyのガイドに沿って進めます。原因を決める前に、署名時と受信時の段階を比べます。
`dkim=fail`で、役立つ理由がない	セレクタと鍵を確認してから、署名された内容と送信経路を調べます。結果だけでは、どの要素が検証を壊したかは特定できません。
`dkim=pass`で`dmarc=fail`	DKIMアライメントのガイドで、アライメントとSPFの結果を確認します。アライメントのためだけに、機能している鍵を交換しないでください。

ステータスそのものの意味は、用語集のdkim=failをご覧ください。エラーの文言とドメイン名しか手元にない場合は、ドメイン付きのDKIM failのガイドで、まだ足りない証拠を確認できます。

DKIMセレクタと鍵の確認方法

DKIM鍵の参照には、メールのセレクタと署名ドメインを使います。たとえばs=mail2026とd=example.comなら、参照先はmail2026._domainkey.example.comです。これは説明用の参照名で、公開するレコードではありません。この関係はRFC 6376のセクション3.6.2で定義されています。

技術的な例text

dig TXT mail2026._domainkey.example.com +short

Windowsの場合：

技術的な例text

nslookup -type=TXT mail2026._domainkey.example.com

その応答を、該当する送信サービスの現在の設定と比べます。プロバイダーがCNAMEでセレクタを委任している場合は、参照先のTXTの応答も確認します。失敗したメールのセレクタの代わりに、プロバイダー名から推測したセレクタを使ってはいけません。

公開DNSの証拠を確かめるには、DKIMチェックが便利です。ドメインだけの診断では、送信元が使うセレクタを見落とすことがあります。鍵が見つかっても、受信したメールの署名が検証に通る証明にはなりません。

公開鍵と実際の署名者が食い違う場合は、送信元が文書化した手順で該当する設定を直します。レコードを削除する前に、稼働中の他の送信経路を洗い出します。鍵の交換には、古い鍵で署名済みのメールを検証できる状態に保つ、計画的な移行が必要です。セレクタのライフサイクルはRFC 5863のセクション3.5で解説されています。

受信側がアルゴリズムや鍵長の問題を報告している場合は、その証拠に絞って確認します。RSAのDKIMについて、RFC 8301は1024ビット以上の鍵を必須とし、署名者には2048ビット以上を推奨し、rsa-sha1を禁止しています。鍵の古さだけでは、失敗の原因は診断できません。

DNSは正しいのにDKIMが失敗する場合

DKIMのDNSレコードが正しくても、確認すべき点はまだ残ります。該当するアプリケーションが対応する秘密鍵を実際に使ったかを確認し、疑わしい処理の前後で、条件をそろえたメールを比べます。

ボディハッシュのエラーが明示されている場合、受信側が署名のルールで計算したボディハッシュがbh=と一致しなかったことを意味します。正規化、MIMEの変更、署名側の実装の確認は、ボディハッシュ専用の解説で扱っています。通常の書式の変更が、すべて同じ影響を持つわけではありません。DKIMの正規化ルールは一部の違いを許容します。これらのルールと検証手順はRFC 6376のセクション3.4と6.1.3で定義されています。

その他の署名の失敗では、本文だけでなく、署名されたヘッダーと署名の設定も比べます。テストには受信側の正確な理由を添えておきます。「DNSは正しそう」だけでは、修正方法を選べません。

転送サービスやメーリングリストは、署名された内容を変えることがあります。RFC 6377にあるとおり、その経路で失敗しているなら、件名の編集や追加されたフッターは調べる価値があります。必要な変更の後に署名する位置を移したり、原因となる書き換えを取り除いたりする前に、メールの証拠で変更を確かめます。転送の設定やメールの暗号化は、どんなDKIMの失敗も直せる万能策ではありません。

DKIMの修正が効いたかの確認方法

DKIMの修正は、該当するアプリケーションから通常の経路で新しいテストを送って検証します。個人のメールボックスで代用せず、テンプレートや中継も含めて、失敗したのと同じ種類のメールを使います。

新しく受信したメールを確認し、意図した署名ドメインとセレクタを特定します。
信頼できる受信側の結果で、その署名がdkim=passになっているか確認します。
表示上のFromドメインに対するDMARCを別に確認します。無関係なドメインの署名がpassしても、DKIMのアライメントは成立しません。この関係はRFC 7489のセクション3.1.1で説明されています。
失敗が特定の転送経路だけで起きていた場合は、その経路でも再テストします。

該当する送信元から送れるなら、到達率テストをテストの宛先に使えます。直接送るテストでは、経由しない転送の段階までは検証できません。

DKIMが直らないときにサポートへ送る情報

解決しないDKIMの失敗には、再現できる例が必要です。送信プロバイダーには、失敗の日時、送信サービス、受信側の正確な応答、署名ドメインとセレクタ、再現する経路を伝えます。直接のテストはpassし、中継したメールは失敗するのかどうかも含めます。

まずは黒塗りしたヘッダーの証拠を共有します。検証のためにサポートが元のメールを必要とする場合は、認められた非公開のサポート窓口を使います。DKIMの秘密鍵は決して共有しないでください。

DKIM failとブロックリスト入りの関係

DKIM failだからといって、ドメインがブロックリストに載っているとは限りません。署名の検証と、受信側のレピュテーションやフィルタリングの判断は、メール処理の別々の部分です。DKIMがpassしても、迷惑メールに入ることはあります。フィルタリングが認証結果を他の要素とどう組み合わせるかは、RFC 5863のセクション2.5で説明されています。

認証はpassしているのに到達が悪いままなら、メール到達率のガイドと、実際の拒否や振り分けの証拠をもとに調査を続けます。