NHN Cloud NHN Cloud Meetup!

   

Emailのセキュリティ強化機能 DKIM、DMARC

2020.09.04

3,470

目次

はじめに

前回の「メールセキュリティ強化機能 – ドメイン保護」に続き、今回はメール認証方法であるDKIM（DomainKeys Identified Mail）、DMARC（Domain-based Message Authentication, Reporting and Conformance）について紹介します。

DKIM（DomainKeys Identified Mail）

TOAST Emailでメールドメインの登録が完了すると、DKIM機能を使用することができます。DKIMは電子メールの認証方法のひとつで、受信サーバーから受信したメールが偽造されていないかをデジタル署名を利用して検証する技術です。送信サーバーは、メール送信時に送信者、受信者、件名、内容などを秘密鍵で署名します。この署名値をDKIM-Signatureヘッダー（Header）に追加します。受信サーバーは、DKIM-Signatureヘッダ内のドメイン（d=）DNSに公開された公開鍵と署名アルゴリズム情報などが含まれたDKIMレコードを照会し、これらの値を利用して受信したメールのDKIM-Signatureヘッダのデジタル署名を検証します。

下図は、DKIMレコードの登録および検証フローです。

DKIMレコード構造

下記は、送信ドメインDNSに登録するDKIMレコードのサンプルです。DKIMレコードは、受信サーバーから受信したメールのDKIM-Signatureヘッダの検証に使用されます。DKIMレコードはSPFレコードとは異なり、送信ドメインのDNSに登録するのではなく、’${指定子}._domainkey.${ドメイン}’ ドメインのDNS TXTレコードに登録します。これに関しては「DKIM-Signature構造」で詳しく説明します。

以下は、DKIMレコードのサンプルです。

v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB

上記で使用された値を説明します。この他にも選択値がありますが、DKIMレコード構造の詳しい内容は、「参考」欄の「DKIM RFC」項目をご確認ください。

区分 必須区分 値 説明
v   DKIM1 DKIMレコードのバージョン
k   rsa DKIM認証時に使用するアルゴリズム
p o Base64文字列 デジタル署名の検証時に使用する公開鍵（Base64でエンコードされた値）
メール送信時、メールにDKIM署名をするところ（例:TOAST Email）で発行する。

DKIM-Signature構造

以下は、メール送信時にメールのヘッダーに追加されたDKIM署名（DKIM-Signatureヘッダ）のサンプルです。

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=toast;
     t=1117574938; x=1118006938;
     h=from:to:subject:date;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

DKIM-Signatureに使用される値について説明します。DKIM-Signature構造の詳しい内容は、「参考」欄の「DKIM RFC」項目をご確認ください。

区分 必須区分 値 説明
v o 1 バージョン
a o sha-256 DKIM署名に使用されるアルゴリズム
s o – 指定子（Selector）
送信ドメインは複数のDKIMを使用できる。したがって、DKIM-Signatureヘッダでは、この署名がどのような公開鍵を用いて認証すべきか受信サーバーに通知する必要がある。たとえば、指定子「toast」であれば、受信サーバーは「toast._domainkey.example.com」のDNSでDKIMレコードを確認する。
h o – 署名ヘッダ（Header）
ヘッダはコロン（:）で区切る
b o – 署名ヘッダ（h）に定義されたヘッダを署名した値
Base64でエンコードされる
bh o – メールの本文に署名した値
l   – 本文署名（b）に使用される本文の長さ
特に定義されていなければ本文全体を使用する
d o – ドメイン
指定子（s）と一緒にDKIM署名を検証するため、DNSにDKIMレコードを照会するときに使用される。MAIL FROM（5321.From）とFrom（5322.From）とは異なる場合がある。ただし、異なる場合は疑わしいメールに分類されることがある。
t   – DKIM署名の作成日時
形式は、UNIX時間（Unix Time）、1970年1月1日0時0分0秒（UTC協定世界時間）からの経過時間を秒単位で換算した値
例: 2020年6月8日午後3時47分17秒のUNIX時間：1591631237秒
x   – DKIM署名の有効期限日時
形式は、署名作成日時（t）と同じ

