用語 · DKIMの確認

アプリケーションメールのDKIMはどう確認するのか

信頼できるDKIMの確認には、実際に配信されたメッセージを使います。DKIM-Signatureヘッダーを読み、署名ドメイン（`d=`）とセレクター（`s=`）を取り出し、`<selector>._domainkey.<domain>`にある対応するDNSの鍵を問い合わせ、署名されたヘッダーと本文を暗号的に検証します。そのうえで、信頼できる受信側のAuthentication-Resultsを確認します。レコードの有無、署名の検証、DMARCのアライメント、受信サーバーによる受け付け、受信トレイへの到達は、それぞれ別の結果として扱ってください。

DKIMの確認は4つの別々のテストとして扱う

DNSルックアップだけではDKIMの確認として不十分です。第1に、メッセージにDKIM-Signatureフィールドが含まれていることを確認し、テストしたい署名を特定します。第2に、その署名が指定する公開鍵のレコードを取得して解析します。第3に、署名されたヘッダーと正規化された本文が、暗号署名と引き続き一致することを検証します。第4に、合格した署名ドメインが、DMARCの観点で表示上のFromドメインとアライメントしているかを判断します。これらの層は、それぞれ異なる問いに答えるものです。公開されたレコードが使われていないこともあれば、メッセージが存在しないセレクターを参照していることも、コンテンツの変更後に署名が失敗することも、暗号的には合格しても作成者ドメインとアライメントしていないこともあります。緑色のバッジひとつで示すのではなく、それぞれの結果を記録してください。また、送信経路の状態とメールボックスの状態も区別しておきます。プロバイダーによる受け付け、受信サーバーによる受け付け、受信トレイへの到達は、DKIMの検証結果ではありません。

実際のメッセージの署名から始める

通常のアプリケーションの経路で届いた、管理下の受信者からrawメッセージを取得します。各DKIM-Signatureフィールドについて、`d=`の署名ドメイン、`s=`のセレクター、`a=`のアルゴリズム、`c=`の正規化モード、`h=`の署名対象ヘッダーのリスト、`bh=`の本文ハッシュ、`b=`の署名データ、そして存在する場合はタイムスタンプを記録します。RFC 6376は署名ドメインとセレクターのタグを定義しており、それらを使って公開鍵を特定します。プロバイダーのダッシュボードからセレクターを推測したり、セレクターなしで`_domainkey`を問い合わせたりしてはいけません。メッセージには、送信者、中継者、メーリングシステムによる複数の署名が付いていることがあるため、署名ごとに結果を保存してください。本番環境のメッセージを公開のチェッカーに貼り付けるのは避けましょう。rawのヘッダーと本文からは、受信者、メッセージ識別子、ルーティングの詳細、配信停止用のトークン、アプリケーションのコンテンツが漏れる可能性があります。アクセスが制限されたストレージを使い、全文が不要な場合は伏せ字にした診断用のコピーを使ってください。

正確なセレクターと署名ドメインを問い合わせる

署名から、`<selector>._domainkey.<signing-domain>`という形式でDNS名を組み立てます。ヘッダーに`s=app2026`と`d=notify.example.test`が含まれている場合は、`app2026._domainkey.notify.example.test`のTXTを問い合わせます。問い合わせた名前、リゾルバー、レスポンス、TTL、CNAMEチェーンがあればそれも記録してください。テキストの断片を検索するのではなく、得られたタグと値の形式のレコードを解析します。レコードでは、バージョン、鍵の種類、サービスの制限、フラグ、ハッシュアルゴリズム、公開鍵のデータを宣言できます。公開鍵の値が空であれば、その鍵は失効しています。NXDOMAIN、空の応答、不正な形式の内容、未対応のアルゴリズム、使用できない鍵、一時的なリゾルバーの障害を区別してください。変更したレコードのルックアップは、TTLの期限切れ後に独立したリゾルバーで再度行いますが、すべての受信側がすぐに更新されたとは考えないでください。DNSの成功が証明するのは、その時点でレコードが返されたことだけです。テストしたメッセージが検証に合格することも、プロバイダーが現在のトラフィックをそのセレクターで署名していることも証明しません。

ヘッダー、本文ハッシュ、署名を検証する

DKIMの検証は、署名で宣言された正規化ルールに従って行われます。検証者は本文を正規化してハッシュを計算し、`bh=`と比較します。また、`h=`に列挙された署名対象ヘッダーを正規化し、仕様どおりにDKIM-Signatureフィールドを組み込み、公開鍵で`b=`を検証します。これらの変換を文字列操作で再現するのではなく、メンテナンスされている検証ライブラリか、受信側の信頼できる認証結果を使ってください。本文ハッシュの不一致は、多くの場合、署名後に本文が変更されたことを意味します。一方、ヘッダーの署名の失敗は、署名対象ヘッダーの変更、誤った鍵、署名データの破損、実装の誤りを示している可能性があります。どのフェーズで失敗したかを記録しましょう。From、Subject、Date、Message-IDなどの重要なフィールドが署名されているかも確認しますが、万能の署名対象ヘッダーのポリシーをでっち上げてはいけません。正規化によって許容されるのは定義された書式の変更だけです。任意のフッターの挿入、MIMEの書き換え、改行コードの破損、送信経路での改変が安全になるわけではありません。

