Internet Infrastructure Review（IIR）Vol.35
2017年6月20日

2.3 メールの技術動向

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

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

2.3.1 DMARCの普及状況

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

拡大する

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

2.3.2 DMARC普及に向けて

いずれかの認証結果が"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資源レコードにまず以下の設定をしてみてください。

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

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

2.3.3 DMARCレポートの委譲

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

2.3.4 DMARCポリシー

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

なお、"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.txt)。
2. （※10）DKIMを使用して、Office 365のカスタム ドメインから送信される送信電子メールを検証する(https://technet.microsoft.com/ja-jp/library/mt695945(v=exchg.150).aspx)。

2.メッセージングテクノロジー

• 2.1 はじめに
• 2.2 迷惑メールの動向
• 2.3 メールの技術動向
• 2.4 おわりに