綺麗に死ぬITエンジニア

DMARCを利用したEメールのなりすまし対策

2016-01-29

メール送信時に使われる比較的新しい技術、「DMARC」というものをご存知でしょうか。

インフラエンジニアでない人なら知らない方も多いですが、メールというものは「なりすまし」が簡単にできる技術です。よくメールに記載されている「送信者メールアドレス」の欄は、実はメーラーが勝手に自動生成したもので、仕組み上はどんなメールアドレスでも記載できるので、対策をしなければどんな人にでもなりすますことができます。

今回は、そんななりすまし対策を統合的に行うことができる、DMARC(ディーマーク)という技術を紹介します。メールのなりすましをされては困る、高い信用度が必要な会社や組織では、今後必須の技術になると思いますので、導入されていない場合はいち早く導入を検討しましょう。

DMARCの概要

一言でいうと、「2つのメールの送信ドメイン認証技術(SPFとDKIM)を用いた、レポーティング・ポリシー制御のフレームワーク」のことです。

と、言われてもさっぱりでしょう。

現状、実際に送信されたメールを送信したメールサーバーと、実際のメールに記載されている送信者メールアドレスが、一致しているかを確認する技術(送信ドメイン認証技術)があります。その1つがSPFであり、もう1つがDKIMです(後述)。

その技術を用いれば、送信されてきたメールが「正当なもの」なのか「なりすましの可能性があるもの」なのかを判断できます。

しかし、SPFやDKIMを使っていないメールサーバーも多く、使っていても例外的に認証されたメールサーバー以外からメールを送信するパターンがあったり、メールがポリシー違反として誤って送られてこない事態を避けるために違反したものであっても受信してしまったり、正しく運用するには技術的な敷居が高く、多くの課題がありました。また、実際にポリシー違反として弾かれたメールの集計レポートが取れないなど、可視化できない部分も問題となっていました。

そこで、それらの技術をまとめて、1つの標準化されたルールのもとで、メールサーバーを運用していこうという動きが、DMARCの始まりです。

こちらにDMARCの公式サイト?があります。

送信ドメイン認証技術、SPFとは

DMARCを知る前に、送信ドメイン認証技術の動作を知らなければ話にならないので、まずはそちらの説明から。

SPFは、まず送信ドメインを管理するDNSサーバーにSPFレコード(TXTレコードで記述されたSPFのための定義)を用意します。SPFレコードには、正規の送信メールサーバーのIPアドレスが記載されています。

そして受信側メールサーバーがメールを受信したとき、その送信ドメインのDNSサーバーのSPFレコードを確認し、実際に送ってきたメールサーバーのIPアドレスと確認したSPFレコードのIPアドレスが一致したとき、正規のメールだと判断します。

つまり、送信ドメインのDNSサーバーが証人となるわけです。

送信ドメイン認証技術、DKIMとは

DKIMもSPFと、大枠の仕組みは同じで、DNSサーバーを有効活用します。しかし、こちらはIPアドレスではなく、公開鍵と秘密鍵を用いて認証します。

まず送信ドメインを管理するDNSサーバーにTXTレコードで公開鍵を記述します。

そして送信メールサーバーで秘密鍵を使って送信メールのヘッダに暗号化した署名情報を記載します。受信側メールサーバーでは、送信ドメインを管理するDNSサーバー上の公開鍵を取得し、署名情報を検証します。

これによりメールの送信者(ドメイン)とメール本文の正当性(途中経路で改ざんされていないこと)の両方を確認できます。

SPFとDKIMのポリシーを制御する、DMARCとは

そして、ようやくDMARCです。

DMARCではSPFとDKIMのどちらかまたは両方を使用します。

メールサーバーにて新しくメールを受信したとき、まずはDKIMで、送信メールに記載された署名が正しいか、送信メールの内容が改ざんされていないかを検証します。

次に、SPFで送信メールサーバーのIPアドレスが正しいかを検証します。

そしてそれらの送信ドメイン認証を通過したものは、送信元及び送信メールの内容が正当だとして、通常どおり受信します。

逆に送信ドメイン認証を通過しなかったとき、そのときの動作を決めるのがDMARCです。

こちらも、あらかじめ送信ドメインのDNSサーバーにDMARCレコード(TXTレコードで記述されたDMARCのための定義)を用意します。DMARCレコードの定義によって、送信ドメイン認証を失敗したときのメールの動作について定義することができます。通過させてもいいか、それとも隔離して保存しておくか、それとも破棄するか、といった怪しいメールに対する挙動をそれぞれの組織におけるコンプライアンスに合わせて定義することができます。

実際の設定方法

私は業務用のメールにG Suite: 旧Google Apps for Work(Gmail)を使用していますが、その場合は簡単に設定できました。

下記のURLに具体的な設定方法についてまとめられています。なお設定には前述したとおり、該当ドメインのDNSサーバーのレコード定義を変更する必要があります。

また、プログラムによる実装は以下が参考になります。

まとめ

メールサーバーの運用や設定に関しては見直す機会が少なく、特にITリテラシーの低い古くからある企業などでは、この辺りの対策をしていないところも多いと思います。

組織の信用度にも関わる部分ですので、一度見直してみて、DMARCを利用していない場合は利用を検討してみてはいかがでしょうか。