エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

DMARCの対応って進んでますか？

Mail セキュリティ SRE

こんにちは。エムスリーでSREやセキュリティに従事している山本です。

以前に、「Gmailのメール認証規制強化への対応って終わってますか？」という記事を書かせていただいておりますが、そこでちょい出しだけしたDMARCについて書かせていただきたいと思います。

www.m3tech.blog

Gmailへの対応を実施するだけならば、「とりあえずよくわかんないけど入れておけばOK」なのですが、そもそもDMARCは何のために存在していてどのように活用にするのかというところに触れていきたいと思います。

DMARCとは

DMARCの日本における普及は進んでいないと言われることがあります。それ以前に「何のために存在するのか」「どのような動きをするのか」というところから知られていない部分もあります。

SPF/DKIM

前回の記事で触れたSPF/DKIMについておさらいします。

  • SPF : メール送信元のIPを自ドメインのDNSに登録しておくことで、そのドメイン権利者からの送信であることを担保する
  • DKIM : メールに署名を付与し、その署名をした秘密鍵と対になる公開鍵を自ドメインのDNSに登録しておくことで、そのドメイン権利者からの送信であることを担保する

つまりどちらも目的は 自社のメールが自社から送られたことを保証するものです。

これはもちろん正しいことであり、ブログでもその方法について書いてきました。しかしそれは「なりすましで自社ドメインからメールを送る人たち」に対する直接的な防御策にはなりません。

DMARC登場

DMARCはSPF/DKIMを使った技術ですが、少し毛色が異なります。SPFやDKIMをアラインメントを含めて正しく設定すればDMARCはPASSするのですが、目的とするところに違いがあります。

  • SPF/DKIM → 自社のメールが自社から送られたことを保証する
  • DMARC → なりすました自社ドメインのメール(DMARCã‚’PASSしないメール)について拒否/隔離するように指示ができる

DMARCにはSPF/DKIMの処理結果を受けてどうすべきかが書かれている

自社のメールでDMARCをPASSさせる努力というのは、裏を返せばDMARCにPASSしないメールは偽物だ、と言い切るための努力です。 実際に有名な大手企業を名乗る迷惑メールも存在いたします。迷惑メールでなく、実際の企業名を偽る詐欺師かもしれません。そのようなメールを可能な限り削減するためにできる対策なのです。

DMARCで実施できるポリシー三種

DMARCのDNSレコードではポリシーの指定が実施されます。以下の三種です。

  • p=none : DMARCにPASSしなくても特に何もしない(メールサーバの基準に沿って迷惑メール扱いなどをすることを妨げるわけではない)
  • p=quarantine : DMARCにPASSしないなら隔離する(迷惑メールフォルダなど)
  • p=reject : DMARCにPASSしないメールは拒否する

実際に各社を見てみましょう。我らがエムスリーは none、Googleは reject、Appleは quarantineです。

$ dig +short txt _dmarc.m3.com
"v=DMARC1;p=none;rua=mailto:[email protected];ruf=mailto:[email protected];rf=afrf;pct=1"

$ dig +short txt _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:[email protected]"

$ dig +short txt _dmarc.apple.com
"v=DMARC1; p=quarantine; sp=reject; rua=mailto:[email protected]; ruf=mailto:[email protected];"

ポリシーの強化

今回、Gmailでのメール認証で大量送信にはDMARCが必須となりましたが、「とりあえず入れとけ」については p=noneもありです。 しかし、本来は none よりも強いポリシーの方が効果的です。

自社のDMARCポリシーを仮に reject ã‚„ quarantine にすれば、少なくとも対応したメールサーバにおいて、明確になりすましメールを判別できるようになります。それは、例えば [email protected] を名乗ってフィッシングサイトに誘導するようなスパムメールを排除できるわけですし、社員を名乗る詐欺師が @m3.com を騙ったメールを出す事も困難となります。

これがメールセキュリティの現状での目的地です。

強化できるか

自社のメールでDMARCをPASSさせる努力というのは、裏を返せばDMARCにPASSしないメールは偽物だ、と言い切るための努力です。

