こんにちは。2回目の投稿になります。技術部ネットワーク課の 松元 です。
私が所属している部署では、ネットワーク/サーバの設計/構築/運用が主な業務ではありますが、まだ自社で取り入れていない技術やサービスの検証も行っています。 今回は、メールのなりすましなどの悪用を防ぐためのメール認証の仕組みであるDMARCをちょこっとだけ試してみました。
DMARCとは？
DMARC (Domain-based Message Authentication, Reporting, and Conformance)とは、
送信ドメイン認証でSPFやDKIMを使って認証する際に、認証に失敗したメールをどう扱うか（そのまま受信する、迷惑メールとして扱う、破棄する）を、メールの受信者ではなく、メールの送信者（ドメインの持ち主）がDNSレコード上にポリシーとして公開して、受信者はそれを参照する仕組みです。
きっかけと試してみたこと
以前、以下のカンファレンスに参加した際にDMARCの紹介があり、将来導入することになった場合の参考にできないかなと試してみました。
今回はちょこっとだけがテーマ？なので、SPF認証でのDMARCの設定を試してみました。
テスト用のドメインにDMARC用のレコードを追加する。
追加したレコード
_dmarc.<テスト用のドメイン> TXT v=DMARC1; p=none; rua=mailto:メールアドレス; ruf=mailto:メールアドレス
解説
| 記述 | 解説 |
|---|---|
| TXT | レコードの種類 |
| v=DMARC1 | DMARCのバージョン （現在はバージョン1） |
| p=none | 受信側がDMARC認証に失敗した場合に参照するポリシー※1 |
| rua=mailto:メールアドレス | DMARCの「統計レポート」の送信先を指定 |
| ruf=mailto:メールアドレス | DMARCの「失敗レポート」の送信先を指定※2 |
※1.ポリシーは3種類（どのポリシーでもDMARCレポートは送られてきます）
- none（何もしない）
- そのまま受信する
- quarantine （隔離する）
- 迷惑メールとして扱う
- reject （拒否する）
- メールの受信を拒否する
※2.失敗レポートの送信先について
- レコードを設定したドメインのメールアドレスを使用します。別のドメインを設定する場合は、送信先のドメインのレコードに追記が必要になります。
設定がうまくできているかを確認する。
なりすまし対策ポータル「ナリタイ」様にて、DMARCの設定を確認できるツールを公開されているので、こちらを使用しました。(空メールを送信すると、ドメイン認証の結果を返送してくれる仕組みです。）結果で届いたメールの一部がこちらになります。
正しく設定されていませんとなっていますが、今回はDKIMでの認証を行っていないことによるものです。設定したSPFの認証とポリシーはOKとなっていることを確認しました。
レポートが送られてくることを確認する。
設定の部分で触れましたが、DMARCには受信者側が対応していれば認証失敗際の送信者側にレポートを送る機能があり、このレポートを参照することで送信者側はどういった内容で認証に失敗したかを知る事ができます。
レポートの種類
- 統計レポート（日次で送られてくる認証に失敗したメールの集計結果のレポート）
- 失敗レポート（認証に失敗したメールがあった際にリアルタイムで送られてくるレポート）
レポートから読み取れること
- メールの送信元IP, Header-From, Envelope-From, 送信ドメイン認証の結果など
レポートの活用
例えば、SPFの認証で失敗していればSPFレコードで設定していないIPアドレスからドメインをなりすまして送っているところがある…といった事がわかり、なりすましメールの送信状況の把握に役立てる事ができます。 レポートはxml形式で送られてくるのですが、XMLファイルをアップロードすることで見やすい形に成形してくれるwebサービスもあります。
XML to Human Converter - dmarcian
DMARC Report Analyzer - DMARC Email XML Parser - MxToolbox
試しに、Googleから送られてきたレポートをXML to Human Converterで変換してみました。
また今回は未確認ですが、dmarc.orgにてソフトウェアの紹介もありました。
所感
DMARCレポートを受け取るだけであれば、spfレコードの設定があれば比較的簡単に導入できるのではないかと思いました。 DMARCレポートを送信する側の設定については今回未確認のため、機会があればこちらも検証してみたいですが、 大量になりすましがあった場合の各レポート送信でどの程度負荷があるのか気になるところです。
