DKIMとは

DKIMを読むときの前提

DKIM（DomainKeys Identified Mail）は、送信メールに電子署名を付け、受信側がDNS上の公開鍵で署名を検証する仕組みです。本文や一部ヘッダーが途中で改ざんされていないかを確認できます。

実務では、selector、d=ドメイン、公開鍵TXT、秘密鍵の管理、鍵長、署名対象ヘッダー、送信サービスごとのselector、ローテーション、DMARC alignmentを分けて確認します。

証跡には、selector、DKIM-Signatureヘッダー、d=、s=、公開鍵TXT、Authentication-Results、送信サービス、鍵ローテーション予定、確認時刻を残します。

selectorと公開鍵を突合する

DKIMの公開鍵は、selector._domainkey.example.com のようなTXTレコードで公開されます。メールヘッダーの s= と d= から問い合わせるFQDNを組み立て、DNS上の公開鍵と照合します。

送信サービスごとにselectorが異なるため、1つのDKIMレコードだけ見ても全送信経路を確認したことにはなりません。移行中は旧selectorと新selectorが併存します。

• DKIM-Signatureのd=とs=を確認する。
• selector._domainkeyのTXTを権威DNSで確認する。
• 送信サービスごとのselectorを台帳化する。

署名失敗の原因を分ける

DKIMがfailになる原因は、公開鍵不足、selector違い、鍵ローテーション失敗、メール本文の改変、フッター追加、転送サービス、ヘッダー書き換えなど複数あります。DNSだけで結論を出しません。

受信側ではAuthentication-Results、DKIM-Signature、Receivedを同じメールで保存します。送信元サービスのログと受信側判定を突合すると、どこで改変されたかを追いやすくなります。

• 同じメールのヘッダー全体を保存する。
• 署名前後で本文やヘッダーが変わる経路を確認する。
• 公開鍵と秘密鍵ローテーション時刻を突合する。

DMARC alignmentを見る

DKIMがpassしても、d=ドメインがFromドメインとalignmentしていなければ、DMARCでは期待どおり評価されないことがあります。委託送信やSaaS送信では、この差分がよく出ます。

SPFが転送で失敗しても、DKIMがpassしalignmentしていればDMARCを通せる場合があります。SPF、DKIM、DMARCを同じメールで確認します。

• DKIMのpass/failとd=ドメインを確認する。
• Fromドメインとのalignmentを確認する。
• SPF結果とDMARC結果を同じヘッダーで見る。

変更証跡と引き継ぎ

DKIM変更では、selector、公開鍵TXT、送信サービス、鍵長、ローテーション予定、旧鍵削除日、テストメールのヘッダーを残します。秘密鍵は証跡に貼らず、管理場所とローテーション手順だけを記録します。

引き継ぎでは、送信サービスごとのselector、DNS管理者、メール基盤管理者、関連語としてSPF、DMARC、TXTレコード、Authentication-Resultsを残すと確認しやすくなります。

• selectorごとの所有者と用途を記録する。
• 旧公開鍵の削除条件を残す。
• 秘密鍵そのものをドキュメントに貼らない。

関連語

同じ主要カテゴリの用語

メールの学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能