【DKIM】送信ドメイン認証DKIMデータの見方

1 はじめに

本記事は、電子メールにおける送信ドメイン認証方式である
DKIM(Domainkeys Identified Mail)について、
下に示すポイントを理解する観点からデータ様式について説明するものです。

DNSサーバーに登録するTXTレコード
・ 受信メールヘッダーのDKIM項目(DKIM-Signature)
・ 認証結果(Authentication-Results)

また、本記事では、
受信メールの認証結果を簡易に確認できるツールについても、いくつか紹介します。

本記事は、DKIMとはなんであるかとか、
DKIMを利用しようとする際のLinuxなどメールサーバーに対して行うDKIM設定について
示すものではありません。

本記事は、下に示すページを基に、DKIMデータについて整理し直しました。
メールヘッダー解析における、DKIMデータの内容を理解するのが主目的で記述しました。

DKIM (Domainkeys Identified Mail) | 財団法人インターネット協会 迷惑メール対策委員会

なお、本記事であげている表は見栄えの都合上、全部イメージとなっています。
表をご利用されたい場合は、
この記事の最後に添付するPDFからご利用された方が便利かと思います
PDFからのデータ取り込みについては、インターネット等でご検索ください)。

2 公開鍵の提供とADSP・・・DNSサーバーに設定するデータ

2.1 公開鍵の提供

DKIMでは、
送信側のドメインを管理する権威DNSサーバーを使用して、署名に利用する公開鍵を公開します。

公開鍵は、
FQDN(Fully Qualified Domain Name:完全修飾ドメイン名)に対するTXTレコードとして
DNSサーバーに登録します。

鍵の長さは、512ビットから2048ビットをサポートしています。

DKIMでの電子署名では、第三者認証局が発行した電子証明書を利用するのではなく、
OpenSSLなどのツールを使って、
各ドメインの担当者自身が管理するドメインの鍵を自身で作成します。

たとえば、OpenDKIMでは、opendkim-genkeyというツールが提供されており、
DKIMの署名に必要な秘密鍵公開鍵が作成できます。

作成した公開鍵を登録するFQDNの形式を下に示します。

<セレクタ>._domainkey.<ドメイン名>

<セレクタ>は、DKIM-Signatureヘッダーsタグに指定したラベルになります。
<ドメイン名>は、同じくdタグに指定されたドメイン名です。

異なるセレクタを用意することで、
同じドメインに対して複数の公開鍵を運用できるようになります。

公開鍵のレコードは、「タグ=」を“;”で区切り列挙します。

レコードの例を下に示します。

sls.dkim._domainkey.smtest.com. 300 IN TXT "v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3...<省略>"

利用できるタグを表2.1-1に示します。

2.2 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)

2.2.1 ADSP概要

Author Domain Signing Practice(ADSP)とは、
DKIMの認証結果をどのように扱うべきかを示すポリシーを送信側で公開するものです。

DKIMではメールのDKIM-Signatureヘッダーから認証対象のドメインを取り出すので、
Fromヘッダーに指定されている送信者アドレスのドメインと、
署名したドメインが異なる場合があります。

DKIM-ADSPでは、これを次のように整理しています。

メール作成者ドメイン署名であれば、そのメールの送信ドメインは認証されたと判断されます。
ADSPレコードの内容が重要になるケースとしては、
認証成功した署名がないメール、
認証照合した署名のドメインdタグで指定)がメール作成者署名と異なる場合などです。

2.2.2 ADSPレコードの公開

ADSPも、
送信側のドメインを管理する権威DNSサーバーを使用して、
下に示すようTXTレコードで公開します。

_adsp._domainkey.<ドメイン名>

<ドメイン名>は、同じくFromヘッダーのアドレスのドメイン名部分です。

電子署名の認証に使う公開鍵
DKIM-Signatureヘッダーdタグiタグを元に読み出すのに対して、
ADSPFromヘッダー上の送信ドメインから取り出す点には注意が必要です。

ADSPは、“dkim=”で記述します。

には、次のものがあります。

discardableallを公開すると、
署名して送信したメールが配送経路において再署名されるケース(メーリングリストへの投稿等)や、
第三者にメールの送信を委託する場合などにおいて、
受信側に厳しい対応をとられる可能性が考えられます。

そのような状況を考慮する必要のあるメールを送信する場合、
discardableallの公開については十分に注意が必要です。

3 送信側での署名作成とDKIM-Signatureヘッダー

送信側では、電子メールのヘッダーおよびボディを元に電子署名を作成し、
作成した電子署名DKIM-Signatureヘッダーとして追加します。

DKIM-Signatureヘッダーの書式は、“タグ=”の組を“;”で区切って列挙します。

DKIM-Signatureヘッダーの例を下に示します。

タグの一覧を表3.1-1に示します。

4 受信側での処理

4.1 受信側での処理

受信側では、メッセージに付与されたDKIM-Signatureヘッダーを取り出し、
下に手順で署名の照合を行います。

1. DKIM-Signatureヘッダーdタグsタグの値から、
公開鍵を取得するFQDNを作成する。

2. 鍵を取得する。
このとき、iタグに設定してあるメールアドレスのローカルパートが
gタグの条件パターンに合わない場合には、署名の照合を行わない。

3. hタグに記述してあるヘッダーと、メール本文
lタグで有効な本文の長さが指定してある場合には、先頭からその長さだけ切り出したもの)、
および電子署名データ以外のDKIM-Signatureヘッダーの値を併せてハッシュを作成し、
電子署名を作成する。

4. 公開鍵を利用して、電子署名からハッシュを取り出す。

5. 電子署名から取り出したハッシュと、
受信したメールから作成したハッシュを比較して同じであれば認証成功。

