DKIMエラー：各エラーの意味と対処法

DomainKeys Identified Mail（DKIM）は、電子メール認証の基盤となる重要な要素の一つです。DKIMは、送信メッセージに暗号署名を付加することで、受信側のメールサーバーが、そのメールがドメイン所有者によって正当に承認されたものであること、および転送中に内容が改ざんされていないことを確認できるようにします。

しかし、受信サーバーが受信メールを検査した際、ヘッダーに「dkim=fail」というステータスが含まれていると、認証は失敗します。DKIMの失敗は、Google Workspace、Microsoft 365、Apple Mailなどの受信ゲートウェイに対し、メッセージ本文が送信元を離れた後に改ざんされたか、DNSから公開鍵を取得できなかったか、あるいは暗号署名自体が無効であることを示します。

ドメインのDMARCポリシーや受信側のセキュリティ設定によっては、DKIMの検証に失敗すると、正当なビジネスメールがスパムフォルダに振り分けられたり、完全に拒否されたりすることがあります。このガイドは、エラーメッセージの具体的な参照資料として、メールヘッダーに記載されている正確なエラーメッセージを診断し、根本原因を特定して、問題を迅速に解決するのに役立ちます。

DKIMが失敗する一般的な理由

DKIMの検証失敗は、最終的にはハッシュの不一致や鍵の取得失敗に起因するものですが、実際の運用上の原因は通常、いくつかの予測可能なカテゴリーに分類されます。これらの根本原因と、メールヘッダーに記載されている具体的なエラーメッセージとを照らし合わせることで、解決策を直接見つけることができます。

1. メールゲートウェイおよびセキュリティアプライアンスによるメッセージの変更

企業環境においてDKIM検証に失敗する最も一般的な原因は、DKIM署名がすでに適用された後に、中間サービスがメッセージの内容を変更してしまうことです。セキュリティアプライアンス、送信ゲートウェイ、スパム対策フィルター、およびデータ漏洩防止（DLP）ツールは、企業用のフッターを追加したり、追跡リンクを挿入したり、文字セットを再エンコードしたり、MIME境界を変更したりすることで、送信メッセージを改変することがよくあります。 

これらのアプライアンスを通過する前に、プライマリメールサーバーで署名が行われた場合、受信側が計算した本文のハッシュ値は元の署名と一致せず、「dkim=fail」（本文のハッシュ値が検証に失敗した）というエラーが発生します。

2. メーリングリストと自動メール転送

メーリングリストにメールが送信されたり、中間メール転送エージェント（MTA）を経由して自動転送されたりする場合、転送サーバーがメッセージのヘッダー（件名や宛先など）を変更したり、メーリングリスト管理用のフッター（購読解除リンクやリストの免責事項など）を追加したりすることがよくあります。暗号署名はこれらの要素も対象としているため、署名後に変更が加わると、検証が無効になってしまいます。 

Authenticated Received Chain（ARC）のような最新のプロトコルは、転送者が認証状態を維持するのに役立ちますが、転送されたメッセージに対する生のDKIMチェックは、しばしば失敗します。

3. DNS TXTレコードの欠落、設定ミス、または切り捨て

受信メールサーバーは、selector._domainkey.yourdomain.com にある特定の DNS TXT レコードから公開鍵を取得する必要があります。この DNS レコードが存在しない場合、誤ったセレクタ名で公開されている場合、または DNS の伝播遅延により取得が遅れる場合、受信側は鍵を取得できず、dkim=fail（署名用の鍵なし）というエラーが発生します。

さらに、2048ビットのRSA鍵に関しては、特定の一般的な問題が発生します。RFC 1035では、DNS TXTレコード内の個々の文字列は255バイトに制限されています。 Base64エンコードされた2048ビットのRSA鍵の長さは、およそ392文字になります。DNSプロバイダーや管理者が、2048ビットの鍵を引用符で囲まない単一の文字列として貼り付けた場合、古いDNS管理ツールでは鍵のペイロードが切り捨てられ、DNS内の公開鍵が不完全となり、「dkim=fail」（署名の検証に失敗）というエラーが発生する可能性があります。

