テックブログ

2024.2.19

レコードを設定しただけでは終わらない。DMARCレポートを解析してみよう

お疲れ様です。ネットアシスト開発部の ykinjo です。

今回は、情勢の流れにより国内でも普及が進んできたメール認証関連技術の一つである「DMARC」と「DMARCレポート」の簡単な解析にスポットを当てていきたいと思います。

DMARCレコード設定を済ませた。だけでは終わらない

昨今、メールサーバーやメール送信を伴う各種Webシステムから送られるメールについて、そのメールがスパムメールやなりすましメール等ではない事をチェックするためのメール認証技術の普及が進みつつあります。メール認証技術の代表的なものには「SPF」「DKIM」が有ります。

そしてそれらの設定を適切に済ませた状態のサーバーでは、以下が有効になっている状態かと思います。

適切なMXレコードの設定
適切なDNS逆引きの設定
SPFレコードの設定
DKIMレコードの設定とMTA側へのDKIM設定
TLS接続を行う　※Gmailへ送信する場合の要件

これらに対し、

メール受け取り側でSPF/DKIM/ドメインのアライメント等の認証に失敗した際の処理方法の指示
→そのメールを隔離する、削除するなどの指示。
メール受け取り側での認証状況レポートを送信側へ返す
→どの送信元IPからのメールが認証失敗している、等。
→レポート受け取り側はレポート内容を確認し、適切に運用できているか確認する。

為の技術がDMARCになります。そして、DMARCを適切に運用するためには後者の「メール受け取り側での認証状況レポートを送信側へ返す」部分の対応を行うためには、DMARCレコードをDNSサーバーに追加する以上の対応が必要になります。

DMARCレポートを読んでみよう

DMARCレコードにDMARCレコード送信先メールアドレスを設定すると、DMARCに対応した送信先メールサーバーから毎日DMARCレポートが送信されてくるようになります。これには .gz または .zip 形式で圧縮されたXMLファイルが添付されています。

このXMLファイルはそこまで複雑なフォーマットではないので、人間が読むことも一応可能です。以下が実際のDMARCレポートXMLの冒頭部分になります。

ざっくり注目すべき点として、以下のような情報が含まれています。

report_metadata
- レポートを送っている側の情報です。org_name から分かるように、このレポートは docomo.ne.jp で処理されたメールのレポートになります。
- data_range はUNIXタイムになっており、基本的には毎日1日分の内容がレポートされてきます。
policy_published
- DMARCの設定情報です。
record
- これが最も重要な情報です。どの送信元IP（source_ip）から何件（count）のメールが来て、DMARC認証結果がどうなったか（dkim: pass/fail spf: pass/fail）になったか、という情報が得られます。
- policy_evaluated と auth_results にそれぞれSPFとDKIMの認証結果が表示されていますが、これは若干意味合いが異なり、auth_results がそれぞれの認証結果、policy_evaluated がDMARCとしての認証結果になります。

このレポートの内容から、不正なメールがあずかりしらない所から送信されていないか、もしくは社内のメール認証対応が漏れたサーバーから送信されたりしていないか、等が確認できます。このようにメール認証が問題なく動いているか経過観察するためのものがDMARCレポートになります。

レポートの詳細な内容については、より詳しく解説している記事なども有りますので、そちらを参照してみてください。

DMARCレポートを解析してみよう

しかし、毎日何通もDMARC対応サーバーからDMARCレポートが送られてきて、それを1つ1つ目視でチェックするのは厳しいです。さらに、ファイルは .gz もしくは .zip で圧縮されているため1つ1つ伸張（解凍）する必要が有る他、XMLの内容が1行になっているパターンも有り、その場合はXMLに対応したエディタやビューワで複数行にフォーマットされた状態で読む必要が有ります。

このようなニーズに対応するために様々な有用なSaaSが存在しますが、とはいえシンプルなXMLファイル群ですので、まずは簡単なスクリプトで解析・統計ツールを組むことができます。1コマンドで済むならまずは1コマンドで解析してみたいですよね。

以下が実際に組んでみたスクリプトです。dmarc_parser.php をお手元の環境にダウンロード/Git Cloneし、PHP 8.0以降のバージョンで実行することができます。ライセンスはMITにしています。

https://bitbucket.org/netassist_dev/dmarc_report_parser/src/main/

php dmarc_parser.php --help で使い方を表示できます。


php dmarc_parser.php --help
Usage: php dmarc_parser.php [options] [target directory or file]

-v --version    Show version number.
-h --help       Show command help.
--include-ips=[ips]     Include only specified IPs.
--exclude-ips=[ips]     Exclude specific IPs.
-s --statistics-mode    Show statistics all data.

DMARCレポート添付ファイルを集めた適当なフォルダを作成し、そのフォルダのパスを引数に指定し実行すると、レポート処理元ごとにレポート内容が表示れます。添付ファイルは圧縮されたままで構いません。

また、 -s オプションを付けると送信元IPごとに合計した結果を表示することができます。

簡単なPHPスクリプトですので、policy_evaluated ではなく auth_results の方も見るように書き換える、処理日時ごとに振り分ける処理を追加する、解析結果をDBに保存するなど、コードのカスタマイズも簡単かと思います。

このようにDMARCレポート解析ツールを発展させていってもいいですし、より大規模・自動化された・グラフィカルなチェックを行いたいのであれば、既存のSaaSを利用するのも良いかと思います。

DMARCの検証・レポートに対応したメールサーバーにする

ここまでは送られてきたDMARCレポートに対する対応でしたが、では、DMARCレポートはどうやって送られてきているのでしょうか。これはメールを受信するサーバー側でDMARCを検証し、更に送信元にレポートを返してあげる処理の追加が必要になります。

つまり、メールを受信するサーバーではMTA側でもDMARCに関連した設定が必要になります。Postfixを利用している場合、OpenDKIM のように OpenDMARC というソフトウェアが有り、それを使って他のサーバーにDMARCレポートを返してあげることが可能になります。

Gmailにさえ送信できればいいのではなく、自分自身のサーバーもDMARCに対応していくのであれば、レコードを追加するだけでなくMTA側でもDMARCに対応しておいた方が望ましいでしょう。

DMARC検証されたメールの転送に対応したメールサーバーにする

メールを転送する場合、メール転送先のサーバーでDMARCの検証が失敗扱いになることが有ります。これを回避するための技術が「ARC」になります。最初にメールを受信したサーバーがDMARCの検証結果をメールのARCヘッダとして付与し、転送先のサーバーではARCヘッダの情報を見る、というような流れになります。

つまり、DMARC検証を受けたメールを転送するサーバーではMTA側でARCに関連した設定が必要になります。多いですね。これもPostfixの場合には OpenARC というソフトウェアが利用可能です。

まとめ

というわけでDMARCはレコードを設定するだけでは終わらない、という趣旨の記事でした。日々のDMARCレポートを確認することで各種メール認証の設定誤りに早期に気づくことができますし、自身のメールサーバーでDMARCの検証を行ったりレポートを返してあげるには追加の設定が必要ですし、転送に対応するにはARCへの対応が必要となります。

メールはメールサーバーにしても送信するWebシステムにしても、既に実運用されている場合は調整が難しいこともあるかと思いますが、今後必要なものとして、対応を進めていきましょう。