たとえば、ある顧客がメール送信サービスの高可用性（High Availability）のため、TOAST EmailとGoogleを使用した場合、顧客が使用する送信ドメインにはTOAST EmailとGoogleで発行された2つのDKIMレコードを登録する必要があります。

顧客が使用する指定子とドメインは、以下のとおりです。

指定子: toast, google
ドメイン: example.com

下記は、TOAST EmailのDKIMレコードです。

nslookup -q=TXT toast._domainkey.example.com

v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB

照会したドメインにおいて、「toast」が指定子（s）、「_domainkey」が固定された文字列、「example .com」がドメイン（d）です。

次は、GoogleのDKIMレコードです。

nslookup -q=TXT google._domainkey.example.com

v=DKIM1;k=rsa;p=1IafMAFEOF93azFjQDQEBAQUAA4GNADCBiQKBgQDDmFOEJFEvjoF3FP3aafg4suA2SyMwR5MGHpP9diNT1hRiwUd/AFAEFLjeofp2390fjaljfnveAEFLE/EW72O1839ThkyCgpSYS8nmEQIDAaMd

TOAST Emailで送信したメールのDKIM-Signatureの指定子は「toast」に設定され、受信サーバーは「toast._domainkey.example.com」のDKIMレコードを照会してDKIM認証を行います。Googleから送信したメールのDKIM-Signatureの指定は「google」に設定され、受信サーバーは「google._domainkey.example.com」のDKIMレコードを照会してDKIM認証を行います。

DKIMレコードの登録

TOAST EmailでDKIMレコードを受信し、送信ドメインDNSに登録する方法を説明します。

1）メールドメイン管理タブに移動します。
2）登録された送信ドメインでDKIM認証ボタンをクリックします。
3）表示されたDKIMレコードをコピーして送信指定されたドメインDNSに登録します。
4）DKIMレコードが登録されたら、認証ボタンをクリックして認証します。

5）認証が成功したら、ポップアップ内のDKIM機能に移動し、有効化ボタンをクリックしてDKIMを有効にします。

DKIM認証テスト

DKIM機能を有効化したら、メールを送信してDKIMが正常に認証されるかを確認します。
TOAST EmailコンソールからGmailにメールを送信したときを例に挙げて説明します。

1）コンソールから、自分が所有するGmailにメールを送信します。
2）Gmailに移動して、受信メールを確認します。
3）メールの右上プレビューからメッセージのソースを表示をクリックします。

4）表示されたページから、DKIM認証の結果を確認できます。

DMARC（Domain-based Message Authentication, Reporting and Conformance）

メールセキュリティ強化の最終ステップであるDMARCは、メールのなりすましを利用したフィッシングや詐欺などを防ぐためのメール認証方法です。受信サーバーは、送信者アドレス（From）ドメインのDNSでDMARCレコードを照会します。DMARCレコードに定義されたポリシーに基づいて、受信サーバーは受信したメールを認証します。DMARCポリシーは、SPFとDKIMの使用有無と、それぞれの認証方法が失敗した際のメールの処理方法によって構成されています。必須機能ではありませんが、ほとんどのメールサービスはDMARCを使用しており、メールの安全な送受信のため、使用を推奨します。SPFとDKIMを使用していなくても、DMARCポリシーを設定して受信が失敗しているメールをモニタリングすることができます。また、メールのなりすましやフィッシングなどに、自分が所有しているメールドメインが使用されないように保護することができます。

以下は、TOAST Emailを通じてGmailにメールを送信した際のDMARC認証のフローを表したシーケンス図です。

DMARC DNSレコード構造

DMARC DNSレコードは、「_dmarc.sender.com」のようにDMARCを適用する送信ドメインに「_dmarc」を付けたサブドメインのDNSにレコードを登録します。

以下は、ウィキペディアに記載されたDMARC DNSレコードのサンプルです。

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"

DMARCレコードに使用される値について説明します。詳しい内容は「参考」欄の「DMARC RFC」項目をご確認ください。