4. 鍵の不一致、予告なしの鍵の更新、およびプロバイダーの移行

DKIMの検証が成功するためには、送信メールサーバーが署名を生成するために使用する秘密鍵が、DNSに登録されている公開鍵と数学的に一致している必要があります。以下の場合、暗号的な不一致が発生します：

• 署名用メールサーバーは新しい秘密鍵を生成しますが、DNSレコードは同時に更新されません。
• メールサービスプロバイダー（ESP）は、公開されているTXTレコードやCNAMEのターゲットを更新することなく、署名鍵をローテーションします。
• ドメインが新しいホスティングプラットフォームに移行される一方で、メールサーバーは引き続き古いセレクターまたは使用停止となった鍵ペアを使用して署名を行っています。

5. DNSレコードの構文エラーと厳格な正規化設定

公開鍵レコードにわずかな書式上の不備（セミコロンが欠落している、Base64エンコードされた鍵のペイロード内に余分なスペースがある、タグ名が間違っているなど）があると、受信側のMTAによってその公開鍵を解析できなくなります。 

同様に、署名サーバーがヘッダーや本文の内容に対して単純な正規化（c=simple/simple）を使用している場合、中継サーバーによって生じたわずかな改行形式の変換（CRLF 対 LF）や末尾の空白の調整でさえ、検証が失敗してしまいます。

レビュー DKIMレコードの構文.

6. サードパーティのメールプロバイダーに対してDKIMを設定していません

組織を代表してメールを送信するために複数のサードパーティ製メールベンダーを利用している場合は、送信メールでDKIMを有効にする方法について、各ベンダーに問い合わせて指示を受ける必要があります。このサードパーティ製サービスに登録された独自のカスタムドメインやサブドメインを使用して顧客にメールを送信している場合は、必ずベンダーにDKIMの設定を代行するよう依頼してください。

理想を言えば、メール業務のアウトソーシングをサードパーティのベンダーに委託している場合、そのベンダーが自社のDNSにDKIMレコードを公開して、お客様のドメインを設定してくれるはずです。その際、 DKIMセレクタ を使用して、貴社のDNSにDKIMレコードを公開することでドメインを設定してくれるのが理想的です。これにより、貴社が直接手を加える必要がなくなります。

または 

DKIMの鍵ペアを生成し、秘密鍵をメールプロバイダーに引き渡す一方で、公開鍵を自社のDNSに公開することができます。 

設定ミスはDKIMの失敗につながる可能性があるため、サービスプロバイダーとはDKIM設定について率直にコミュニケーションを取る必要があります。 DKIM設定について、サービスプロバイダーと率直にコミュニケーションを取る必要があります。 

注：一部のサードパーティ製メールサーバーでは、メッセージ本文に書式付きフッターが挿入されることがあります。これらのサーバーがメール転送プロセスの中継サーバーとなっている場合、結合されたフッターがDKIM検証の失敗の一因となる可能性があります。 

7. サーバー通信における問題

状況によっては、DKIMが無効になっているサーバーからメールが送信される場合があります。そのような場合、お客様のインフラ内の他のサーバーが正しく設定されていても、そのメールのDKIM検証は失敗します。通信を行う双方がDKIMを適切に有効にしていることを確認することが重要です。 

8. DNSの障害／DNSのダウンタイム

これはDKIM失敗の一般的な理由である。DNSの停止は、サービス拒否攻撃を含むさまざまな理由で発生する可能性があります。ネームサーバーの定期的なメンテナンスも、DNS停止時間の背景にある可能性があります。この（通常は短い）期間中、受信者サーバーはDNSクエリを実行できません。 

DKIMはTXT/CNAMEレコードとしてDNSに存在することが分かっているので、クライアント・サーバーは認証時に送信者のDNSに公開鍵を問い合わせるルックアップを実行します。停電時には、これは不可能と判断されるため、DKIMを破壊する可能性があります。 

9. OpenDKIM の使用

OpenDKIM は、自前のメールサーバーに導入して、送信メールの署名および検証を行うことができるオープンソースのDKIM実装です。セルフホスト型のOpenDKIM環境を使用する場合、このサービスは通常、ポート8891を介してメールサーバーと通信します。

