どれくらい自社ドメインがなりすまされているか、ご存知ですか?

企業の情報システム部門でメールを担当されているみなさん、この問いに答えられる方は、どれくらいいらっしゃるでしょうか。

「そんなこと、気にしたこともない」という方も少なくないかもしれません。それもそのはず、これまで送信ドメイン認証を代表する SPF、DKIM は、送信者側が受信者側でどのように評価されたか知る術がありませんでした。ましてや、第三者の何者かが自社ドメインを勝手に使って誰かにメールを送っている、なんて知ることは不可能でした。

しかし、DMARC(RFC 7489;「ディーマーク」と発音します) の登場によって状況は一変しました。DMARC にはメール受信時点での送信ドメイン認証の結果を、差出人へレポートできる仕組みが備わっています。この DMARC の仕組みを利用し、またIIJセキュアMXサービスを利用することで、以下のようにグラフィカルに統計データを見ることが可能になりました。

どのような仕組みでこれを実現しているのでしょう?
今回は、この「DMARC レポート」の中身を詳しく見ていきたいと思います。

DMARC レポートを受信しよう

DMARC レポートを受け取るには、まず DMARC レコードの公開と、受け取るためのメールアドレスが必要です。例えば IIJ では以下のように設定しています。

_dmarc.iij.ad.jp. IN TXT "v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:dmarc-rua@dmarc.iij.ad.jp"

レポートを受け取るために必要な記述は rua= の部分です。rua は Reporting URL(s) for aggregate data の略で、通称「集約レポート」と呼ばれ、「SPF, DKIM の認証結果の集計を dmarc-rua@dmarc.iij.ad.jp に送ってほしい」という意味になります。宛先メールアドレスは複数設定することもできます。

DMARC レコードを宣言してから、Google (@gmail.com) や AOL (@aol.com) といった、DMARC レポートの送付に対応している事業者宛にメールを送信すると、だいたい一日くらいしてレポートが届くようになります。実物を見たい方は、ここで一旦読むのをやめて、明日以降、実際に届いた DMARC レポートを見てから、もう一度お越しください。

DMARC レポート大解剖

DMARC レポートは XML フォーマットで 1日 1通、GZIP 形式で圧縮された添付ファイルで送られてきます。^(※1)(※2)
圧縮ファイルを展開すると、XML ファイルが出てきます。以下は Google から送られてきたもののサンプルの一部です。

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1551916800</begin>
      <end>1552003199</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.jp</domain>
    <adkim>s</adkim>
    <aspf>s</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>5</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.jp</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.jp</domain>
        <result>pass</result>
        <selector>key1</selector>
      </dkim>
      <spf>
        <domain>example.jp</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

簡単な説明は以下の通りです。

いかがでしょうか。
送信したメールが、受信者側でどのように評価されたのか、ちょっとメールの流れが見えてきましたよね? ^(※4)

DMARC レポートを活用しよう

こんな貴重なデータが無料で手に入るのなら、活用しない手はありません! 早速設定しましょう。
DMARC レポートを受け取るのに必要な最低限の DNS 設定は、以下の通り。3分でできます。^(※5)

(例) example.jp ドメインに設定する場合:

_dmarc.example.jp. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.jp"

レコードの意味は以下の通りです。

もし、受け取ったレポートを見て、送信ドメイン認証の検証結果が fail となっている場合は、以下のようなケースが考えられます。

どのケースに該当しているかは、個々の事情により判断が異なりますので、参考情報として捉えてください。
(でも DMARC がなかったら、このような情報すら手に入らなかったので、とても有益なはずです!)

DMARC レポートをしばらく眺めていると、月初・月末に出現する傾向や、自社ドメインを詐称して送られる spammer の存在に気付くことがあります。また、正規な出口メールサーバなのに SPF レコードに含まれていなかったり、DKIM 署名がいつの間にか壊れていた、といった異常に気付くこともできますので、メールフローの透明化に役立てることもできます。

DMARC レポートの可視化

上記で取り上げた DMARC レポートのサンプルは、適度にインデントされて改行が入っているので、それなりに目でも読み解くことができますが、DMARC レポートを送付してくれる事業者によっては、インデントや改行が全く入っていないケースもありました。それもそのはず、DMARC レポートは人が毎日目で見て確認するのではなく、ある程度機械的に処理され、自動化されたシステムに組み込むことを想定して作られています。

そこで IIJ は、この DMARC レポートを自動で可視化するツールを開発し、2019年 3月より、IIJセキュアMXサービスで提供を始めました。
冒頭でお見せしたスクリーンショットは、IIJセキュアMXで提供中の DMARC レポート統計画面のサンプルです。

あの読みにくかった XML ファイルが、一気に可視化されましたね！

また、DMARC レポートは、それぞれの宛先の組織から届きますので、1日の傾向を把握するには全てのレポートを統合して集計する必要がありますが、これも自動で行ってくれます。大企業なら複数のドメインを管理していることも多くありますが、これも DMARC レポートの送付先をIIJセキュアMXサービスにするだけでできちゃいます！

IIJセキュアMXサービスをご契約のお客様は、上記で紹介した DMARC レポート解析機能を無料でご利用いただけます！
本機能をリリースしてから利用者も順調に増えており、お客様からも好評いただいております。ぜひ、ご活用ください。

(参考) IIJ、「IIJセキュアMXサービス」の機能を拡充し、DMARCレポート統計機能を提供開始

なお、DMARC レポートの XML スキーマは、RFC 7489 の Appendix C に記述があります。自力で解析システムを構築される場合は、参考にしてみてください。

「アライメント(Alignment)」という概念

最後に DMARC には「アライメント」という新しい概念があります。少し難しいのですが、メール担当者なら必ず理解して欲しいポイントです。用語を用語で説明してしまいますが、まず、SPF に要求されるアライメントは、以下の通りです。そういうものだと思ってください。

strict モード(aspf=s)	エンベロープ From ドメイン = ヘッダ From ドメイン 完全に一致
relaxed モード(aspf=r)	エンベロープ From の組織ドメイン = ヘッダ From の組織ドメイン 一致

ここで「組織ドメイン」という、また新しい用語が出てきてしまいました。

端的に言うと、組織ドメインとは iij.ad.jp のような、「みんなのものではないもの」です。
一方で、.com、.co.jp、.jp、.tokyo.jp などは、「みんなのもの」です。なぜなら、(誰も取得していなければ)その下のレベルのドメインを取得できるからです。

ここで言う「みんなのドメイン」は、Public suffix と言ってインターネット上で公開されており、時々アップデートされています。
https://publicsuffix.org/list/public_suffix_list.dat
そして、「組織ドメイン」と「アライメント」には、以下のような関係が成り立ちます。

(例) 組織ドメインが iij.ad.jp のとき

• 上図で例示したサブドメイン ml.iij.ad.jp、bounce.ml.iij.ad.jp、us.iij.ad.jp のいずれも、組織ドメインは iij.ad.jp です。
• bounce.ml.iij.ad.jp の組織ドメインは、ml.iij.ad.jp ではないことに注意してください。

 

次に DKIM に要求されるアライメントは、以下の通りです。