DMARCとは

日々メールを受信している私たちは、「誰が」送信したメールなのかを知るほぼ唯一の手段として、メールの「差出人アドレス（From)」を見ています。しかし、電子メールは仕組み上、From を自由に設定することができます。この仕組みと人の習慣を悪用し、From を企業やブランドのドメインになりすまして人々を信用させて、フィッシング行為が行われるケースがあります。このようなケースでは、直接の被害者はもちろん、なりすまされた企業やブランドにも大きな被害が発生することが考えられます。

電子メールを取り扱う企業や組織の間では、こうしたなりすましの問題に対して、送信ドメイン認証の導入を進めてきました。送信ドメイン認証とは、DNSを利用して、ドメイン所有者が許可した者が送信したメールであるかを検証する技術です。現在、SPF(Sender Policy Framework) と DKIM(DomainKeys Identified Mail) の２つが運用されています。

送信ドメイン認証により、なりすましを判断することが技術的には可能になりました。しかし、正当なドメイン所有者が送信したメールであっても、設定ミスなどで認証に失敗するケースも考えられるため、なりすましと判断したメールをどのように取り扱うかについて、メール送信者とメール受信者の間で取り決める仕組みが必要でした。

DMARC（Domain-based Message Authentication, Reporting & Conformance)は、なりすましと判断したメールをどのように取り扱うべきかをメール送信者が宣言し、メール受信者がそれを実行する仕組みを提供します。また、送信ドメイン認証の結果やなりすましメールの発生をメール受信者がメール送信者に対してレポートする仕組みを提供します。

誰が DMARC に対応しているのか？

DMARCは、 RFC7489 で仕様が公開されていますが、実装は世界中に存在するメールサーバーを保有する企業や組織が行わなければなりません。前述した通り、メール送信者とメール受信者に役割があるため、それぞれが実装を進める必要があります。

メール送信者
From を自らのドメインで運用している企業または組織。オンプレミスのメールサーバーだけではなく、メール配信サービスを利用している場合もメール送信者となります。

メール受信者
メールボックスを運用している企業または組織。近年では、Google (Gmail / G Suite) や Microsoft (Outlook.com / Office365) など、個人向け / 企業向けに関わらず少数のプロバイダが膨大な数のメールボックスを提供・運用する状況になりつつあります。

電子メールの技術実装では「鶏が先か、卵が先か」問題がたびたび起こります。メール送信者とメール受信者のどちらかで実装が進まないと、仕様としては存在するが実際は動作しないという状況に陥ります。 DMARC はメール受信者の実装が大変ではないかと思います。しかし幸いなことに、2017年12月時点で、メールボックスの大きなシェアを持つ Google と Microsoft が DMARC に対応しており、国内では IIJ が対応して普及を進めています。

こうした状況から、メール送信者が DMARC に対応することで、なりすましメールへの対策に一定の効果があるのではないかと思います。

DMARCを導入する

さてここからは、メール送信者のお話です。メール送信者は、送信ドメイン認証を導入し、 DMARC に関する情報（DMARCレコードと呼びます）を DNS に公開することで DMARC の運用を開始することができます。

2つのFrom

DMARC は From のなりすましを防ぐ仕組みですが、実は電子メールには２つのFromが存在します。送信ドメイン認証やDMARCを正しく理解するために、まずはこの2つのFromについて説明します。

電子メールは、SMTP という通信プロトコル使って送受信されます。 SMTPではいくつかのコマンドを使用しますが、そのうちの１つ「MAIL FROM」コマンドを使って送信サーバーは受信サーバーに「差出人アドレス」を送信します。このアドレスはメールの配送エラーを伝える「バウンスメール」と呼ばれるメールを受信します。これが１つめのFromです。

続いて、「DATA」コマンドを使ってメールデータを送信します。メールデータは、ヘッダとボディ（本文）で構成されます。ヘッダの中には皆さんが目にする「差出人アドレス」が含まれます。これが２つめのFromです。

電子メールを郵便物に例えて、１つめのFromは封書に書いてある差出人ですので Envelope-From, ２つめのFromは封書の中にある手紙のヘッダに書いてある差出人ですので Header-From と呼ばれています。