区分 必須区分 値 説明
v o DMARC1（固定） バージョン
p o none, quarantine, reject 失敗時の処理ポリシー
sp   none, quarantine, reject サブドメインの失敗処理ポリシー
pct   0〜100（デフォルトは100） ポリシーを適用するメールの割合
例：50の場合、受信したメールのうち半分がDMARCポリシーによって認証される
adkim   s, r（デフォルト） DKIMアライメント（Alignment）
DKIM-Signatureのドメイン（d）とFrom（5322.From）の一致レベルを設定
aspf   s, r（デフォルト） SPFアライメント
SPF認証時のMAIL FROM（5321.From）とFrom（5322.From）の一致レベルを設定
rua     定期的に集計する失敗レポートを受信するアドレス
例：mailto:demarc-report@toast.com
ruf     失敗レポートの受信アドレス
例：mailto:demarc-report@toast.com
fo   0（デフォルト）, 1, d, s 失敗レポート（ruf）の作成基準
rf   afrf（固定） 失敗レポート（ruf）の形式設定
ri   86400（単位秒、デフォルト） 失敗集計期間
設定された周期で失敗レポート（rua）が送信される

「adkim」と「aspf」の説明から分かるように、DMARCポリシーを適用すると、MAIL FROM（5321.From）、DKIM-Signatureのドメイン（d）は、送信アドレスFrom（5322.From）を比較してメールのなりすましを防ぐことができます。しかし、あまりにも厳密に設定すると、正常なメールも失敗として処理されることがあるため注意が必要です。

失敗ポリシー（p）の詳しい内容は、次のとおりです。

失敗ポリシー 説明
none 受信サーバーで失敗について一切処理しないようにする。SPF、DKIMを使用していない状況で設定可能。
quarantine 受信サーバーは失敗したメールをスパムとして処理するようにする。
reject 受信サーバーでDMARCに失敗したメールを返送する。一般的に、送信サーバーと受信サーバーは、SMTP通信時にDSN（Delivery Status Notification）応答が行われることを推奨するポリシーである。

DMARCで注意すべき点は、受信サーバーがDMARCポリシーに合わせて処理することを完全に保証していないということです。DMARCは送信サーバーが受信サーバーにポリシーを提供するレベルであると理解しましょう。たとえば、失敗ポリシーを「none」に設定しても、受信サーバーは認証が失敗したメールを迷惑メールとして処理することがあります。

次に、SPFとDKIMアライメント（aspf、adkim）値を説明します。

ポリシー 説明
s 厳格性（Strict）/ ドメイン部分が完全に一致する必要がある
r 柔軟性（Relexed）/ サブドメインも可能
例：「d=example.com」のときに「From:news.example.com」も通過する

失敗レポートの種類を説明します。

失敗レポート 説明
rua 定期的に集計された失敗メールのレポートを受信するアドレス
ruf 失敗のより詳しいレポートを受信するアドレス
「fo」の設定によってレポートの形式が決定される

失敗レポートの作成基準（fo）の説明です。失敗レポート（ruf）を設定すると使用されます。

基準 説明
0 SPF、DKIMの両方が失敗したときに報告する
1 SPF、DKIMのいずれかが失敗したときに報告する
d DKIM認証失敗時に報告する
s SPF認証失敗時に報告する

DMARCレコードの登録

DMARCレコードは、「_dmarc.example.com」のように、DMARCを適用する送信ドメインに「_dmarc」を付けたドメインDNSにTXTレコードとして登録します。TOAST Emailコンソールで行う追加作業はなく、適切なDMARCポリシーを策定して登録します。

たとえば、登録する内容は次のとおりです。DMARC失敗時にレポートを受信するアドレスを設定する必要があります。

"v=DMARC1; p=none; fo=1; rua=mailto:${レポートを受信するアドレス}"

登録が完了したら「nslookup」、「dig」コマンドを使って、DMARC DNSレコードがDNSに反映されているか確認できます。

DMARCレコード例

1. SPF、DKIMを使用していないところ、またはDMARCを初めて使用するところ

"v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@example.com"

ポリシーを「none」、ポリシー適用率（pct）を「100」に設定すると、最も弱いポリシーで失敗レポートを受信することができます。

2. SPF、DKIM適用後、DMARCポリシーを徐々に強化する

"v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com"

