Yahoo!メールのDMARC導入のその後と、「DMARCレポート」の活用術

こんにちは。メッセージング技術領域における第11代黒帯（ヤフーでのスキル任命制度）の中村成陽と申します。エンジニアとしてYahoo!メールを担当しております。

以前、Yahoo!メールにおけるなりすましメール対策として、送信ドメイン認証技術である「DMARC」についてのご説明を中心とした記事を掲載いたしました。今回はその続きとして、この DMARC の効果を中心にさらに掘り下げていくのと、さらにはメールの送信も行っている弊社が活用している「DMARCレポート」についてもご説明します。

前回の記事のおさらい

以前 Tech Blog に掲載した以下の記事には多くの反響をいただきありがとうございました。想定以上でしたので驚くと同時に、たくさんの方に関心を持っていただき非常に嬉しかったです。

あなたの会社のなりすましが現れたら？ 迷惑メール対策方法とYahoo!メールのDMARC導入事例紹介

前回の記事では送信ドメイン認証技術についての説明と、なりすましメール対策としてYahoo!メールに導入した DMARC やブランドアイコンのご紹介をいたしました。DMARC というのは送信元を保証するための技術の一つで、その送信元を偽ったメールの扱いを、正規の送信者の意向である”DMARCポリシー”に応じて決めることができるというのが大きな特徴です。今回の記事ではその DMARC を中心に掘り下げていきますので、概要を知りたいという方は前回の記事を読んでいただければと思います。

DMARC導入、その後の効果

DMARC 導入後の効果について、前回の記事でも「DMARCポリシーに応じて多くのなりすましメールの受信をブロックできております」とお話ししました。その後の状況がどうなっているか、ご説明したいと思います。

（復習）DMARCポリシーとは？

前回も触れた内容ですが、大切なポイントなので改めて詳細に説明したいと思います。DMARCポリシーとは正規の送信者が宣言する「自身になりすまされたメールへの振る舞い」のことで、DMARC に対応している受信サーバはその宣言に応じて処理を行います。なお、宣言そのものはDNSの対象ドメインのTXTレコードに対して決められた書式で行います（これをDMARCレコードと呼んでいます）。対象のドメインを HeaderFrom としているメールで、なおかつ SPF や DKIM といった送信ドメイン認証に失敗しているメールに対して希望する振る舞いとして宣言できる内容は、具体的には以下の3種類があります。

• none : 何もしない
• quarantine : 隔離する
• reject : 拒否する

当然ながら reject とするのがより堅牢なポリシーであり、こちらに設定することで受信者に対してなりすましメールが届かないようにできます。

ポリシー reject による受信拒否状況

DMARCポリシーが”reject”である送信元を偽ったメールのブロック数はさらに増加傾向となっており、ある一カ月の受信拒否数を比較した昨対比ではおよそ1.6倍となっております。この一年でYahoo!メール全体の総受信数も同じように増えている、ということはありませんので、恐らく DMARC をポリシー reject で宣言しているドメインが増えていることでこのような状況になっているものと思われます。非常に良いことだと思いますし、この傾向が続けば良いと考えています。

ポリシー quarantine の取り扱い

前述しましたが、DMARCポリシーの”quarantine”について「（認証に失敗したメールを）隔離する」という宣言であると説明しました。メールの世界で隔離するということなので、要するに多くの場合は「迷惑メールフォルダに送ってほしい」という意味合いなのですが、実はこの quarantine というポリシーの定義や扱いについては DMARC について標準化している RFC 7489 でも結構ふわっとしており、以下のように記載されています。

quarantine と宣言したドメインの所有者は、DMARC認証に失敗したメールを、そのメールの受信者が疑わしいものとして扱うことを望んでいる。メールの受信者は、その機能に応じて「迷惑メールフォルダに配置する」、「通常のメールよりも迷惑メール判定しやすくする」、もしくは「疑わしいというフラグを立てる」といった処理をする場合がある。