この2つのFromを認証するために、SPF と DKIM という２つの送信ドメイン認証を使用します。では、DMARCでの送信ドメイン認証の使い方を詳しく見ていきましょう。

SPFを設定する

SPFは Envelope-From のドメインを認証します(*1)。メール送信者は、メール送信に使用する IPアドレスを Envelope-From のドメインを管理するDNSに公開します。これをSPFレコードと呼びます。メール受信者は、メールの送信元IPアドレスとSPFレコードを使用してドメインを認証します。

Envelope-From はメールサーバー間で渡される差出人アドレスなので、メールの利用者が意識して設定するものではありません。あなたが、Outlook などのメーラーを使い、一般的なメールサーバーを使ってメールを送信している場合は、通常、 Envelope-From と Header-From は同じメールアドレスになります。

一方でメール配信サービスを利用している場合、Envelope-From はサービス事業者のドメインであることが多いのではないかと思います。なぜならサービス事業者は利用者の代わりにメールの配送を行っており、その状況を把握するためにバウンスメールを受信する必要があるからです。もちろん、サービス事業者のドメインが SPF に対応していれば、メールの到達性などへの影響はありません。

しかし、DMARCの仕様では、Envelope-From は Header-From と同じドメイン、もしくは、Header-From のサブドメインで運用して SPF による送信ドメイン認証を行うことを要求しています。私どもが提供するメール配信サービス「Customers Mail Cloud 」では、Envelope-From に Header-From のサブドメインを設定して運用できるようになっており、 DMARC が要求する SPF に対応することができます。

Customers Mail Cloud で SPF を設定する方法については以下ページを参照ください。

SPF | Customers Mail Cloud

SPFの詳細については以下ページを参照ください。

SPF（Sender Policy Framework） : 迷惑メール対策委員会

SPFレコードの設定例を見てみましょう。Customers Mail Cloud のサービスドメインである smtps.jp では以下のように設定をしています。

$ dig txt smtps.jp
;; ANSWER SECTION:
smtps.jp.               60      IN      TXT     "v=spf1 include:spf.hdecmc.smtps.jp include:spf.m21.mailds.jp ~all"

$ dig txt spf.hdecmc.smtps.jp
;; ANSWER SECTION:
spf.hdecmc.smtps.jp.    60      IN      TXT     "v=spf1 ip4:153.149.33.121 ip4:153.128.29.75 ~all"

*1) 携帯キャリアの SPF について
docomo などの携帯キャリアは、SPF を使って Header-From を認証します。 docomo が迷惑メール対策を発表した 2005年当時は、広く利用できる送信ドメイン認証が SPF しかありませんでしたが、メール利用者が目にする Header-From に対してなりすましを防ぎたかったのではないかと考えます。このため、携帯キャリア宛にメール送信する場合は、Header-From のドメインに対しても SPF の設定が必要になります。

DKIMを設定する

DKIMは Header-From のドメインを認証します。メール送信者は、秘密鍵で生成した電子署名をメールに付与し、これを検証するための公開鍵を Header-From のドメインを管理するDNSに公開します。これをDKIMレコードと呼びます。メール受信者は、電子署名とDKIMレコードを使用してドメインを認証します。

DKIM では、DKIM-Signature ヘッダに電子署名を付与します。この電子署名の dタグという部分に送信ドメインを記述します。 dタグに記述する送信ドメインは、必ずしも Header-From のドメインと同じではありません。 dタグの送信ドメインが Header-From と異なるドメインで作成された署名を「第三者署名」、 dタグの送信ドメインが Header-From と同じドメインで作成された署名を「作成者署名」と呼びます。

DMARCの仕様では、「作成者署名」を使用した DKIM で送信ドメイン認証を行うことを要求しています。例えば、DKIMに対応している場合でもメール配信サービスのドメインで署名されている場合は第三者署名になります。この場合、サービス事業者に「作成者署名」での DKIM が運用できるかを確認する必要があります。

Customers Mail Cloud は「作成者署名」に対応しています。実際に、どのようなメールヘッダが付与されるのか、例を見てみましょう。

