DMARCも組んでみた

前回の記事ではDKIMについて取り扱ってみたのですが、もう少し踏み込んでDMARCについても触ってみました。DMARCとはこのようなものみたいです。

一番のミソなポイントは「送信ドメインが認証失敗時の動作を規定していること」です。
DKIM/SPFは、その動作を受信メールサーバが判断していました。が、DMARCはどうやら「なりすましメールサーバのメールは受け取ってくれるな」的なアプローチができるようです。

適用方法

前提として、SPFレコードおよびDKIMの実装が必要です。送信ドメイン認証が通ったか通ってないかの判断に、これらの認証方式を使っているからです。要は、SPF/DKIMの上にDMARCが成り立っていると考えるとよいのかなと思います。

その上で、権威DNSサーバのTXTレコードとして「_dmarc」レコードを追加することで対応します。簡単ながら書式についても例示してみました。

DMARCでは、後述するレポート機能もあるので、そのレポートを展開する先となるアドレスの指定などもこのレコードで定義されます。

Authentication-Resultsヘッダには、DKIM, SPFに加えて、DMARCヘッダが追加され、その中で認証結果が表示されます。

なお、ポリシーは「なにもしない」「隔離」「拒否」の三段階から選択することができ、レポート集積が目的の場合は「何もしない」とし、その後正式に認証結果に基づいた処理を行わせる際には「隔離」「拒否」の設定を行っていくようです。

DMARCレポート

DMARCでは、実際にメールの認証結果を送信ドメイン管理者へレポートすることが可能です。DMARCレコード追加の際に「rua」「ruf」の定義をしているわけですが、この宛先にレポートを飛ばすことができます。

ただ、それだけではレポートを飛ばすことができず、追加でレポート送信先を認めるための専用レコードを別途構成する必要があります。

TXTフィールドは「v=DMARC1」だけで良いようで、私の環境の場合、送信ドメインも受信ドメインも共にBLUECORE.NETであるため、そのように指定する感じになります（画像中のドメインがTypoしてるんですが、前者が送信ドメイン、後者が受信ドメインです）

すると、デフォルトで1日毎(らしい)にDMARC認証を行った(DMARCレコードを見に行った)メールサーバからレポートが送信されるようになります。内容としてはXML形式となっています。

今回お試しした内容だと、単純にメール受信をし、その中身を開いただけなんですが、実際にはDMARCレポートを集積し、これを解析してどれほどのspam senderがいるのか、それはどの様なヘッダで偽装するのかなどをキャッチアップするなど、もう少し高次的な使い方をすることのほうが多いようです。

セキュリティ製品などは特に、このあたりの機能が充実しており、使いこなせれば、よりセキュリティの高いメールインフラを構成・維持することが可能になるのかなと思います。