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という名前で登録します。

_domainkey
DKIMのレコードであることを示す固定プレフィックスです。
DKIMの公開鍵を格納するDNSレコードを検索する際に、このプレフィックスが使用されます。
google
これは「セレクタ」と呼ばれます。
セレクタは、同じドメインで複数のDKIMキーを使用する場合に、それらのキーを区別するためのものです。
メールを送信する際に、どのセレクタを使用して署名されたのかを示す情報がメールヘッダに含まれます。
受信側はこのセレクタ情報を基に、適切な公開鍵をDNSから取得して、メールの署名を検証します。
セレクタは、サービス毎にユニークな値である必要があります。
Google Workspaceなら、googleという値が使われます。
Microsoft365なら、selector1/selector2という値が使われます。
SendGridなら、s1/s2という値が使われます。

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署名を追加することが可能です。
これにより、メールが各システムやサービスを経由して送信されたことを確認することができます。
例えば、SMG(Secure Mail Gateway)を使っていたり、PPAP対策で添付ファイルを自動でリンクに変換するサービスを使っていたり、誤送信防止のために一定時間キューイングしてから送信するサービスを使っていると、一番最初にユーザが利用したMTAで署名したメールの状態から日時や内容が変更になるため、DKIM署名の検証で失敗します。
そこで、それらのサービスでも、できれば送信ドメイン名義で発行された秘密鍵を使ってDKIMの署名を行うことで、検証に合格できるようになります。

複数のDKIM署名を持つメールには以下の注意点があります。

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

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

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

DKIMのキーローテーション

DKIMのキーローテーションとは、定期的にDKIMの秘密鍵と公開鍵のペアを変更するプロセスのことを指します。
このプロセスは、セキュリティのベストプラクティスとして推奨されています。 キーローテーションは以下の理由で重要です。

セキュリティの向上
もし秘密鍵が何らかの理由で漏洩した場合、ローテーションを行うことで、その鍵での署名の有効期間を短縮することができます。
これにより、攻撃者がその鍵を使用した悪意のある活動を行う機会が減少します。
鍵の強度の維持
暗号技術は進化し続けており、古い鍵が新しい攻撃手法に対して脆弱である可能性があります。
定期的なローテーションにより、最新の暗号技術を使用した鍵を継続的に利用することができます。
運用上の問題の対処
鍵の管理や運用上の問題が発生した場合、新しい鍵ペアへの切り替えをスムーズに行うことができます。

DKIMのキーローテーションを行うには、新しい秘密鍵と公開鍵のペアを生成し、新しい公開鍵をDNSに登録します。
同時に、メールサーバは新しい秘密鍵を使用してメールに署名を開始します。
古い鍵は一定期間はDNSに残しておくことで、過去のメールの署名検証をサポートすることができます。
しかし、適切な期間が経過した後、古い鍵はDNSから削除することが推奨されます。

Google Workspaceは、一定の期間毎に手動でDKIMの鍵を生成しなおして登録する必要があります。
Microsoft365は、CNAMEを使って、DKIMの固定プリフィックスをonmicrosoft.comに向ける手法を採用しており、selector1とselector2を使って新旧のキーローテーションを自動で行います。

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=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCQxcLY5Rg+AQq87XtdJA/n1GEU6ZFM4viEMgC18fjodbT3FrWRgqso17yBhDtT1AkkfaWmiDSBezmUNs1d3EEjWiowGB4yfNz/LwxzK04NgUmRd3Vj9ymCGq/5R4KyBscQ/y0B9GJbr38dTMA+xVP4fWHz0RwBiTa8cdN8fOIX6wIDAQAB

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

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が登場します。