From: Customers Mail Cloud <no-reply@smtps.jp>
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
   d=smtps.jp; s=cmc001; t=1506306208;
   h=Date:From:To:Message-ID:Subject:MIME-Version
   :Content-Type:Content-Transfer-Encoding;
   bh=7j8AIYN2YB5flcwzRdEEAmnvPXLCMOm2NGmMyIhFs8k=;
   b=aj3vRRcWgebBo3r5qlzF6DsAAaPakFmYd7jG7NP+2pImHLrk8dygTwdm2ddPfCZz
   SaDbuE6RcMmDSUN/Lab2b/b5kKTo81qob+7sJbBCyXnyjhBrDrgQa/V24Tg7Z579

Header-From に @smtps.jp を使用しており、DKIM-Signature に d=smtps.jp の記述があります。 Header-From と DKIM の送信ドメイン(dタグ）が一致しているので「作成者署名」であることがわかります。

SPFは、DNSにSPFレコードを公開するだけで対応することできますが、 DKIMに対応するには、電子署名を付与することができるメールサーバーが必要です。オンプレミスのメールサーバーをアップデートすることができない場合、 Customers Mail Cloud にメールをリレーすることで DKIM に対応することができます。

Customers Mail Cloud で DKIM を設定する方法については以下ページを参照ください。

DKIM | Customers Mail Cloud

DKIMの詳細については以下ページを参照ください。

DKIM (Domainkeys Identified Mail) : 迷惑メール対策委員会

バウンスメールを受信する

メールには Envelope-From, Header-From の２つのFromがあり、それぞれのドメインをSPF, DKIM で認証することはおわかりいただけましたでしょうか？メール配信サービスを利用して DMARC に対応する場合、Envelope-From のドメイン設計には少し注意が必要です。

例えば、以下のケースを考えてみましょう。

1) 株式会社HDEは、@hde.co.jp でメールを運用しています。

2) @hde.co.jp を Header-From としてニュースレターを配信します。

3) ニュースレターの配信にはメール配信サービスを利用します。

このようなケースにおいて DMARC に対応するには、Envelope-From をどのように運用すべきでしょうか？ Envelope-From に @hde.co.jp を設定した場合、メール配信サービスが送信したメールに対する配送エラー（バウンスメール）が、会社のメールサーバーに戻ってきてしまいます。これではメール配信サービスが配送エラーを正しく管理することができません。

では、@hde.co.jp の MXレコードにメール配信サービスが提供する SMTPホスト名を登録して、バウンスメールをルーティングすれば、、、ちょっとまってください。これは絶対にやってはいけません。確かにバウンスメールはメール配信サービスに戻りますが、社員のアカウントで受信しているメールも全て、メール配信サービスに届くことになってしまいます。

メール配信サービスを利用する場合、企業のドメインで取り扱う通常のメールと、バウンスメールのルーティングを分離することが重要です。

DMARCでは、Header-From のサブドメインを Envelope-From として運用することは許可しています。ですから、上記ケースの場合、@cmc.hde.co.jp というサブドメインを Envelope-From として、サブドメインの MXレコードにメール配信サービスの SMTPホスト名を登録します。こうすることで、@hde.co.jp のメール運用に影響を与えることなく、バウンスメールだけをメール配信サービスにルーティングすることができ、かつ、DMARC にも対応することができます。

Customers Mail Cloud でバウンスメールを受信する設定については以下ページを参照ください。

受信サーバ | Customers Mail Cloud

送信ドメイン認証の結果を確認する

ここまでの作業で送信ドメイン認証を設定し、バウンスメールをメール配信サービスに返すことができました。次に、あなたが設定した送信ドメイン認証がメール受信者に正しく認証されているかを確認します。おすすめは、Gmail にテストメールを送信して、Authentication-Results ヘッダを参照する方法です。

Gmail でメールヘッダを確認するには、以下の操作を行います。

1) Gmail でメールヘッダを確認したいメールを開きます。

2) 画面右上に「返信」ボタンの右にある「▼」をクリックしてメニューを開きます（図を参照）

3) 「メッセージのソースを表示」メニューをクリックします。

4) 別ウインドウでメッセージのソースコードが表示されます。

f:id:gorotan35:20171221104954p:plain

メッセージのソースコードから、Authentication-Results ヘッダを探してください。 Authentication-Results から以下の4か所を確認します。