受信側の結果はその信頼境界の中で読む

RFC 8601はAuthentication-Resultsヘッダーと、none、pass、fail、policy、neutral、temperror、permerrorを含むDKIMの結果を定義しています。passは、受信側が検証テストに合格した有効な署名を見つけたことを意味します。temperrorは、鍵のルックアップの一時的な失敗など、変化する可能性の高い状態を反映していることがあります。permerrorは、修正しない限り後で試しても成功する可能性が低いものです。提供されている場合は、報告した認証サービス、署名ドメイン、セレクター、アルゴリズムを記録してください。送信者は送信前に偽造したAuthentication-Resultsフィールドを追加できるため、受信システムが文書化している境界の内側で挿入された結果だけを信頼してください。最終的な受信環境について、信頼できる結果のうち最も上にあるものを確認し、中間のホップも考慮します。受信側によって結果が異なる場合は、メッセージの正確なバージョン、DNSの見え方、評価時刻、対応しているアルゴリズム、ローカルポリシーを比較してください。`dkim=pass`を、メールボックスプロバイダーがコンテンツを承認した、あるいは受信トレイに振り分けたという主張に置き換えてはいけません。

DMARCのアライメントはDKIMの合格とは別に確認する

DKIMの合格は`d=`の署名ドメインを認証するものであり、そのドメインが表示上のRFC 5322のFromドメインと一致することを求めるものではありません。RFC 9989では、DKIMで認証された識別子がDMARCに使われるのは、該当するstrictまたはrelaxedのアライメントモードのもとで作成者ドメインとアライメントしている場合に限られます。たとえば、`billing.example.test`からのメッセージが`d=provider.test`で署名されている場合、DKIMには合格してもアライメントはしていません。`d=example.test`による有効な署名は、組織ドメインの算出とポリシーによっては、relaxedモードでアライメントする場合があります。DKIMの結果、署名ドメイン、アライメントの判定という3つの項目を報告してください。DKIMが失敗した場合やアライメントしていない場合でも、アライメントしたSPFによってメッセージがDMARCに合格することがあるため、DMARCの合格は特定のDKIM署名が合格したことの証明にはなりません。現在のGmailの送信者ガイドラインには、該当するトラフィックに対する認証とアライメントの要件が含まれていますが、それらを満たしても受信サーバーによる受け付けやメールボックスでの振り分けが保証されるわけではありません。

現行のアルゴリズムと鍵のローテーションを確認する

RFC 8301はDKIMの暗号要件を更新しています。署名者は`rsa-sha256`を使わなければならず、検証者はそれに対応しなければならず、`rsa-sha1`は使ってはなりません。また、RSAの署名鍵を1024ビット以上とすることを求め、運用上可能であればより長い鍵が望ましい理由も説明しています。チェッカーはアルゴリズムを特定し、廃止された情報や使用できない情報を指摘すべきですが、鍵の長さだけでメールストリームが信頼できると主張してはいけません。プロバイダーのワークフローはそれぞれ異なります。Amazon SESのドキュメントでは、Easy DKIMはデフォルトで2048ビットの鍵を使用するとされており、中間ステップを挟まずに署名方式を変更すると、メッセージにDKIM署名が付かない期間が生じる可能性があると警告しています。ローテーションは、有効なセレクターを2つ用意するか、プロバイダーが文書化している重複期間の仕組みを使って計画してください。新しいメッセージが新しいセレクターを使っていることを確認し、遅延したメールが届く可能性がある間は古い公開鍵を残し、重複期間が終わってから削除します。秘密の署名鍵を、DNS、ログ、チケット、プロンプトに公開してはいけません。

失敗はメッセージを起点に外側へ向かって診断する

確認が失敗したら、DNSを変更する前にrawメッセージと受信側の結果を保存してください。想定したアプリケーションとプロバイダーが実際にそのメッセージを生成したことを確認します。署名がない場合は、そのID、リージョン、テナント、メッセージの種類で署名が有効になっていたかを調べます。セレクターのルックアップが失敗する場合は、`d=`と`s=`の正確な値、DNSゾーン、CNAMEの参照先、TTL、最近のローテーションを比較します。鍵は解析できるのに本文ハッシュが失敗する場合は、ゲートウェイ、メーリングリストのフッター、トラッキングによる書き換え、MIMEの変換、改行コード、署名後にコンテンツを変更する可能性のあるセキュリティ製品を確認します。本文ハッシュは一致するのに暗号署名が失敗する場合は、署名対象ヘッダーの変更、鍵の不一致、署名の実装を調べます。DKIMは合格するのにDMARCが失敗する場合は、同じ鍵を公開し直すのではなく、アライメントをテストしてください。該当するTTLや設定の反映を待ってから管理下の受信者で再テストし、成功したサンプルひとつでドメイン全体が修正されたと宣言するのではなく、メッセージの種類ごとに根拠を記録しましょう。