つまり、quarantine という英単語自体は“隔離”といった意味ですが、「絶対に迷惑メールフォルダに送りなさい」とは言っておらず、その扱いについては受信者の裁量に任されている部分があります。
DMARC はその仕様上、正規の送信者が送っているメールであったとしても、設定の不備などにより送信ドメイン認証に失敗をした場合はなりすましと判定されます。従って、場合によっては正規のメールが受信拒否されるなどといったケースも想定されました。そこで、Yahoo!メールとしては DMARC の導入当初はあまりこの quarantine のスパム判定を強くせず、「通常のメールよりも迷惑メール判定しやすくする」ということで、場合によっては迷惑メールフォルダに送られることがある、という程度の扱いに留めておりました。

しかし、現在ではリスクより効果が大きいと判断し、quarantine での宣言ドメインを偽ったメールを迷惑メールフォルダに送りやすくするよう対応を行いました（もちろん、一部例外はあります）。その理由としては、みなさんもきっとお使いであろうあの大手ECサービスのドメインも quarantine で宣言されている（2021/11/19現在）など、フィッシングメールの標的となってしまうようなドメインにおいて quarantine が設定されているケースが少なからずあったためです。また、reject による受信拒否の効果が非常に大きかったこと、更には、前回の記事でもお話しした通りユーザーからの「正規のメールが届かなくなった」といった問い合わせも少なかったことなども判断材料となっております。

このようにネガティブな影響を最小限にできるようだんだんと慎重に進めていっている状況ではありますが、受信箱に届かなくなることによる効果も大きいと考えており、これも DMARC によるメリットの一つだと考えています。

DMARCレポート

ここからは別の切り口で、DMARC のもう一つの大きな特徴である「DMARCレポート」についてご紹介します。

前回も少し触れましたが、DMARCレポートというのは対応している受信サーバから受け取れる統計情報のことで、DNSで対象ドメインのDMARCレコードにメールアドレスを記載しておくことで、そこに受信できます（なお、個人情報保護の観点から解決すべき課題も多く、現在Yahoo!メールではこのDMARCレポートの送信には対応しておりません。将来的には開発予定となっております） 。

ヤフーはYahoo!メールというサービスを提供するISPでもありますが、一方で各サービスからのお知らせメールなどをユーザーの皆さんにお送りする立場でもあります。ではこれらのメールが配信されるドメインである mail.yahoo.co.jp のDMARCポリシーがどうなっているかというと、現在は quarantine となっております（2021/11/19現在）。以前は none （何もしない）だったのですがそこから引き上げを行った状況であり、さらに将来的には reject としたいと思っております。その際に活用できるのがこのDMARCレポートです。そもそも none というDMARCポリシーがある意義として、このDMARCレポートが存在することも理由の一つであると理解しています。

※なお、厳密にはDMARCレポートには2種類ありますが、今回はそのうち実際にヤフーも活用している“Aggregate Report”の方のみを取り上げたいと思います。

ポリシーを引き上げたい経緯

mail.yahoo.co.jp ドメインのDMARCポリシーを現状の quarantine からさらに reject へと引き上げたい理由としては、当然ながらユーザーのフィッシング被害の防止のためです。弊社もさまざまなサービスで多くの皆様にご利用いただいており、どうしてもフィッシングメールの標的になってしまう状態となっています。DMARC を導入したYahoo!メールの提供事業社として、その効果は先述の通り日々実感しておりますので、ユーザーの皆様を守るためにもポリシーをより厳しくしていきたいというのが経緯です。

難しいポイント

「じゃあ reject にしちゃえばいいじゃん！」という話になるかと思います。確かに TXTレコードに記載の DMARCポリシーを書き換えれば終わる話なので技術的には全く困難はないのですが、実際問題そう簡単にはいきません。特にヤフーのように多くのサービスを抱えた大きな組織となると、把握できていないシステムなどからのメール送信が行われている可能性もゼロではなく、そのメールが送信ドメイン認証に成功していない恐れもあります。万が一そのようなものがあった場合、ユーザーに必要なメールが届かないという事態になりかねず、これは避けなければなりません。