ポリシーを「quarantine」、最初のポリシー適用率（pct）を「10」や十分に低い値に設定します。受信した失敗レポートを分析して失敗率を下げ、ポリシー適用率を増やしていくことを推奨します。

DKIM認証の限界とDMARC

DKIM認証時にDKIM-Signatureのドメイン（d=）を使用するため、依然としてFrom（5322.From、ヘッダーFrom）を偽造したメールのなりすまし攻撃を防ぐことはできません。DKIMはメールの内容の偽造有無を認証するだけで、DKIM-Signatureドメイン（d=）とMAIL FROM（5321.From、エンベロープFrom）、From（5322.From）の関係を検証していないためです。

以下は、攻撃者（spoofing.com）が直接送信したメールのサンプルです。From（5322.From）を受信者が信頼するアドレスに設定し、SPFで使用されるMAIL FROM（5321.From）とDKIMで使用するDKIM-Signatureドメイン（d=）は、攻撃者のドメインに設定されていますが、SPFレコードとDKIMレコードが正常であれば認証が通過します。

C: telnet www.example.com 25
S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.com
S: 250 smtp.example.com, I am glad to meet you
C: MAIL FROM:<bob@spoofing.com>    <-- SPFレコードが登録されているFromと異なる攻撃者ドメインを使用
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: DKIM-Signature: v=1; a=rsa-sha256; d=spoofing.com; s=brisbane; <-- 攻撃者ドメインと指定子
      c=simple; q=dns/txt; i=@eng.example.net;
      t=1117574938; x=1118006938;
      h=from:to:subject:date;
      bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
      b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
C: From: "Bob Example" <bob@trust.com>  <-- 受信者はMAIL FROMではなく、Fromを見るため騙されることがある
C: To: Alice Example <alice@example.com>
...

DMARCは、このような攻撃を防ぐためにSPF、DKIMアライメント（Alignment）と呼ばれる機能を使用します。上記のDMARCレコード構造の説明で述べたようにDKIM-Signatureドメイン（d=）とMAIL FROM（5321.From）、From（5322.From）の関係を検証するため、サンプルではSPF、DKIMアライメント認証が失敗します。このような失敗に対してDMARCポリシーを「quarantine」や「reject」に設定すると、攻撃者が送信したメールを受信しないように防ぐことができます。

DMARC適用時の注意事項

一部の送信SMTPサーバーのIPアドレスがSPFレコードに含まれていない、または送信するメールにDKIMが正しく適用されていない状態で、DMARCを初めから「p=quarantine」や「p=reject」で適用した場合、通常のメールが受信されないことがあります。したがって、最初にDMARCを適用する際は「p=none」に設定し、DMARC失敗レポートを分析して誤った部分を修正しましょう。修正後、誤りがないことを十分に検証してから、「DMARCレコード例」のようにDMARCポリシーのレベルを段階的に高めることをお勧めします。

まとめ

前回の記事では、Emailのセキュリティ強化機能を理解するための事前知識とSPF（Sender Policy Framework）、ドメイン保護について紹介しました。今回は、送信メールのDKIM（DKIM-Signature）、DMARC（Domain-based Message Authentication, Reporting and Conformance）について紹介しました。現在、韓国の送信ドメインを見ると、SPFとDKIMを適用しているところはたくさんありますが、DMARCを適用しているところは少ないことがわかりました。自分が所有しているメールドメインがスプーフィング攻撃に使用されることを完全に防止し、受信者により信頼されるようにするためには、DMARCの適用と継続的な失敗レポートの分析、ポリシー管理が必要となります。

参考

– ウィキペディア：DKIM
https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
– DKIM RFC
https://tools.ietf.org/html/rfc4871
https://tools.ietf.org/html/rfc6376
– Gmail：発信者名の追加情報
https://support.google.com/mail/answer/1311182
– ウィキペディア：DMARC
https://en.wikipedia.org/wiki/DMARC
– DMARC RFC
https://tools.ietf.org/html/rfc7489
– Valimail、Shortcomings of DKIM
https://www.valimail.com/blog/dkim/

NHN Cloud Meetup 編集部

NHN Cloudの技術ナレッジやお得なイベント情報を発信していきます
pagetop