MailData

DomainKeys Identified Mail

DKIM

公開鍵暗号方式を用いたメールの送信者の正当性と送信内容の完全性保証

DKIMディーキム（DomainKeys Identified Mail）は、公開鍵暗号方式を用いてメールの送信者の正当性とメール内容の完全性を検証する認証システムです。
ドメイン管理者は、DNSに公開鍵を登録し、送信側のMTA（Mail Transfer Agent）は秘密鍵を使ってメールに署名を行います。
これにより、受信側のMTAは送信者の正当性とメール内容が改竄されていないことを確認できます。
DKIMの仕様は、2011年に公開されたRFC6376に記載されています。

動作例

DKIM(DomainKeys Identified Mail)の動作について、下の図を使って説明します。
例として、example.comの正しいメールサーバはGmailだとします。
Gmailでは、デフォルトでDKIM鍵(d=*.gappssmtp.com)を使用して、全てのメールに署名します。

しかし、これでは、DMARC Alignment Checkで、ドメイン名が違うと判断されてしまうため、d=example.comでDKIM鍵を発行します。
その公開鍵をDNSにTXTレコードとしてgoogle._domainkeyという名前で登録します。
DNSに公開鍵を登録後、Google管理コンソールにログインして、認証を開始のボタンをクリックして有効化します。

具体的な手順は、こちらをご覧ください。
ドメインでDKIMを有効にする - Google Workspace 管理者ヘルプ

もし悪意のある人が、support@example.comのアドレスを使ってなりすましメールを送ろうとし、Gmailのアカウントを使用して送信を試みるとします。
SPFのところで説明したとおり、Gmailのアカウントさえ取得できれば、SPFは同じになるため、SPF認証を突破できるからです。

署名プロセス

電子メールが送信されるとき、送信サーバは一部のメッセージヘッダーとボディのハッシュを作成します。
これは一定のルールに従って選択され、ハッシュ関数（例えばSHA-256）を使用して計算されます。
その結果得られるハッシュ値は、メールの特定の部分の「要約」を表します。

その次に、このハッシュ値は送信ドメインの秘密鍵で署名されます。
これにより、秘密鍵による署名が作成され、それが電子メールメッセージのDKIM-Signatureヘッダーに追加されます。
この署名は、メッセージが送信中に改竄されなかったこと、または「偽造」されていないことを証明します。

検証プロセス

電子メールが受信されると、受信サーバはDKIM-Signatureヘッダーを調べます。
このヘッダーから、受信サーバはハッシュを作成した際の原文（メールヘッダーとボディの一部）と署名を抽出します。

受信サーバは次に、送信ドメインの公開鍵をDNSから検索します。
公開鍵は送信ドメインのDNSレコードに保存されています。
その公開鍵を使用して、署名を解読します。

これにより、元のハッシュ値が計算によって取り出せます。
同時に、受信サーバは受信した電子メールから同じ部分を取り出し、同じハッシュ関数を使用して新たなハッシュ値を計算します。
これらの2つのハッシュ値（解読されたものと新しく計算されたもの）が一致する場合、メッセージは改竄されていないと確認され、署名は有効とみなされます。

これにより、電子メールが送信ドメインから本当に送信されたことが確認できます。
また、メールシステムにGmailを使用していても、ドメインが異なれば異なる公開鍵・秘密鍵が発行されるため、他のドメインの公開鍵で上記の検証で合格することはありません。

DKIMとはの動作の例

受信側メールサーバが処理を決める

DKIMレコードが設定されていると、受信側のメールサーバは、メールが正当な送信者から送られたかどうかを判断できます。
正当でない送信者からのメールの処理方法は、受信側のメールサーバに委ねられています。
一般的に、多くのメールサーバは、正当でない送信者からのメールを迷惑メールフォルダに移動する設定になっています。

DKIMが必要な理由とS/MIMEとの違い

公開鍵方式による暗号化とデジタル署名で、メールの送信者と送信内容の完全性の正当性を確認する標準規格としては、S/MIMEが担ってきました。
SPF & DKIMとはとS/MIMEは何が違うのでしょうか?

S/MIMEの設定・運用は、組織の設定・運用に依らず使えますが、組織単位で見ると、全体への適用で大きな困難があります。
SPF & DKIMとはは、ユーザに意識させることなく、組織全体のメールについて適用が可能な点が大きく異なります。

SPF & DKIMとS/MIMEの違い
規格SPFDKIMS/MIME電子署名
なりすましドメイン検知✔
メール改竄検知❌✔
fromアドレス詐称検知❌✔
メール暗号化❌✔
メールシステム構成 MTAがSPFに対応している必要がある 送信側MTA、受信側MDAがDKIMに対応している必要がある 送信側MUA、受信側MUA、双方が対応している必要がある
DNSへの登録 SPFをTXTレコードとして登録が必要 公開鍵をTXTレコードとして登録が必要 不要
誰が設定・運用するのか 組織がシステム単位で設定・運用し、透過的に処理されるので、ユーザは意識する必要はない 個人単位で設定・運用し、組織が関与しなくてもいい