Authentication-Results: mx.google.com;
       dkim=pass header.i=@smtps.jp header.s=cmc001 header.b=aj3vRRcW;
       spf=pass (google.com: domain of no-reply@smtps.jp designates 153.149.33.121
       as permitted sender) smtp.mailfrom=no-reply@smtps.jp;

dkim=pass
DKIMの認証結果。これが pass 以外である場合、DKIM の設定に問題があります。

header.i=@smtps.jp
DKIMの署名を付与した送信ドメイン（DKIMの dタグと同じ）。DMARC を運用する場合、このドメインが Header-From と同じ (*2)である必要があります。

spf=pass
SPFの認証結果。これが pass 以外である場合、SPF の設定に問題があります。

smtp.mailfrom=no-reply@smtps.jp
SPFの認証に使用した Envelope-From。DMARCを運用する場合、このドメインは Header-From のサブドメインである必要があります。

*2) adkim という DMARC のパラメータを使い、サブドメインの範囲で調整することはできます。

DMARC レコードを公開する

送信ドメイン認証が正常に動作していることが確認できたので、いよいよ DMARC レコードを公開します。 DMARC レコードは、"_dmarc" + "Header-Fromのドメイン" をレコード名とした TXT レコードです。

Customers Mail Cloud の例を見てみましょう。

$ dig txt _dmarc.smtps.jp
;; ANSWER SECTION:
_dmarc.smtps.jp.        60      IN      TXT     "v=DMARC1\; p=none\; pct=100\; adkim=r\; aspf=r\; rua=mailto:dm0j4gytnon3r.rua@dmarc.smtps.jp"

レコード値は、「タグ=値」という形式で記述します。

v=DMARC1
必須。DMARCのバージョンをあらわします。このタグは DMARCレコードの最初に記述しなければなりません。

p=none
必須。なりすましと判断したメールの取り扱い（ポリシー）を宣言します。 DMARCでは、SPF, DKIM の両方の認証に失敗した場合、「なりすまし」と判断します。ポリシーには、none（何もしない）, quarantine （隔離する）, reject （拒否する）のいずれを指定します。ポリシーに対する具体的な動作はメール受信者の実装にゆだねられますが、quarantine を宣言した場合は迷惑メールフォルダに分類する、 reject を宣言した場合はメールの受信を拒否する、といった動作が一般的ではないかと思います。

DMARC導入の最初のステップでは、p=none を宣言して、レポートを受信・分析することを強く推奨します。先ほど、Gmail でのテストメールでは認証成功となりましたが、実運用では、実装が異なる複数のISPと送信ドメイン認証を行うため、ここで技術的な問題があるかも知れませんし、あなたが思っている以上に様々なサーバーやサービスがあなたのドメインを使用しています。送信ドメイン認証に対応していないサーバーが無いかを確認するためにも、レポートを受信して確認することをお勧めします。

pct=100
オプション（デフォルト値は 100)。DMARCのポリシーを適用する割合をパーセンテージで指定します。ポリシーを quarantine や、reject に移行していく際に、少しずつ検証をしながら移行することができます。

