最も信頼できる場所を見つけるのは、 DKIMセレクター です DKIM-Signature 調査しているメッセージのヘッダー。 s= 値を読み取り、それを同じ署名の d= 署名ドメインとペアにします。
セレクターは、検証資料が公開される場所を識別します。目に見える送信者を特定したり、署名が通過したことを証明したりするものではありません。このガイドでは、受信メッセージから正しいDNS名までの証拠を追跡し、検索で何が確立できるか、何が確立できないかを説明します。
元の受信メッセージを取得する
実際のサービスを通じて別の受信者に送信される、制御されたメッセージを使用します。そこで受信した元のメッセージを保存します。転送されたスクリーンショットや再保存され編集されたメッセージでは、証拠が省略されたり変更されたりする可能性があります。
すべてのDKIM-Signatureヘッダーを見つけます。メッセージには複数のメッセージを含めることができます。署名ごとに、その署名ドメインとセレクターを個別に記録し、信頼できる受信者の検証結果を関連付けます。
- d: 署名ドメイン。
- s: セレクター。
- a: 署名/ハッシュ アルゴリズム。
- h: 選択された署名付きヘッダーのリスト。
- bhとb: ボディハッシュ DNS公開キー レコードではなく、署名値。
これらのフィールドは次のように定義されます。 RFC 6376 §3.5.
表示されている From ドメインを代わりに使用しないでください。 d= キールックアップを構築するとき。 位置合わせ これは、受け渡し署名 ID と可視の From ID との間の後の比較です。
検証名の構築とクエリ
下 RFC 6376 §3.6.2.1、検証名は、同じ署名の 2 つの値を組み合わせたものです。
<セレクター>。 _domainkey .<署名ドメイン>
この合成例では、署名により以下が識別されます。
合成署名にはd=example.comとs=mail2026.
対応するルックアップは次のとおりです。
dig TXT mail2026._domainkey.example.com +noall +answer
プロバイダーがキー管理を委任する場合、 CNAME、そのチェーンも調べます。
dig CNAME mail2026._domainkey.example.com +noall +answer
これらはDNSチェックの例であり、キャプチャされた実際のメッセージの検証ではありません。実際の署名値を使用します。下 RFC 1034 §3.6.2、公開されたエイリアスの場合、意図されたターゲットに従い、チェーンを通じて検証データが利用できることを確立します。
パブリックDNSには、検証キー マテリアルまたはそれにつながる委任が含まれています。秘密署名キーは、承認された署名システムに属しており、 TXTレコード.
検証結果とともにルックアップを解釈する
公開鍵の答えは、リゾルバーがその時点で特定の検証資料を取得できることを示します。メッセージに署名が含まれていること、対応する秘密キーが正しく使用されていること、または署名されたコンテンツがそのまま残っていることは証明されません。
キーは存在するが署名が失敗した場合は、完全な検証結果を調査してください。コンテンツの変更、不正な形式または互換性のない鍵データ、署名の適用範囲、時間関連の条件、およびDNS監視には、さまざまな救済策が必要になる場合があります。
キーが見つからない場合は、正確なキーを確認してください d= そして s=、権限のあるゾーン、 CNAMEターゲット、キーの廃止履歴、およびリゾルバー エラー。チェッカーを緑色にするためだけに、推測されたセレクターを公開しないでください。
オリジナルに関連するDKIM署名がない場合、セレクター検索では署名を作成できません。実際の送信者が署名するように構成されているかどうか、サービスが必要な ID をサポートしているかどうか、後のルートによって証拠が変更されたかどうかを確認してください。
複数の署名とキーのローテーションを処理する
署名とその信頼できる結果ごとに別の行を作成します。サービス自体の受け渡し署名は調整されていない可能性がありますが、顧客ドメインの署名は調整に合格します。別のメッセージには、顧客ドメインの署名が失敗し、無関係な署名だけが渡された可能性があります。
ローテーションの場合は、 DNSでどの 2 つのレコードが利用可能かだけでなく、実際のメッセージがどのセレクターを使用したかを確認してください。構成状態、署名カットオーバー、およびすでに転送中のメッセージの間の関係を維持します。古いセレクターの廃止は、保存または遅延されたメッセージの後の検証に影響を与える可能性があります。
Microsoft 365の場合は、 テナント固有のセットアップ ガイド。ワークスペースの場合は、 選択されたドメインのセットアップ ガイド。どちらのプロバイダーの共通セレクター パターンも、実際の証拠の読み取りに代わるものではありません。
実際のサービスで署名を確認する
サプライヤーがあなたのドメインには DKIM 設定されている場合は、関連するワークフローによって送信されたメッセージと実際に署名したドメインを表示するように要求します。公開されたキーは構成の依存関係の 1 つであり、ライブ署名の証拠ではありません。
これは、複数のツールが同じ表示ブランドを使用している場合に重要です。従業員のメール、サポート チケット、領収書には、セレクター、署名ドメイン、所有者が異なる場合があります。 1 つのチェックが成功しても、残りのチェックの代わりをすることはできません。
署名の所有権と委任を追跡する
サービス、ドメイン、キー管理モデル、ビジネス オーナーに関連付けられたセレクターのインベントリを維持します。キーの直接制御とプロバイダーへの委任を区別します。サービスがオフボードされたときに委任を確認します。
秘密キーへのアクセスを制限し、侵害の疑いに対する対応を定義します。有効な公的記録は、鍵の管理が健全であることを証明するものではありません。同様に、有効な署名は対象コンテンツに対するドメインレベルのアサーションを確立します。支払いリクエストを承認したり、アカウント侵害を排除したりするものではありません。
有用な証拠チェーンは、メッセージ、署名 ID、キー検索、信頼できる検証、および調整です。次のレビュー担当者が診断を再現できるように、これらの観察結果をまとめて保管してください。
実践的なポイント
元のメッセージ、署名 ID、 DNS観察、および信頼できる受信者の結果をまとめて保存します。この証拠により、不足しているキーと、署名されていないメッセージ、失敗した署名、または合格したが一致していない署名が区別されます。
区別を適用する
2 つの仮想署名d=example.com/s=mail2026とd=service.example.net/s=outbound, mail2026._domainkey.example.comとoutbound._domainkey.service.example.netを別々にクエリします。 mail2026 と 2 番目の d を決して組み合わせないでください。各検索時間と信頼できる結果をそのペアと一緒に保持します。後でキーが失われても、以前の信頼された受信者の観察は消去されません。