上でこのように書きましたが、Gmailの規制強化に伴って自社のメールサービスが完璧にSPF/DKIMに対応できれば、確実に「DMARCにPASSしないメールは偽物」と言い切れるはずです。それならば p=none と日和ってないでさっさと p=rejectなどにすればよいはずです。

それができないのは、必ずしも全ての正しいメールがSPF/DKIMに対応できていないかもしれないので自信がないという事です。メールを送信する側は勝手に送信していますが、相手のメールボックスで迷惑メールフォルダに入ってしまっているとすれば、それは検知できません。だから「自信がない」ので断行できません。エムスリーに限らずグローバルに展開している場合には、m3.com を使っているのが国内に限らなかったりしますので、全体的な影響が出てきます。

ちなみに、デフォルトではDMARCのポリシーはサブドメインに継承されます。usa.m3.com などといったドメインについても m3.com のポリシーがそのまま継承されますが、もしもそれが困る場合にはポリシーを上書きするような設定も可能です。ですので、サブドメインごとに分割した運用がなされている場合は影響度を小さくしながら進行させる事も可能です。

DMARCレポート

影響するかもしれないから断行できないといっているといつまでたっても実施できないのですが、そのためにDMARCレポートと呼ばれるものが用意されています。

RUA/RUFの二種のレポート

$ dig +short txt _dmarc.m3.com
"v=DMARC1;p=none;rua=mailto:[email protected];ruf=mailto:[email protected];rf=afrf;pct=1"

DMARCの指定の中で ruf や rua というものがあります。この f の方が失敗メール、 a の方が集約情報のメールです。DMARCに対応したメールサーバが日々、 @m3.com からのメールをチェックしてレポートとして送信してくれるのです。このレポートをチェックいたします。多くのメールを送信している場合とても大量に受信することになりますので、受信先のメールアドレスは注意してください。

念のためですが、RUAレポートのXMLには個人情報や機密情報は一切含まれていません。(メールを送信した先のドメイン名などは含まれます。) RUFレポートにも基本的には含まれませんが、もう少し詳細な情報があります。

このレポートを使って次の確認ができます。

  • 自社から送信したメールでSPF/DKIM/DMARCで失敗しているものはないか？
  • なりすましその他が横行して怪しいメールが飛び交っていないか？

DMARCレポートの確認ツール

XMLなので、そのまま目で眺めてもちょっと意味がわかりません。

以下はMicrosoftから送信されてきたRUAレポートのごく一部です。

<?xml version="1.0"?>
<feedback xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <version>1.0</version>
  <report_metadata>
    <org_name>Enterprise Outlook</org_name>
    <email>[email protected]</email>
    <report_id>b64757d736234cc382af6df3d7049a5b</report_id>
    <date_range>
      <begin>1700956800</begin>
      <end>1701043200</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>m3.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>1</pct>
    <fo>0</fo>
  </policy_published>
  <record>
    <row>
      <source_ip>35.76.16.148</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_to>XXXX.co.jp</envelope_to>
      <envelope_from>bounce.m3.com</envelope_from>
      <header_from>m3.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>m3.com</domain>
        <selector>awsmail-20180830</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounce.m3.com</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
...

よく見るとなんとなく意味はわかりますが、非常に大量なので全てをチェックするわけにはいきません。これを解決するためにはDMARCのレポート解析ツールを使うことになります。受信したレポートメールを自動的にツールに流し込んで…、ということです。 有償のツールが多いと思いますがちょっと手動で見てみるレベルならば以下のものでも良いと思います。どちらもアメリカの企業の提供するものです。

では実際に、Microsoftから来たRUAレポートを後者のサイト(dmarcian)で処理してみます。このサイトではレポートをきれいに可視化してくれます。ただし、10MBが上限ですので多すぎる場合は適当に区切ってください。複数のレポートファイルをアップロードできます。