そこで、mail.yahoo.co.jp ドメインからはどのような状況でメールが送られているのか、その統計情報を得ることができるのがDMARCレポート（DMARC Aggregate Report）です。

DMARCレポートには何が書かれているか

DMARCレポートで受け取れる情報には以下のようなものがあります。

• SPF や DKIM の認証結果
• 送信元IPアドレスとそこから送られた件数
• 受信サーバがそのメールに対して行った処理結果

これにより、ヤフーや関連すると思われるシステムから送られているメールで、意図せずに SPF や DKIM に失敗しているものがないかなどを知ることができるため、DMARCポリシーを変更する際に大いに参考になります。他にも、明らかに弊社が利用しているものではない送信サーバから、送信ドメイン認証に失敗しているメールが送られている状況を知ることもできます。

実際のレポートは以下のような XML ファイルで送られます。

<?xml version="1.0"?>
<feedback>
    <version>0.1</version>
    <report_metadata>
        <org_name>***</org_name>
        <email>postmaster@***.com</email>
        <report_id>***</report_id>
        <date_range>
            <begin>1636934400</begin>
            <end>1637020800</end>
        </date_range>
    </report_metadata>
    <policy_published>
        <domain>mail.yahoo.co.jp</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>quarantine</p>
        <sp>quarantine</sp>
        <pct>100</pct>
        <fo>0</fo>
    </policy_published>
    <record>
        <row>
            <source_ip>***</source_ip>
            <count>2</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>pass</dkim>
                <spf>pass</spf>
            </policy_evaluated>
        </row>
        <identifiers>
            <envelope_from>err.yahoo.co.jp</envelope_from>
            <header_from>mail.yahoo.co.jp</header_from>
        </identifiers>
        <auth_results>
            <dkim>
                <domain>mail.yahoo.co.jp</domain>
                <result>pass</result>
            </dkim>
            <spf>
                <domain>err.yahoo.co.jp</domain>
                <result>pass</result>
            </spf>
        </auth_results>
    </record>
...
</feedback>

XML要素の内容は内容は以下の通りです。

隠してしまっているところもありますが、この場合は disposition が “none” となっているので、DKIM や SPF 認証に成功しているので何もしなかった、ということになります。例示したこのパターンはわれわれが把握している送信サーバから想定通りに送信ドメイン認証に成功しているものでしたが、中には海外のサーバから送られていて、かつ認証も全て失敗しているようなものもあります・・・。

DMARCレポート可視化

このXMLファイルそのままでは見づらいため、可視化をして解析することで初めて意味を成します。われわれは elasticsearch そして kibana を活用して可視化環境を構築し、状況の把握に役立てております。グラフなどを用いて可視化することで主に以下のような観点で確認をしております。

• 自社および関連システムからのメールは想定通り送信ドメイン認証に成功しているか
  • もし認証に失敗しているものがあった場合、SPF や DKIM の設定を行う
• 想定していない送信元からのメール送信が行われているかどうか
  • これらは確認次第、何か対処ができないか検討を行う

これらが把握できることで、自社ドメインのDMARCポリシーを変更しても問題がないか、さらには変更をした場合にどの程度の効果があるかどうかという判断材料になるわけです。

なお、弊社は現状利用していませんが、各社から出されている専用ツールもあり、DMARCレポートの検証結果からさまざまな観点で分析を行い、なりすましメールが配信されているかどうかといった状況を検知してくれるものもあるそうです。

まだ道の途中

このようにヤフーでもDMARCレポートを役立てることで、自社ドメインからのメールの配信状況を把握しております。引き続き活用することで、reject に変更してより強固にしていきたいと考えています。

おわりに

前回の記事では紹介できなかった DMARC の特徴について、ヤフーでの現状を交えて説明しました。残念ながらこれにより全てのフィッシングメールがなくなるわけではありませんが、少なくともユーザーが目にする HeaderFrom アドレスを詐称されているメールに対しては大きな効果を発揮するのは間違いないと思います。前回と同じ結びとなってしまいますが、なりすましメールによる被害を少しでも減らせるよう、ぜひ DMARC を宣言いただきたいと思います。