DKIMでは、認証する対象の送信ドメインはメールのFromヘッダーから取り出すのではなく、
あくまでも、
DKIM-Signatureというヘッダーに指定されているドメイン名や送信アドレスを対象に認証します。

4.2 認証結果であるAuthentication-Resultsヘッダー

送信ドメイン認証の認証結果を該当のメールヘッダーに記録する場合の方法は、
RFC 5451に標準化されています。

RFC5451では、
認証結果を記録するヘッダーとしてAuthentication-Resultsヘッダーを利用するよう定義しています。

4.2.1 Authentication-Resultsヘッダー

Authentication-Resultsヘッダーの例を下に示します。

Authentication-Results: dkim.example.com;
dkim=pass (1024-bit key) header.i=user@example.com; dkim-adsp=none

このヘッダーには、複数の認証処理の結果を記録できます。
上記の例では、dkimdkim-adspの結果が表示されています。

Authentication-Resultsヘッダーで表示される認証の種類を 表4.2-1に示します。

各認証方法ごとに、その結果を表示できます。

Authentication-Results: 認証実施したFQDN; 認証結果情報; 認証結果情報; ……

1つのAuthentication-Resultsヘッダーで、複数の種類の認証方式による認証結果を表示できます。

1つの認証方式による認証結果情報は、次の形で記録します。

認証結果は、認証処理の結果を表示するもので、
認証方式ラベル=認証結果”の値で表示されます。

4.2.2 Authentication-Resultsのプロパティ情報

プロパティ情報によって認証対象が何であったかを表示することも可能です。
その場合、“認証対象タグ=認証対象”の値で表わします。
複数の認証方式の結果を表示する場合は、“;”で区切って並べられます。

認証方式ラベル認証対象タグとして指定されるものを、 次の表4.2-2に示します。

4.2.3 結果表示

RFC 5451では、 各認証方式ごとにどのようなラベルで認証結果を表すか定義されています。

表4.2-3に、DKIM-ADSPでの結果表示を示します。

5 DKIM結果表示ツール

メールヘッダーには、実際に書かれている項目が多く、
また1項目の文字数が多い場合もあって全体でかなりの文字数になっています。

その中で、メールの配送経路の確認や、SPFDKIMなどの送信元ドメイン認証結果を
確認するのはちょっとした作業となります。

本章では、DKIM認証結果だけを表示してくれるわけではありませんが、
面倒なメールヘッダー解析を手助けしてくれるツールをいくつか紹介します。

① メールソフト(ThunderbirdとWeb版Gmail
② Webのメールヘッダー解析サービス

5.1 メールソフト

よく知られたメールソフトのThunderbirdには、
DKIM署名を検証してくれる”DKIM verifier”というアドオンがあります。
これをインストールすれば、DKIM認証結果を一目で判別できるようになります。

また、Web版Gmailでも、受信メールの「メッセージのソース」を表示すれば、
DKIM認証結果を一目で確認することができるようになっています。

5.1.1 ThunderbirdのDKIM Verifierアドオン

Thunderbirdに ”DKIM verifier”をインストールしていると、
以下に示すようにDKIM認証結果を一目で判別できるようになります。

【DKIM Verifierの機能】

各受信メールにおいて、DKIM認証が成功すれば、
図5.1-1に示すように差出人の背景が 緑色で表示されます。

DKIM認証が失敗した時は、図5.1-2に示すように 差出人の背景が赤色で表示されます。
発信元詐称でDKIM認証に失敗するのは、やはりフィッシングメールで多いです。

【DKIM Verifierのインストール】

DKIM Virifierは、次の手順でインストールします。

1. 図5.1-3において、 メインメニュー/ツール(T)アドオンとテーマ(A)を選択

2. 図5.1-4において、 図右上の「アドオンを探す」で「DKIM verifier」と入力し検索

3. 図5.1-5において、 右端の緑背景「Thunderbirdに追加」をクリック

5.1.2 Web版Gmail

Web版Gmailでも、受信メール各々のSPFや、DKIMDMARCなどの認証結果を、
メッセージのソース」として図5.1-6に示すように表示してくれます。

図5.1-6の例では、 SPFDKIMDMARCとも、認証に成功しています。

メッセージのソース」は、
受信メールを開いた状態で差出人表示行右端 「 」アイコンをクリック、
表示されたメニューの中から「メッセージのソースを表示」を選択すると表示します。

5.2 Webのメールヘッダー解析サービス

DKIM認証結果だけを表示してくれるわけではありませんが、
面倒なメールヘッダー解析を手助けしてくれるツールを3つ紹介します。

Google Workspaceサービス / Google Admin Toolbox / Messageheader
MXTOOLBOX / Email Header Analyzer
Microsoft Message Header Analyzer

Googleのメールヘッダー解析ツールには、DKIMの認証結果表示があります。

Google以外の他のツールであっても、
DKIM-SignatureヘッダーAuthentication-Resultsヘッダーなどを切り分けてくれるので、
素のメールヘッダーを直接解析するよりは楽になります。

どのツールであっても、DKIMデータの見方の知識は必要です。

以下に、各ツールのメールヘッダー解析結果表示の例を示します。

以上

HTMLだと、
思うように編集することは難しく、やろうすればとっても時間が掛かります。
ですので、本記事の元となっているWordで作成したPDFを
ページ最後に貼り付けました。

役に立てていただければ、うれしく思います。

このPDFファイルは、自由に配布されてもかまいません。
ただし、再配布の際には、
入手元著者名は明らかにしてください

なお、上のPDFファイルの内容、また本文中の記述に、
誤字や脱字、誤った内容の記述など見つかりましたら、
下に示すフォームでご連絡いただければ幸いです。

お問い合わせ