念のためXMLの要素のうちenvelope-toをsalt+hash化して隠して<envelope_to>b94fdc2eac3669a489d7ff566c40c4ee6729d8dc.com</envelope_to> のような形にしてからアップロードしました。実際にアップロードされたのはヘッダFromドメイン、envelope-from、送信元IP、DKIMドメイン、DKIMセレクタあたりです。送信先はMicrosoftメールを使っているとはいえ、多種多様のドメインとなります。ここを隠しておきました。 レポートURLが生成されますのでそれはシェア可能ですが広く公開されます。確認が終わったら消しておくと良いでしょう。

dmarcianのレポート

この場合はThreat/Unknownのタブ(赤いところ)を選択して中身をよく見てみます。

SPF/DKIMともPASSしているが…

これは、SPF/DKIMが Pass かつ fail-unaligned です。簡単に言えば、次の状態です。

  • ヘッダFromは m3.com(元々m3.comのレポートですのでそうなります)
  • envelope-fromとして willap.jpを使っていて、willap.jpのSPFに合致します(つまり、WiLL Mailです)
  • dkim1._domainkey.willap.jp というDKIMのセレクタに対応する鍵で署名を実施されています

SPF/DKIMともに問題ありませんが、ヘッダドメインと不一致です。(つまり、アラインメントチェックで失敗しています。)

どう判断するか

そのようなメールがレポートされていたとして、次のどちらかです。

  • 誰か悪い人が m3.com を名乗って WiLL Mailで送信している
  • M3で設定してWiLL Mailで送信しているが、DKIMの設定を作成者署名にしていない

WiLL Mailはenvelope-fromが [email protected] となりますが、DKIMは変更可能です。 おそらくはこの変更もれなのでどこの部署がこのメールを送信しているのかを探すということになってくるのです。

もしも仮に前者だとしたら、それはそれで問題ですが、送信できる以上は直接的には手出しできません。 しかし m3.com から送信しているメールから撲滅した時に DMARC設定を変更して reject などにすることでDMARCに対応したメールサーバで拒否させることができるというわけです。

メール転送

他にもレポートに検出された怪しいメールがいくつかあります。

メール転送？

例えば同じようなWiLL Mailからのメール送信でも、これは我々の管理しないIP(その逆引きは XXXX.go.jp) からの送信となっており、envelope-fromである willap.jpとは一致しません。

断言はできませんが、おそらくは XXXX.go.jp で受けたメールをMicrosoftに転送したのでしょうか。そのために送信IPが変化してしまったと。SPFは転送に弱いのでこのようなことが発生します。DKIMについても転送でヘッダ等が変化した際に、電子署名とずれてしまうことがあります。(DKIMはヘッダやボディの中身に署名しますので、そこが書き換えられると改ざんと判断されます。)

このようなものはそれなりに散見されますが、直接的には手出しできませんので今回は静観しています。

今後

エムスリーでもDMARCについてももちろん考慮していますが、現状では p=none になっているという状態です。 それは問題のあるメールの存在を知っていたためなのですが、問題のあるメールを今回のGmail対応で一掃しようとしています。

Gmail対応のあかつきにはさらにDMARCの強化を図っていただけると、世界からなりすましメールが少しでも減るということですので、特に影響力あるドメインをお持ちの会社の方々はどんどん強化していただけると少しでも世界がよくなりそうです。

私は現在は有償のサービスを使っているわけではありませんが、そのようなサービスも多々ありますので、その検討も良いかと思います。

まとめ

  • 来年2月からGmailへの大量送信は規制が始まる → Gmailのメール認証規制強化への対応って終わってますか？ - エムスリーテックブログ
  • DMARCへの対応も必須になるけれど、DMARCってそもそも何なんだっけ？
  • DMARCはSPF/DKIMに対応して「いない」メールを排除するための仕組みだ
  • DMARCレポートを使って自ドメインのメールの対応状況や迷惑メール状況を確認できる
  • DMARC対応で世界がよくなる

We are hiring!

エムスリーやそのグループ会社では常に素敵なエンジニアを募集しております！ 興味あればぜひお越しください！

jobs.m3.com

open.talentio.com