S/MIMEで可能なメール暗号化については、メール送信時はSMTPS、MTA間はMTA-STS、メール受信時はPOPSやIMAPSを使う事で、メール通信経路の暗号化を行います。

DKIMの構文

DKIM署名は、メールのヘッダにDKIM-Signatureというフィールドとして追加されます。
このフィールドには、いくつかのタグが含まれており、それぞれ異なる情報を持ちます。
以下に、主要なタグを示します。

v
DKIM署名のバージョン。通常、"1" と設定されます。
a
署名に使用されたアルゴリズム。一般的には、"rsa-sha256" が使用されます。
d
DKIM署名を行ったドメイン名。
s
セレクタ。署名に使用された公開鍵を特定するために使用されます。
c
ヘッダキャノニカライゼーションアルゴリズムと本文キャノニカライゼーションアルゴリズム。"relaxed/relaxed" や "simple/simple" などの組み合わせがあります。
q
公開鍵取得のクエリ方法。通常、"dns/txt" が使用されます。
h
署名対象のヘッダフィールドのリスト。
bh
メール本文のハッシュ値。
b
署名データ。秘密鍵で署名されたハッシュ値です。

以下は、DKIM署名が付加されたメールヘッダの一例です。 


DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector;
  h=From:Date:Subject:To:From;
  bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
  b=aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789AbCdEfGhIjKlMnOpQrStUvWxYz;

この例では、以下のような情報が含まれています。

v=1
DKIM署名のバージョンは1です。
a=rsa-sha256
署名に使用されたアルゴリズムはRSA-SHA256です。
c=relaxed/relaxed
ヘッダと本文のキャノニカライゼーションアルゴリズムは、両方ともrelaxedです。
d=example.com
DKIM署名を行ったドメイン名はexample.comです。
s=selector
セレクタは"selector"です。
h=From:Date:Subject:To:From
署名対象のヘッダフィールドは、From, Date, Subject, To, Fromです。
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=
メール本文のハッシュ値（Base64エンコード済み）です。
b=aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789AbCdEfGhIjKlMnOpQrStUvWxYz
署名データ（Base64エンコード済み）です。

受信側のメールサーバは、このDKIM-Signatureヘッダから情報を取得し、送信者のドメイン（d=）とセレクタ（s=）を使ってDNSから公開鍵を取得します。
その後、公開鍵を使って署名データ（b=）を検証し、正当性と改竄がないことを確認します。
検証が成功すれば、メールは正当な送信者からのものとして受信されます。

メールに複数のDKIM署名を付ける理由とその効果

DKIMは、1通のメールに複数の署名を付けることが可能です。
1つのメールに複数のDKIM署名が付けられる主な理由は以下のとおりです。

複数の組織の関与
最近は、Amazon SESやSendGrid、MailChimp、SalesForce、Zohoなど、様々なメール配信サービスやSaaSを使ってメールを送信している企業も多いです。
マーケティング企業や送信代行サービスなどの複数の組織を経由して配信される場合、各組織はそれぞれ独自のDKIM署名を付けることができます。
これにより、メールの信頼性が向上し、各組織がメールの配信に責任を持つことが明確になります。
複数の送信システム
同じドメインを使用して複数の送信システムがメールを送信する場合、それぞれのシステムが独自のDKIM署名を生成し、メールに追加することができます。
例えば、皆さんの企業では、メールサーバから直接送信するのではなく、中継MTAやSecure Mail Gatewayのサービスを利用されているところもあるでしょう。
DKIMの署名が複数の送信システムで、各々付与できることで、各送信システムの認証が維持されます。

複数のDKIM署名の効果

メールに複数のDKIM署名がある場合、受信者側のメールシステムは、それぞれの署名を個別に検証します。
少なくとも1つの署名が正しく検証されると、DKIM検証は成功とみなされます。
これにより、以下の効果が得られます。

認証の維持
異なる送信システムや組織が同じドメインを使用していても、メールの認証が維持されます。
柔軟性
メールが複数の組織や送信システムを経由する場合でも、それぞれの参加者が独自のDKIM署名を付けることで、認証プロセスに柔軟性をもたらします。
信頼性の向上
複数のDKIM署名が存在することで、メールの信頼性が向上し、受信者によるメールの開封率が高まります。
スパム対策の強化
複数のDKIM署名を使用することで、スパムやフィッシング攻撃から受信者をより効果的に保護することができます。