OpenDKIMが正しく動作していることを確認するには、サーバー上でポート8891が開いており、アクセス可能であることを確認してください。また、必要な権限が正しく設定されているかどうかも確認してください。権限の設定が正しくない場合、OpenDKIMがソケットにアクセスできなかったり、ソケットへのバインドが正しく行えなかったりする可能性があります。

サーバーの設定と、OpenDKIMソケットが格納されているディレクトリを確認し、そのディレクトリが存在すること、および適切な所有権とアクセス権が設定されていることを確認してください。

10. DKIM チェックにおける整合性の不一致

もしあなたが DMARC が設定されている場合、 DKIMチェックでは、メールヘッダーのDKIM署名にあるd=フィールドのドメイン値が、Fromアドレスに記載されたドメインと一致する必要があります。この一致は厳密な一致（両ドメインが完全に一致すること）か、組織単位レベルでの一致を許容する緩やかな一致のいずれかです。 

DKIM署名ヘッダーのドメインが「From」ヘッダーに記載されているドメインと一致しない場合、DKIMエラーが発生する可能性があります。これは、 ドメインスプーフィング やなりすまし攻撃の典型的な例である可能性があります。 

DKIM失敗エラーの解説（エラーメッセージ別）

以下のリストから、発生したエラーを特定し、受信サーバーでどのような問題が発生したのか、またその解決方法を確認してください。

dkim=fail（本文のハッシュが検証に失敗しました）

「dkim=fail（本文のハッシュが検証されなかった）」というエラーは、DNS から公開鍵の取得に成功し、署名ヘッダー全体の形式も正しいものの、受信者が計算したメッセージ本文の暗号ハッシュが、署名の bh= タグに格納されているハッシュ値と一致しないことを示しています。

簡単に言えば、送信サーバーがメールに署名した後、メールの本文が改ざんされたということです。

主な原因：

• アウトバウンドセキュリティゲートウェイ、免責事項ツール、またはCRMプラグインは、署名段階の後に法的免責事項、プロモーション用のフッター、またはトラッキングピクセルを追加しました。
• 中間リレーは、転送中に改行、文字セット、または空白を修正した。
• メール転送またはメーリングリスト用ソフトウェアが、本文のペイロードを改変しました。

解決方法：

1. 送信メールの処理順序を見直し、DKIM署名がメッセージがネットワークインフラを離れる直前の絶対的な最終ステップとして実行されるようにし、署名前にすべてのフッターや追跡リンクが確実に追加されるようにしてください。
2. メールサーバーが「relaxed」形式の本文正規化（c=relaxed/relaxed または c=relaxed/simple）を使用していることを確認してください。これにより、転送中に生じる些細な空白や改行の差異が許容されます。
3. DKIMヘッダーで l=（長さ）タグを使用している場合は、それを削除してください。l= タグは、署名対象となる本文の範囲を制限し、セキュリティ上の脆弱性を生じさせる一方で、本文の改ざんに関する問題を解決することはできません。

dkim=fail（署名用の鍵がありません）

「dkim=fail（署名用の鍵が見つかりません）」というエラーは、受信サーバーがメールのDKIM-Signatureヘッダーからドメイン（d=）とセレクタ（s=）を抽出し、s=._domainkey.d= に対してDNSクエリを実行しようとしたものの、有効な公開鍵レコードを取得できなかった場合に発生します。

このエラーにより、問題は具体的にDNSの設定またはセレクタの不整合に絞り込まれます。

主な原因：

• 送信元アプリケーションで指定されたセレクタ名が、DNSで公開されているセレクタプレフィックスと一致しません。
• TXTレコードまたはCNAMEレコードは、権威DNSサーバーに一度も公開されたことがありません。
• DKIMレコードは最近公開されたばかりで、世界中のDNSリゾルバーにまだ完全に反映されていません。
• ドメインの移行または鍵の整理中に、公開鍵レコードが誤って削除されてしまいました。

解決方法：

