詐欺メールを減らす「送信ドメイン認証」、運用時の3大つまずきポイントと対策

　本特集ではここまで、最近の詐欺メールの動向とその対策である送信ドメイン認証を紹介してきた。仕組みを理解したら、あなたの現場にぜひ実装してほしい。

　メール送信側が実装する手間は、ツボを押さえればさほどかからない。DNS（Domain Name System）サーバーのテキストのレコードに記述すればよい。SPF（Sender Policy Framework）とDMARC（Domain-based Message Authentication Reporting and Conformance）、それぞれのレコードのサンプルを示そう。

SPFレコードの記述例。SPFのバージョン、メールの判定基準、処理方法などを記述する

（出所：古賀 勇）

[画像のクリックで拡大表示]

DMARCレコードの記述例。DMARCのバージョン、認証失敗時のポリシー、リポートの送信先などを記述する

（出所：古賀 勇）

[画像のクリックで拡大表示]

　SPFレコードであれば、バージョン、判定基準となる「メカニズム」、処理方法を定義する「クオリファイヤー」などを記述する。DMARCレコードであればバージョンのほか、認証に失敗した際に受信者に求めるアクションを定義する「ポリシー」や、メールの認証結果を示す「リポート」の送信先などを記述する。

　しかし、いざ現場に実装するとなると、「設定を失敗しないだろうか」などと不安に思うIT管理者も多いかもしれない。つまずきやすいケースを知らなければ、何が起こるか分からず不安になるのも当然だ。

　そこで、メールセキュリティーのクラウドサービスを運用する現場から、送信ドメイン認証の導入や運用でよく見かける「つまずきポイント」を紹介する。ポイントを知っておけば、注意しておきたい勘所が分かる。不安を払拭できるはずだ。

　送信ドメイン認証の運用における代表的なつまずきポイントは3つある。（1）書式を誤る、（2）メールマガジンやメーリングリストを運用している、（3）導入順にこだわりすぎる――である。以下で順に見ていこう。

つまずきポイント（1）書式を誤る

（1）の「書式を誤る」は、最も多く見られるつまずきポイントだ。レコードの書式を誤ると、せっかく設定したはずの送信ドメイン認証が機能しない。

　書式の誤りは、単純な記述ミスと、設定内容が仕様の規格外になってしまうミスに大別される。前者の記述ミスは、例えばSPFでメールサーバーのIPアドレスを指定する記述などで発生する。

IPアドレスを指定する記述で書き間違う

　SPFでIPv4アドレスを指定する場合、本来はメカニズムの部分に「ip4」と記述する。ところが、「ipv4」と記述してしまいやすい。この記述ミスは当社のメールサービスでも多数観測している。IPアドレスの前に不要なスペースを設けてしまう例もよく見られる。

SPFにおける記述ミスの例。IPアドレスのバージョンの記載を誤ったり、余計な空白を挿入してしまったりしやすい

（出所：古賀 勇）

[画像のクリックで拡大表示]

　こうした記述ミスがあれば正しく認証できない。送信ドメイン認証のレコードを設定した後は、他のサービスにメールを送信してみるなどして、正しく認証されているかを必ず確認しておきたい。

DNSの参照回数が多すぎるとエラーに

　後者の規格外になってしまうミスとは、記述ミスはないものの、記述した内容が送信ドメイン認証の規格に外れてエラーを起こしてしまうケースだ。こちらも散見される。

　例えばSPFレコードであれば、メカニズムの記述に注意したい。メカニズムには「include」のように他ドメインのSPFレコードを参照するものがある。includeであれば、別組織「spf.example.com」のSPFレコードを参照して認証するといった具合だ。includeのほかにも「a」「exists」「mx」「ptr」「redirect」というメカニズムがある。

　これらのメカニズムは認証にDNSを用いるが、そのDNSを参照する回数は、SPFの仕様で最大10回に定められている（RFC7208、4.6.4. DNS Lookup Limits）。これはDNSの参照が増えてDoS（サービス妨害）攻撃になってしまうのを防ぐためだ（RFC7208、11.1. Processing Limits）。

SPFによる認証の規格外になってしまうミスの例。DNSを参照するメカニズムを正しく記述していても、参照回数が10回を超えるとエラーとなる

（出所：古賀 勇）

[画像のクリックで拡大表示]

　自社の管理範囲でDNSの参照が10回以内に収まっていても安心できない。例えばincludeした先のDNSを管理する組織が、SPFレコードをさらに追加している可能性がある。自社だけではコントロールできないため要注意だ。こうした点を踏まえればSPFレコードは、DNSを参照しない「ip4」や「ip6」のメカニズムをできるだけ利用し、シンプルに管理することに努めたい。

　もっとも、クラウドサービスを利用する企業では、クラウドサービスの仕様でinclude に代表されるDNSを参照するメカニズムを指定せざるを得ない場合がある。このような場合は、最大でも8回の参照にとどめておきたい。運用開始後にDNSの参照回数が増えてしまっても、慌てずに対応できる。こうした備えによって送信ドメイン認証を適切に運用できる。

　書式を誤るつまずきは、運用を開始した後も引き続き注意したい。当初は正しく設定していても、SPFやDMARCのレコードを編集した際に書き間違えてしまうケースがあるからだ。運用担当者の交代があり、引き継いだ担当者がうっかりSPFレコードを新たに追加してしまい、規格から外れてしまうケースも考えられる。

　こうした状況をいち早く察知する上ではDMARCリポートが役立つ。リポートを受信し、エラーが起こっていないか、起こっている場合は何が原因かを日々確認しておくことが肝要だ。