adkim=r
オプション（デフォルト値は r )。DKIM認証の調整パラメータで、r (relaxed) または s (strict) が指定できます。 s を指定した場合、DKIM の送信ドメイン (dタグ）と Header-From は同じドメインでなければなりません。 r を指定した場合、DKIM の送信ドメイン (dタグ）のサブドメインを Header-From に使用することができます。例えば、d=@example.com, Header-From=@a.example.com である場合、s を指定すると認証失敗となりますが、r を指定すると認証成功となります。

aspf=r
オプション（デフォルト値は r )。SPF認証の調整パラメータで、r (relaxed) または s (strict) が指定できます。 s を指定した場合、Envelope-From と Header-From は同じドメインでなければなりません。 r を指定した場合、Header-Fromのサブドメインを Envelope-From に使用することができます。前述の通り、メール配信サービスを利用する場合、r として Envelope-From にはサブドメインを使用します。

rua=mailto：dm0j4gytnon3r.rua@dmarc.smtps.jp
オプション。DMARC の集計レポートの送信先を URI 形式で指定します。 rua はカンマ区切りで複数の送信先を指定することができます。 DMARCでは、「集計レポート」と「失敗レポート」の２種類のレポートが定義されています。

「集計レポート」
メールの送信元IP, Header-From, Envelope-From, 送信ドメイン認証の結果など、主になりすましの判定に使用した情報がレポートされます。 Return-Path 社のブログに詳しい説明がありますので、詳細についてはこちらを参照ください。

How to Read Your First DMARC Reports (Part 1)

「失敗レポート」
なりすましと判定した場合、そのメールの詳細な情報がリアルタイムにレポートされます。バウンスメールのように送られてくるレポートですので、送信ドメイン認証を導入していないサーバーがあるなど、送信したメールすべてが送信ドメイン認証に失敗するケースでは、大量のレポートを受信してしまいます。このため、まずは集計レポートを受信して、運用しているドメインでどの程度認証失敗が発生しているのかを把握してから、失敗レポートを受信するといったステップを経てください。

How to Read Your First DMARC Reports (Part 2)

失敗レポートを受信するには、以下のタグを使用します。

ruf=
オプション。rua ど同様、レポートの送信先を URI 形式で指定します。

rf=
オプション（デフォルト値は afrf)。失敗レポートのフォーマットを指定します。 afrf (RFC5965 に定義されているフォーマット) または iodef (RFC5070 に定義されているフォーマット）のいずれかを指定することができます。

その他にもいくつか DMARC を制御するタグはいくつかありますが、こちらの記事に情報が良くまとまっていると思いますので紹介します。

HOWTO - Define a DMARC Record

DMARCレポートを受信する

さて、DMARCレコードも公開し、主なメール受信者である ISP からのレポートを待つだけですが、、、あと１つ、やらなければならないことがあります。 DMARCでは、rua （レポートの送信先）にメールアドレスを指定することが一般的です。しかし、ISPは、ruaに記述したメールアドレスに無条件にレポートを送信してくれるというわけではありません。

DMARCでは、以下のレコード名の TXTレコードを、DMARC レポートを受信するドメインで公開することで、「自分は指定したドメインの DMARC レポートを受け取りますよ」と宣言します。

レコード名
"送信ドメイン." + ”_report._dmarc.” + "レポートを受信するドメイン"

レコード値
"v=DMARC1"

Customers Mail Cloud の例を見てみましょう。

$ dig txt smtps.jp._report._dmarc.dmarc.smtps.jp
;; ANSWER SECTION:
smtps.jp._report._dmarc.dmarc.smtps.jp. 60 IN TXT "v=DMARC1"

Customers Mail Cloud では、@dmarc.smtps.jp というドメインでレポートを受信しています。ですので、このドメインに、_report._dmarc を書いて、さらにその前に送信ドメインである "smtps.jp" を書いています。このTXTレコードが DNS に公開されていないと、ISP はレポートを送信してくれませんのでご注意ください。

DMARCレポートを読む

DMARCの集計レポートは、プログラムが読みやすいようにXML形式となっています。このため、メール運用担当者のメールボックスでレポートを受信し、人間がこれを読むというのはあまり現実的な運用ではありません。 DMARC レポートの解析・モニタリングを提供するサービスを利用するのが良いかと思います。

Customers Mail Cloud でも DMARC レポートの解析ツールを開発していまして、現在、ベータ版を運用しています。

f:id:gorotan35:20171221125452p:plain

※ DMARC レポートの解析・モニタリングサービスを利用する場合、 ruaタグには、サービス事業者から提供されるメールアドレスを登録します。このため、サービスを利用する場合は、先ほど説明した、_report._dmarc の TXTレコードを公開する必要はありません。

おわりに

SPF, DKIM といった送信ドメイン認証に対応されている方は多いかと思いますが、 DMARC では、Envelope-From のドメインや、作成者署名など、より厳格な送信ドメイン認証を要求しています。このような DMARC の仕様や、実際の設定方法についての情報が少ないように思いましたので、主にメール配信サービスを利用されている方を想定して、できるだけ詳しく説明を書いてみました。ご参考になれば幸いです。

Customers Mail Cloud ブログ

DMARCと送信ドメイン認証( SPF, DKIM) を理解して、実際に設定してみよう