1. 生のメールヘッダーを確認し、s=タグ内の正確なセレクタ文字列を特定してください。
2. selector._domainkey.yourdomain.com に DNS TXT レコードまたは CNAME レコードが存在することを確認してください（セレクタ文字列の確認方法については、 DKIMセレクタの探し方）を参照してください）。
3. DNSレコードに、p=の公開鍵ペイロードに加え、必須のv=DKIM1;およびk=rsa;（またはk=ed25519;）タグが含まれていることを確認してください。

dkim=fail（署名の検証に失敗しました）

ボディのハッシュ処理の失敗とは異なり、「dkim=fail」（署名の検証に失敗）というエラーは、メインの署名文字列（b=タグ）の暗号学的評価に失敗したことを意味します。受信側はDNSから公開鍵を取得しましたが、その鍵ではヘッダー署名のペイロードを復号および検証することができませんでした。

このエラーは、無効なキーペアまたは変更されたヘッダーフィールドを直接示しています。

主な原因：

• 鍵ペアの不一致: 送信サーバーがメッセージの署名に使用した秘密鍵が、そのセレクタの下でDNSに公開されている公開鍵と一致しません。
• 切り捨てられたDNS鍵: 2048ビットの鍵が、255バイトを超える単一の文字列として誤って公開されたため、DNSサーバーが公開鍵データを切り捨ててしまった。
• ヘッダーの改変: 署名が生成された後、中間メールサーバーまたはゲートウェイによって、署名の h= タグに明示的に含まれているヘッダー（From、To、Subject、Date など）が変更された。

解決方法：

1. DNS内の2048ビットの公開鍵レコードが、それぞれ255バイト以下の引用符で囲まれた複数の文字列に正しく分割されているか確認してください。
2. メールサーバー上の秘密鍵が、公開されている公開鍵と一致していることを確認してください。不明な場合は、新しい鍵ペアを生成し、DNSを更新した上で、一致していることを確認してください。
3. 転送中に、中間にあるセキュリティアプライアンスが署名付きヘッダーフィールドを変更しないようにしてください。

DKIM ソフトフェイル

電子メールの認証において、 「ソフトフェイル」はDKIMプロトコルのネイティブステータスではありません。SPFではSoftFail（~all）という結果が明示的に定義されているのに対し、RFC 6376ではDKIMの結果は、pass、fail、policy、neutral、temperror、またはpermerrorのいずれかに厳密に定義されています。

管理者やメールセキュリティツールが「DKIMソフトフェイル」を報告する場合、通常は次の2つのシナリオのいずれかを指しています：

1. p=none での DMARC 評価: メッセージはDKIM認証に失敗しましたが、ドメイン所有者のDMARCポリシーがモニタリングモード（p=none）に設定されているため、受信側のメールボックスプロバイダは、内部評価ステータスを「ソフト失敗」としてマークしつつ、そのメールを受信トレイに配信します。
2. ゲートウェイ固有の分類：メールセキュリティゲートウェイ（Cisco Secure Email や Mimecast など）では、メールが DKIM 検証に失敗したものの、SPF 検証に合格し、かつDMARC アラインメントが適切である場合、内部診断ラベルとして「ソフトフェイル」などを出力することがあります。これは、そのメッセージ全体としては配信が許可されていることを意味します。

ログに「soft fail」というラベルが表示された場合は、通常のDKIMエラーとして扱い、ヘッダーを確認して、その原因となっているRFCエラー文字列（本文のハッシュが検証されなかった、または署名用のキーがない）を確認してください。

その他に発生する可能性のあるDKIMエラー

受信メールサーバーは、Authentication-Resultsヘッダーに、以下の標準化されたDKIM診断コードを出力する場合もあります。

DKIMは失敗したが、SPFは合格した（その他、結果がまちまちだった）

メールの配信状況レポートを確認する際、プロトコルの結果に矛盾が見られるケースが頻繁に発生します。トラブルシューティングを行う上では、受信ゲートウェイがこれらの組み合わせをどのように評価しているかを理解することが不可欠です。

DMARC仕様（RFC 7489）では、以下の条件を満たす限り、その電子メールはDMARCの全体的な検証に合格することになります。 少なくとも1つの 基盤となるプロトコル（SPFまたはDKIM）のいずれかが「PASS」ステータスを返せば かつ 可視の「From:」ヘッダーに表示されているドメインと適切に一致している限り、その電子メールはDMARCの全体的な検証に合格します。