ただし、複数のDKIM署名を付ける際には、それぞれの署名が異なるセレクタ（署名に関連付けられた識別子）と鍵ペアを使用していることが重要です。これにより、各署名が正しく検証されることが保証されます。

まとめ

メールに複数のDKIM署名を付けることは、複数の組織や送信システムが関与するメール配信において、信頼性、柔軟性、スパム対策の強化に寄与します。
ただし、複数のDKIM署名を適切に管理し、異なるセレクタと鍵ペアを使用していることを確認することが重要です。
これにより、メールの認証が確実に機能し、受信者にとって安全で信頼性の高いメール配信が実現されます。

DKIMレコードはサブドメインに自動継承されない

DKIMレコードは、APEXにしか適用されず、サブドメインに自動的に設定が適用されることはありません。
つまり、各サブドメインごとに独自のDKIM設定が必要です。

例えば、example.comドメインにDKIM設定がある場合、example.comのみに適用され、subdomain.example.comには自動的に継承されません。
subdomain.example.comにもDKIM設定を行い、独自の公開鍵・秘密鍵ペアを生成し、DNSにサブドメイン用のTXTレコードを登録する必要があります。 


Type: TXT
Host: default._domainkey.subdomain
Value: v=DKIM1; p=

ただし、実際の運用上、同じメールサーバーを使用して複数のドメインやサブドメインに対してメールを送信する場合、同じセレクターと鍵ペアを再利用することも可能です。
ただし、この場合でも、各サブドメインに対応するDNS TXTレコードを登録する必要があります。

メールを送信しないドメインでのDKIM設定

企業は、キャンペーン用のサイトに使用するドメインや、なりすましのWebサイト防止のために取得した類似のドメイン名を持つことがあります。
また、国内向けに「.jp」、国際展開のために「.com」といった複数のドメインを取得している場合もあります。
メールを送信しないドメインの場合でも、DKIMを設定することでドメインの信頼性を保ち、なりすまし攻撃から保護することができます。

以下に、メール送信しないドメインでのDKIM設定方法を示します。

Defensive(防御用)DKIMレコードの設定

メール送信がないドメインでは、一般的なセレクタ（例: default）を使用するか、特定の目的を示すセレクタ（例: noemail）を選択できます。
メールを送信しないドメインの場合、空の公開鍵（公開鍵情報がない状態）を作成することができます。
これにより、DKIM署名を持つメールがないことを示すことができます。 


Type: TXT
Host: default._domainkey
Value: v=DKIM1; p=

この設定を行うことで、メール送信しないドメインがなりすまし攻撃の対象になった場合でも、受信側のメールサーバはDKIM検証に失敗し、不正なメールとして扱われることになります。
そのため、メール送信しないドメインであっても、DKIM設定を行うことがセキュリティ上有益です。

DKIMの限界

DKIMはメール認証システムとして広く利用されていますが、いくつかの制限事項が存在します。以下に、主要な制限事項を挙げます。

メールの暗号化に対応していない

DKIMはメールの送信者と内容の完全性を確認するために使用されますが、メールの暗号化には対応していません。
メールの暗号化を実現するには、S/MIMEやPGP（Pretty Good Privacy）のような別の技術を利用する必要があります。

転送やリストサーバによる変更に弱い

DKIM署名は、メールのヘッダーや本文が変更されるとハッシュ値が変わるため無効になります。
そのため、転送やリストサーバによってハッシュ計算対象のヘッダーやメール内容が変更される場合、DKIM検証に失敗します。

DNSの脆弱性

DKIMは公開鍵をDNSに登録することで機能しますが、DNS自体のセキュリティ脆弱性により、攻撃者が公開鍵を書き換えることでDKIM検証を回避する可能性があります。
DNSのセキュリティを強化するためには、DNSSEC（Domain Name System Security Extensions）のような技術を利用することが推奨されます。

SPFやDMARCとの併用が必要

DKIMだけでは、送信者のドメインに対するなりすましやIPアドレスの詐称を防ぐことができません。
これらの問題に対処するために、DKIMと併せてSPF（Sender Policy Framework）やDMARC（Domain-based Message Authentication, Reporting, and Conformance）の導入が推奨されます。

なりすましメール送信用ドメインでSPFとDKIMを設定している

昨今のなりすましメールは、なりすましメールを送信するためのドメイン(例えば～.xyzのような)を取得して、そのドメイン用にSPFやDKIMを設定し、Fromアドレスを書き換えて送信します。
すると、SPFやDKIMは合格するため、なりすましメールを排除することができません。

なりすましメールを送信するドメインでSPFとDKIMを設定してFromアドレスだけ書き換える例

SPFやDKIMの限界を超えるためのDMARC

以上のように、SPFやDKIMだけの設定では、メールセキュリティの限界があります。
そこでDMARCが登場します。