監査可能なDKIM確認の記録を残す

管理下の各メッセージについて、機密性のない相関識別子、送信システム、プロバイダーのアカウントまたはワークスペース、表示上のFromドメイン、受信システム、メッセージの時刻、そして署名ごとの完全な結果を保存してください。`d=`、`s=`、`a=`、正規化、署名対象ヘッダー、DNSクエリの名前、DNSの応答時刻とTTL、鍵レコードのステータス、本文ハッシュの結果、署名の結果、信頼できるAuthentication-Resultsの値、DMARCのアライメントの判定、修正の担当者を含めます。rawメッセージは、アクセスと保持期間の制御が適切な場所にのみ保存してください。テストのシナリオも追加します。通常のアプリケーションからの送信、プロバイダーの移行、鍵のローテーション、ゲートウェイ経由、転送のケースなどです。これにより回帰を比較できるようになり、セレクターやメッセージ処理が変わった後もスクリーンショットが恒久的な証拠として扱われ続けることを防げます。プロバイダーの設定、DNS、署名方式、ルーティングを変更した後や、新しいメッセージの種類を追加した後には再確認してください。運用ダッシュボードでは、不明な状態や取得できない状態を、黙って合格や失敗として扱うのではなく、明示的に表示すべきです。

SendHQがこの確認にどう関わるかを理解する

SendHQでは検証済みFromドメインが必要で、配信イベントを提供しています。DKIMを確認するには、意図したアプリケーションパスを通じて管理されたメッセージを送信し、受信した署名を調べ、実際の`d=`値と`s=`値をクエリし、アライメントを別途記録してください。プロダクトドキュメントだけから、セレクター、キー長、署名アルゴリズム、受信トレイ到達率、配信保証を推測しないでください。

よくある質問

DKIMセレクターはどこで確認できますか？

rawメッセージを開き、DKIM-Signatureフィールドを探します。セレクターは`s=`の値、署名ドメインは`d=`の値です。この2つを使って、DNSクエリ用の`<selector>._domainkey.<signing-domain>`を組み立てます。

DKIMのDNSレコードが見つかれば、DKIMは合格していることになりますか？

いいえ。レコードが提供するのは鍵の情報とポリシーのタグだけです。検証者はそれを使って、対象のメッセージの正規化された本文、署名されたヘッダー、本文ハッシュ、署名データ、アルゴリズムを確認する必要があります。実際に配信されたメッセージでテストしてください。

DKIMが合格してもDMARCが失敗することはありますか？

はい。DKIMは、表示上のFromドメインとアライメントしていない署名ドメインでも検証に合格することがあります。DMARCでは、該当するアライメントモードのもとで、アライメントしたSPFまたはDKIMの識別子が合格している必要があるため、検証とアライメントは分けて報告してください。

DKIMの本文ハッシュが一致しない原因は何ですか？

検証者が受け取った正規化後の本文が、署名者がハッシュを計算した本文と異なっていることが原因です。調査すべき主な箇所として、ゲートウェイ、フッター、トラッキングによる書き換え、MIMEの変換、セキュリティツール、署名後の改行コードの変更があります。診断する前に、正確なメッセージを保存してください。

ローテーション後、古いDKIMセレクターはすぐに削除すべきですか？

いいえ。古い公開鍵で署名されて遅れて届くメッセージも検証できるよう、管理された重複期間中は古い公開鍵を利用可能な状態に保ってください。古いDNSレコードを削除する前に、新しいトラフィックが新しいセレクターを使っていることを確認し、プロバイダーが文書化しているローテーション手順に従いましょう。

DKIMの合格は受信トレイへの到達を証明しますか？

いいえ。評価した受信側において、テストしたメッセージに有効な署名があることを検証するだけです。受信側はメールを受け付けて分類する際に、認証のアライメント、レピュテーション、コンテンツ、苦情、受信者、ローカルポリシーのシグナルを引き続き適用します。

出典

さらに学ぶ

アプリケーションメールのDMARCを確認する方法DMARCレコードの検出、構文、SPFとDKIMのアライメント、ポリシー、レポート、実際のアプリケーションメッセージを、DNSルックアップと配信を混同することなく確認します。メールプロトコルSMTP：アプリケーションメールが届く仕組みSMTPのサブミッション、リレー、エンベロープ、応答コード、TLS、再試行、メッセージの内容が、アプリケーションメールのワークフローをどう形作るのかを学びます。