ページの先頭です


ページ内移動用のリンクです

  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review(IIR)
  5. Vol.35
  6. 2.メッセージングテクノロジー

Internet Infrastructure Review(IIR)Vol.35
2017年6月20日
RSS

目次

2.3 メールの技術動向

ここでは、迷惑メール対策にも有効な送信ドメイン認証技術、特にDMARC(※9)の普及状況や技術動向について報告します。

DMARCは送信ドメイン認証技術のSPFとDKIMを基盤に、送信側から受信ポリシーを示したり、受信側での認証結果をレポートで受け取れることで、より正当なメールが送受信しやすくなるための技術です。そうした状況を作り出すためにも、DMARCが今後普及していくことが望まれます。

2.3.1 DMARCの普及状況

IIJのメールサービスでは、受信したメールについてDMARC 認証を行っています。図-2に示したグラフは、直近の2017年4月に受信したメールのDMARCの認証結果の割合を示したものです。認証結果"none"は、受信したメールの送信ドメインが、DMARCを導入していなかったことを示す認証結果です。"none"が87.7%ですので、9割近い受信メールがまだDMARC に対応していないこと示しています。

図-2 DMARCの認証結果割合(2017年4月)

次に、2016年1月からの認証結果割合の推移を図-3に示します。残念ながら"none"の割合が87%前後で推移しており、ほとんど変化のない結果となりました。既にSPFやDKIMを導入していれば、DMARCレコードを記述するだけで送信側のDMARCは導入できたことになりますので、こうした認証率の低さは、DMARCが国内であまり認知されていないことを示しているものと考えています。

図-3 DMARCの認証結果割合の推移

2.3.2 DMARC普及に向けて

DMARCの認知率の低さを確認するために、受信したメールをSPFとDKIMとDMARCについて、それぞれの認証結果の組み合わせを調べてみました(図-4)。対象は、図-1と同じく2017年4月です。

図-4 送信ドメイン認証結果の組み合わせ(2017年4月)

いずれかの認証結果が"pass"だったものは、そのまま示しています。例えば"DMARC+SPF+DKIM"のデータ項目は、DMARC とSPFとDKIMのすべての認証結果が"pass"だったことを示しています(グラフでは6.7%の割合)。逆に"!()"で括られたデータは、いずれの認証結果でも"pass"だったものはなく、逆に"fail"などの認証が失敗した認証技術の組み合わせを示しています。例えば、"! (SPF)"のデータ項目は12.5%ありますが、 これはDKIMとDMARCでは認証できなかった(認証結果としては"none")が、SPFだけの認証結果が失敗なもの、つまり"hardfail"、"softfail"、"neutral"のいずれかの認証結果だったことを示しています。

このグラフでは、DMARCでは認証できていないが、SPFあるいはDKIM、あるいはその両方で認証できた割合が56.5%もあります。つまり、受信したメールの半分以上が、本来DMARCレコードを記述するだけで、DMARCとして認証できる状態、潜在的にDMARC普及率を向上できる送信元であったと言えます。もちろん、第三者署名の課題など、単純にDMARC認証できないケースに該当することでDMARCレコードを記述できていない可能性は考えられますが、そうした場合でも、DMARCポリシーを強い設定にしなければ、現状悪影響はあまりありませんので、やはり普及率の低さは認知度に影響していると考えています。

送信側でDMARCを導入することは簡単です。例えば、"iij. ad.jp"ドメインにDMARCレコードを設定するには、"_dmarc" サブドメインを作成し、そのTXT資源レコードにまず以下の設定をしてみてください。

_dmarc.iij.ad.jp IN TXT "v=DMARC1; p=none"

SPFかDKIMを導入しているのであれば、最初の設定としては、これで十分です。パラメータ"p="の意味は、認証が失敗した場合に送信側から受信側に求める処理のポリシーを示す値で、表-2の値が設定できます。"none"は隔離や受信拒否などを求めない値となりますので、仮にSPFやDKIM、DMARCで認証失敗したとしても、正しくDMARCの仕様に沿った処理をする受信側に対しては、悪影響はありません。このように、送信側メールサーバのIPアドレスなどを調べる必要もありませんので、SPFレコードより簡単に設定することができます。

表-2 DMARCレコードのポリシー

更に、"rua="や"ruf="のパラメータを正しく設定すれば、機能に対応しているメール受信側から、認証結果のレポートを受信できるようになります。これらのレポートを参照することで、これまで確認することができなかった、SPFやDKIMが正しく認証できていなかったメール送信経路を明らかにできたり、自組織を詐称したメールがどこからどの程度送信されているか、を知ることができるようになります。これにより、正しいメールの配送経路を正しく認証できるように修正したり、詐称メールがメール受信者に届かないように、より強い"reject"などのDMARCポリシーを設定することができるようになります。

