【ITニュース解説】My SPF checker said GitHub was at 8 of 10 DNS lookups. The real number is 10.

メールのセキュリティは、インターネットを利用したコミュニケーションにおいて非常に重要だ。その中でも、メールの「なりすまし」を防ぐための重要な技術の一つに「SPF（Sender Policy Framework）」がある。SPFは、送信されてきたメールが本当にそのドメインの正規のサーバーから送られたものなのかを確認するための仕組みで、ドメインのDNSレコードに、メール送信を許可するサーバーの情報を記述しておくことで機能する。

このSPFには、重要なルールがある。それは、SPFレコードを評価する際に発生する「DNSルックアップ」の回数が、RFCというインターネットの技術標準で定められた文書によって、最大10回までと厳しく制限されているということだ。この10回という制限を超えてしまうと、「PermError（パーマエラー）」という結果になり、そのメールはSPF認証に失敗する。SPF認証が失敗すると、受信側ではそのメールを疑わしいものとして扱う可能性が高まり、迷惑メールと判断されたり、最悪の場合、受信者に届かなかったりすることがある。

ここで特に重要なのが「評価」という言葉の意味だ。多くの人は、自分のドメインのSPFレコードに記述されている内容だけを数えれば良いと考えがちだが、そうではない。この10回という制限は、自分のドメインのSPFレコードに書かれている情報だけでなく、そのレコードが「include:」という記述で他のドメインのSPFレコードを参照している場合、その参照先のドメインのSPFレコードの内容もすべて評価の対象となり、さらにその参照先のレコードが別のドメインを「include:」していれば、それもまた評価の対象となる。このように、参照を辿って発生する全てのDNSルックアップの合計が10回以内である必要があるのだ。

あるツール開発者が、自身の作成したSPFチェックツールで、人気のあるGitHubのSPFレコードをチェックした際、初期のバージョンでは「8/10」という結果を表示していた。これは、GitHubのSPFレコードに直接記述されている「include:」の数が8つだったためだ。開発者はこの数字を見て、まだ余裕があると考えていた。しかし、これは間違いだった。

GitHubのSPFレコードは、以下のような形式で多くのサービスを参照している。 v=spf1 ip4:… include:spf.protection.outlook.com include:_netblocks.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:… ~all

このレコードを直接見ると、「include:」が8つあるように見える。しかし、真のルックアップ数は「10」だった。なぜこのような違いが生まれたのだろうか。それは、前述した「評価」の概念を見落としていたからだ。

GitHubのSPFレコードに含まれる8つの「include:」のうち、「_spf.salesforce.com」と「sendgrid.net」の2つが、さらにDNSルックアップを発生させるメカニズムを含んでいた。具体的には、「_spf.salesforce.com」のSPFレコードの中には「exists:%{i}._spf.mta.salesforce.com」という記述が含まれていた。この「exists:」というメカニズムは、それ自体がDNSルックアップを発生させる。また、「sendgrid.net」のSPFレコードの中には、「include:ab.sendgrid.net」という、さらに別のドメインを参照する「include:」が含まれていた。

このように、自分のドメインのSPFレコードの中に含まれる「include:」が、さらに別のDNSルックアップを発生させる要素を隠し持っている場合がある。GitHubの事例では、直接記述された8つの「include:」に加えて、Salesforceのレコード内の「exists:」で1回、SendGridのレコード内のネストされた「include:」で1回、合計で2回の追加ルックアップが発生し、結果的に「8 + 1 + 1 = 10」というギリギリの数字になっていたのだ。

DNSルックアップを発生させるSPFのメカニズムには、主に「include:」、「a」、「mx」、「ptr」、「exists:」、「redirect=」（ただし、レコード内に「all」がない場合のみ）がある。一方、「ip4:」、「ip6:」、「all」、「exp=」といったメカニズムは、それ自体ではDNSルックアップを発生させない。

したがって、SPFレコードの正確なDNSルックアップ数を数えるには、単に自分のドメインのレコードを見るだけでは不十分で、まるで木を一本一本辿るように、参照されているすべてのドメインのSPFレコードを再帰的に評価し、その中にあるルックアップを発生させるメカニズムをすべて合計する必要がある。これは「DNSツリーをウォークする」と表現されることがある。

この再帰的な評価の際には、いくつかの詳細なルールも考慮する必要がある。例えば、もし参照先のドメインのSPFレコードがループしている（AがBを含み、BがAを含む、といった形で自分自身を直接的または間接的に参照している）場合、それはエラーとなる。ただし、異なるパスで同じドメインが参照されることは許可され、その場合はそれぞれ独立したルックアップとしてカウントされる。また、もし「include:」で参照しているドメインにSPFレコードが存在しない場合、それも「PermError」となるため、使わなくなったサービスを参照し続けることは危険だ。一つのドメインに複数のSPFレコードが存在することも「PermError」の原因となる。さらに、「redirect=」メカニズムは、もしそのSPFレコード内に「all」メカニズムが存在する場合は無視されるというルールもある。

これらの複雑なルールをすべて正しく理解し、評価に反映させることで、初めて正確なSPFのDNSルックアップ数を把握できる。

もし自分のドメインのSPFレコードのDNSルックアップ数が9回や10回といった上限に近い状態であれば、対策を検討する必要がある。 まず最も簡単な方法は、すでに使用していないメール送信サービスをSPFレコードから削除することだ。特に古いマーケティングプラットフォームなどは、多くのルックアップを消費していることが多い。 次に、大量のメールを送信するサービス（ニュースレターなど）がある場合は、それらをメインドメインではなく「news.example.com」のようなサブドメインから送信するように変更し、サブドメイン専用のSPFレコードを設定する方法がある。これにより、メインドメインのSPFルックアップ制限を消費せずに、サブドメイン自身の10回の制限を使用できる。DMARCという別のメール認証技術では、サブドメインからのメールもメインドメインのメールとして許容される「relaxed alignment」という設定があるため、この方法は有効だ。 もう一つ、「フラット化」という方法もある。これは、「include:」で参照しているドメインのSPFレコードが解決するIPアドレス範囲を、直接自分のSPFレコードに記述する方法だ。これにより「include:」によるルックアップを減らせる。しかし、この方法は、参照先のベンダーがIPアドレスを追加したり変更したりした場合に、自分のDNSレコードも手動で更新しなければならなくなるという欠点がある。もし更新を怠ると、正規のメールがSPF認証に失敗する原因となるため、フラット化を行う場合は、定期的にベンダーのIPアドレス範囲を確認し、自動的にDNSレコードを更新する仕組みが必要となる。

この事例から学べるのは、ツールの表示する数字がたとえ「ほとんど正しい」としても、そのわずかな違いが大きな問題を引き起こす可能性があるということだ。特に、制限値に近い状況では、正確な評価が不可欠となる。ツールが提供する情報は、可能な限り正確であるべきで、もし近似値であるならば、その近似性が結果の数字に反映されている必要がある。