以下は、一般的なプロトコルの組み合わせが配信時にどのように処理されるかを示したものです：

なぜDKIMが原因でメッセージがブロックされるのですか？

SPFは通過したものの、DKIMの検証に失敗したためにメッセージがブロックされたり、スパムとしてマークされたりしている場合は、次の2つのうちのいずれかの状況が発生しています：

1. SPFの整合性が取れていません: サードパーティのサーバードメイン（例：mail.mcsv.net）についてはSPFチェックに合格しましたが、実際の「From:」ヘッダーのドメインと一致しませんでした。SPFの整合性が取れておらず、DKIMも完全に失敗したため、DMARCは失敗しました。
2. 送信者に対する厳格な規制： GoogleやMicrosoftなどの主要な受信側は、一括送信者に対して厳格なセキュリティポリシーを適用しています。メールに構造的な認証上の不備があり、かつスパムに関する苦情のシグナルが高い場合、受信側のアルゴリズムは、一部の認証基準を満たしていても、そのメッセージをブロックする可能性があります。

ポリシーの適用がコンプライアンス違反のメールにどのような影響を与えるかを理解するには、 DMARCポリシー とは何かについて解説したガイドを参照し、弊社の無料 DMARCレコードチェッカーを使用してドメインをテストしてください。

メールヘッダーのDKIM結果の読み方

具体的なエラーメッセージを確認するには、配信されたテストメールの生のインターネットヘッダーを確認する必要があります。

手順 1：メールクライアントでRawヘッダーを表示する

• Gmail： メッセージを開き、「返信」ボタンの横にある縦に並んだ3つのドットをクリックして、「元のメッセージを表示」を選択します。
• Microsoft Outlook (Web): メッセージを開き、アクションバーの「…」をクリックして「表示」を選択し、「メッセージの詳細を表示」をクリックします。
• Apple Mail: メールを開き、上部のメニューバーにある「表示」をクリックし、「メッセージ」にカーソルを合わせ、「生データ」を選択します。

ステップ 2: 「Authentication-Results」ヘッダーを探す

生のヘッダーテキストをスクロールして、「Authentication-Results」ブロックを見つけます。「dkim=」というエントリを探してください。

エラーが発生している典型的なヘッダーエントリは、次のようになります：