ただし、"rua="を指定することで受け取れるようになる集約レポート(aggregate report)は、XML形式のデータで、更に圧縮されたMIME形式のメールで届きますので、実際にデータを参照するためには、ある程度の準備が必要となります。最近では、こうしたレポートを代わりに受信し、視覚的にデータとして提示するサービスもありますので、それらを利用する、という方法もあります。

2.3.3 DMARCレポートの委譲

DMARCレポートを自ドメイン宛て以外に送信する場合、つまりレポートの受信を委譲するためには設定が必要になります。これは、勝手に第三者をレポート先に指定し、詐称メールを大量に送信することで無用なレポートが無関係の第三者に送信されてしまうことを防ぐためです。DMARCレポートを委譲する側と委譲される側の間で、双方の関係が見えるような設定が必要になります。具体的には、DMARCレコードのレポート先に示されたURIがそのレコードのドメインと無関係である場合、図-5のように委譲先でのDNS設定が必要になります。

図-5は、"example.jp"のレポートの委譲先に"example.com"を指定した場合です。この場合、"example.com"側では、"example. jp"のDMARCレポートを受け取ることを示すために、"example. jp._report._dmarc.example.com"にTXT資源レコードに"v=DMARC1"を設定します。レポートを送信するメール受信側は、送信時にDNSを参照することで委譲関係を確認します。

図-5 DMARCレポート委譲時の設定

2.3.4 DMARCポリシー

DMARCの普及あるいは送信ドメイン認証技術全体がどの程度普及しているかを示す指標の1つとして、DMARCレコードで設定しているポリシーを確認する方法が考えられます。つまり、より強いポリシーを設定しているドメインの割合が高ければ、正規のメールが認証失敗する可能性がほとんどない状態と判断して設定していると考えられます。ドメインごとのDMARCポリシーの宣言内容の割合を図-6に示します。

"none"の割合が76.4%と高い結果となりましたが、それでも"reject"の割合が11.0%ありました。1割以上のドメインが、最も強いポリシーを設定しているということは、送信ドメイン認証技術が徐々に普及してきている、認証結果を利用して不要なメールを受け取って欲しくない、と考えるドメイン管理者がある程度存在している、ということを示しています。DMARC認証できるメール割合の増加と共に、より強いDMARCポリシーの割合についても今後注目していきたいと考えています。

図-6 DMARCポリシーの割合(2017年4月)

なお、"error"については、DMARC認証したメール受信時と、調査のためDMARCレコードを参照したときとの時間差があるため、その後ドメインが参照できなくなったなどのDNSエラーを示しています。6.1%と比較的高い割合ですが、とりあえず受け取ってもらうためにドメイン名あるいはそのDMARCレコードを立ち上げた、という場合が少なからずあるのかもしれません。

2.3.5 DNS側の対応

DMARCレコードを設定する場合、DNSサービスを提供する側の対応が必要になる場合もあります。これまで述べてきたとおり、DMARCレコードは"_dmarc"というサブドメインが必要になります。また、DMARCレポートの委譲にも"_report"というサブドメインが必要ですし、DKIMを導入する場合にも"_domainkeys" が必要になります。ところが、DNSを提供する側でこの"_" (アンダースコア)文字を使えない場合があるようです。そのため、DKIM、DMARCを導入する場合は、自ドメインで利用しているDNSサービス側の仕様を確認しておく必要があります。

更に、最近ではメールシステムを他社が提供するクラウドサービス上で利用することが多くなりました。こうしたサービスでDKIMを導入する場合、電子署名の第三者署名となるのが一般的ですが、第三者署名ではDMARCの認証が失敗します。これは、ヘッダ上の送信者ドメインと署名を作成するクラウドサービス側のドメインが異なるためです。双方のドメインを管理していれば、DKIMの鍵の設定や更新などの鍵管理が比較的簡単にできますが、それぞれの管理が異なっている場合には何らかの連携作業が必要になります。これを解決するため、DNSのCNAMEレコードを利用する方法がマイクロソフト社によって示されています(※10)。ところが、利用しているDNSサービスによっては、このCNAMEレコードがそもそも利用できなかったり、CNAMEレコードが指し示すレコードとしてTXT 資源レコードが設定できなかったりする場合もあるようです。これについても、利用しているクラウド型のメールサービスやDNS サービスを事前に確認しておく必要があります。

  1. (※9)Domain-based Message Authentication, Reporting, and Conformance(DMARC), RFC7489(https://www.ietf.org/rfc/rfc7489.txtblank)。
  2. (※10)DKIMを使用して、Office 365のカスタム ドメインから送信される送信電子メールを検証する(https://technet.microsoft.com/ja-jp/library/mt695945(v=exchg.150).aspxblank)。
2.メッセージングテクノロジー

ページの終わりです

ページの先頭へ戻る