Authentication-Results: mx.google.com;
dkim=fail (本文のハッシュが検証されませんでした) [email protected] header.s=s1 header.b=W8xKz2L;
spf=合格 (google.com: [email protected] のドメインは 192.0.2.1 を許可された送信者として指定しています) [email protected];
dmarc=合格 (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

確認すべき主要なヘッダータグ：

• dkim=: 直近の検証ステータス（合格、不合格、永続エラーなど）を表示し、その後に括弧で囲まれた具体的なエラーメッセージを表示します。
• header.i=: そのメールに署名した本人またはドメインを表示します。
• header.s=: DNSから公開鍵を取得するために使用された正確なセレクタを識別します。
• header.d=: 署名に対する責任を負う組織のドメインを示します。

生のメールヘッダーを手作業で確認するのは、複雑で時間がかかり、全体的に不便な作業になりがちです。 当社の無料 メールヘッダーアナライザー ツールをご利用いただければ、SPF、DKIM、DMARCの認証結果を、人間が直感的に理解できる形で即座に把握できます。 

DKIMエラーの修正方法と再発防止策

送信インフラ全体におけるDKIMの問題を解決するには、以下の体系的な是正ワークフローに従ってください：

1. DNS 内の公開鍵の有効性を確認する

当社の DKIMレコード検索 などのオンライン検索ツールを使用して、selector._domainkey.yourdomain.com に公開されている公開鍵を確認してください。

• 構文エラー、タイプミス、またはセミコロンが二重になっていないことを確認してください。
• キーの適切なチャンキングを確認してください：2048ビットのキーを使用する場合は、DNSエディタがペイロードを255文字未満の引用符で囲まれた文字列セグメントに分割していることを確認してください（例：「v=DKIM1; k=rsa; p=part1…」 「part2…」）。同じセレクタに対して別々のTXTレコードを作成しないでください。

2. DKIM署名を最終的な送信ホップに移す

組織内で、セカンダリセキュリティゲートウェイ、免責事項ツール、またはCRMソリューションを介して電子メールを中継している場合は、これらのツールによる処理が完了した後にDKIM署名が行われるようにしてください。アプライアンスでコンテンツを変更する必要がある場合は、そのアプライアンスがドメインに代わって最終的なDKIM署名処理を行うように設定してください。

3. 正規化設定の更新

メールサーバーの正規化設定を「relaxed/relaxed」（またはDKIMヘッダー内の「c=relaxed/relaxed」）に変更してください。これにより、受信メールサーバーはハッシュを再計算する前に、空白、末尾のスペース、およびヘッダーフィールドの書式を正規化するよう指示され、転送過程での些細な変更によって引き起こされる誤った検証失敗を防ぐことができます。

4. ローテーション時の鍵ペアの整合性を確保する

DKIMキーをローテーションする際は、必ずまずDNS上で新しいセレクタ名の下に新しい公開鍵を登録してください。DNSの反映に24～48時間かかるため、その時間を待ってから、メールサーバーを設定して新しい秘密鍵でメッセージに署名するようにしてください。移行が完了した後も、古いセレクタで署名された送信中のメッセージやキューに蓄積されたメッセージが引き続き検証できるよう、数日間はDNS上の古い公開鍵レコードを残しておいてください。

なお、本記事では、DKIMでよく見られるエラーメッセージとその考えられる原因について解説し、その解決策も提示しました。ただし、お客様のドメインやサーバーに固有の、本記事では取り上げていないさまざまな根本的な理由により、エラーが発生する場合もあります。 

組織内で認証プロトコルを実装したり、ポリシーを適用したりする前に、認証プロトコルに関する知識を十分に身につけておく必要があります。DKIM、SPF、またはDMARCの検証に失敗すると、メールの配信率に影響を及ぼす可能性があります。 

よくあるご質問

「body hash が検証されませんでした」とはどういう意味ですか？

「Body hash did not verify」とは、DNS で公開鍵が見つかり、ヘッダー形式も有効であったにもかかわらず、メッセージの内容が署名後に変更されたことを意味します。転送中に（免責事項の追加、セキュリティゲートウェイによる処理、再エンコード、または転送などにより）本文が変更されたため、受信者が計算したハッシュ値が、署名の bh= タグに記録されていた元のハッシュ値と一致しませんでした。

DKIMの失敗はどのように解決すればよいですか？

DKIMの失敗を解決するには、メールの「Authentication-Results」ヘッダー内で正確なエラー文字列を特定してください。エラーが「キーの欠落」（署名用のキーがない）である場合は、DNS内の正しいセレクタの下で公開鍵のTXTレコードを公開するか、修正してください。 エラーが本文ハッシュの不一致（本文ハッシュの検証に失敗）である場合は、すべてのフッターやリンクの追加が完了した後の最終ステップとしてDKIM署名が行われるようメールフローを調整し、正規化（canonicalization）を「relaxed/relaxed」に設定してください。

DKIM違反とはどういう意味ですか？

「DKIM違反」とは、特定のメールセキュリティゲートウェイにおいて、受信メールがDKIMの検証チェックに失敗したことを示すために使用される用語です。これは通常、暗号署名が無効であったか、送信中にメッセージが改ざんされたか、あるいは送信者が表示されている送信者アドレスと一致しないドメインを使用してメールに署名しようとしたことを意味します。

DKIMの検証に失敗すると、メールは配信されないのでしょうか？

必ずしもそうとは限りません。ドメインに有効なSPFレコードがあり、適切なDMARCアラインメントを満たしている場合、そのメールはDMARC検証全体を通過し、ほとんどの場合、受信トレイに届くことになります。ただし、SPFのみに依存していると、メールが転送された際に配信率が低下するリスクがあります。さらに、両方のプロトコルでDMARC検証に失敗し、ドメインポリシーが「p=quarantine」または「p=reject」に設定されている場合、そのメールはスパムフォルダに振り分けられるか、完全に拒否されます。