SPFのDNSルックアップ上限10回、あなたの組織は大丈夫？

はじめに

「ある日突然、自組織からのメールが取引先に届かなくなった」——そんな事態が、メール配信サービスを複数利用している組織で実際に起こり得ます。原因は、SPF（Sender Policy Framework）のDNSルックアップ上限です。

外部のメール配信サービスを導入するたびにSPFレコードへ include を追加していくと、気づかないうちに上限へ近づきます。しかも、上限超過のトリガーは自組織の操作ではなく、外部サービス側の設定変更かもしれません。

本記事では、SPFのDNSルックアップ上限の仕組みを解説し、上限超過のリスクと対策を整理します。

SPFの仕組みとDNSルックアップ上限

SPFは、メールの送信元ドメインが「どのサーバーからの送信を許可しているか」をDNSのTXTレコードで宣言する仕組みです。受信側メールサーバーは、送信元IPアドレスがSPFレコードに含まれているかを検証し、正当な送信元かどうかを判断します。

SPFレコードの例を示します。

v=spf1 ip4:192.0.2.0/24 include:spf.example.com ~all

この例では、192.0.2.0/24 のIPレンジからの送信と、spf.example.com が許可する送信元を正当とみなします。

SPFの検証は受信側メールサーバーで行われます。メールを受け取ったサーバーが送信元ドメインのSPFレコードをDNSに問い合わせ、送信元IPが許可されているかを確認します。この検証過程でDNSルックアップが発生しますが、RFC 7208（Section 4.6.4）により、1回のSPF検証で実行できるDNSルックアップは最大10回と制限されています。この制限は、SPF検証によるDNSサーバーへの負荷を防ぐために設けられたものです。

すべてのメカニズムがDNSルックアップを消費するわけではありません。消費するメカニズムとしないメカニズムを表にまとめます。

重要なのは include の挙動です。include は参照先のSPFレコードをさらに評価するため、参照先に include や a が含まれていれば、それらも合算されます。つまり、1つの include が実際には複数回のルックアップを消費する場合があります。

includeの入れ子で上限に近づく実例

架空の組織 example.or.jp を例に考えます。この組織では業務メールに加えて、メールマガジン配信に3つの外部サービスを利用しています。SPFレコードは以下のようになっています。

v=spf1 ip4:192.0.2.0/29 ip4:198.51.100.1 include:spf.mail-a.example include:spf.mail-b.example include:spf.mail-c.example include:spf.bizmail.example ~all

各エントリのDNSルックアップ数を確認します。

一見すると余裕がありそうですが、問題は spf.mail-b.example の内部構造です。このSPFレコードは以下のようになっています。

v=spf1 exists:%{i}.spf.mail-b1.example exists:%{i}.spf.mail-b2.example include:spf.mail-b3.example ~all

include 1つで4回のルックアップを消費しています。そして、この内訳は外部サービス側の設定に依存しています。

ここに大きなリスクがあります。外部サービスがインフラ変更に伴いSPFレコードへ include や a を追加すれば、自組織が何も変更していなくてもルックアップ数が増加します。たとえば spf.mail-b.example が内部で1つ include を追加するだけで、合計は8回になり、上限までわずか2回です。さらに別のサービスも同様の変更をすれば、上限を超えてしまいます。

上限を超えるとどうなるか

SPFのルックアップ数が10回を超えると、SPFの検証結果は permerror（恒久的エラー）になります。これは「SPFレコードが壊れている」とみなされる状態です。

permerror が発生すると、受信側メールサーバーの設定に応じて以下のいずれかが起こります。

• メールが拒否される（バウンス）
• 迷惑メールフォルダに振り分けられる
• DMARCのSPF判定がfailとなり、DMARCポリシー次第でメールが拒否される

特に厄介なのは、この問題が自組織側からは気づきにくい点です。送信自体は正常に行われ、送信者にはエラーが返らない場合もあります。受信側で静かにスパム判定されるため、「最近メールの返信が来ない」「メルマガの開封率が急落した」といった間接的な兆候で初めて気づくことになります。

自分のドメインのルックアップ数を確認する方法

dig コマンドでSPFレコードの内容を確認できます。

dig +short TXT example.or.jp | grep spf

表示されたSPFレコードに含まれる include 先も再帰的に確認する必要があります。

dig +short TXT spf.mail-b.example

手動での再帰的な確認は手間がかかるため、オンラインツールの利用も有効です。

• MXToolbox SPF Record Lookup — SPFレコードの内容とDNSルックアップ数を自動計算してくれる
• dmarcian SPF Surveyor — SPFレコードの構造をツリー表示で可視化できる

これらのツールにドメイン名を入力するだけで、現在のルックアップ数と上限までの余裕を確認できます。定期的にチェックしておくことをお勧めします。

対策

SPFルックアップ上限の問題に対して、短期的な対策と中長期的な対策があります。

まず短期的な対策として、メール送信経路を棚卸しします。SPFレコードに登録されている include やIPアドレスが、現在も使われているかを確認します。利用を終了したサービスの include が残っていると、ルックアップ数を無駄に消費するだけでなく、そのサービスのIPレンジが自ドメインの正当な送信元として許可されたままになります。これはなりすましに悪用されるリスクでもあります。

次に、メール配信サービスの統合を検討します。メルマガ配信に複数のサービスを併用している場合、1つに統合すれば include の数を減らせます。配信実績の分析も一元化でき、コスト管理も簡素化されます。

これらの根本対策とは別に、技術的な回避策も存在します¹。ただし運用上の注意点があるため、まずは送信経路の整理を優先すべきです。

最後に、中長期的な対策としてDMARCポリシーの段階的強化があります。DMARCはSPFとDKIMの認証結果に基づいて、認証失敗時のメール処理方針を宣言する仕組みです。ポリシーは以下の順で強化します。

1. p=none（監視モード）でDMARCレポートを収集し、全送信経路の認証状況を把握する
2. 全経路でSPF・DKIMがpassすることを確認したうえで p=quarantine（隔離）に移行する
3. 一定期間の監視後、問題がなければ p=reject（拒否）に移行する

送信経路が整理されていれば、この移行は技術的には難しくありません。逆に、送信経路が乱立したままでは各経路の認証状況を把握すること自体が困難であり、DMARC強化は事実上不可能です。

まとめ

SPFのDNSルックアップ上限10回は、メール配信サービスを複数利用する組織にとって見落とされがちなリスクです。外部サービスの include は入れ子構造でルックアップ数が膨らみ、しかも外部サービス側の変更で自組織のルックアップ数が増加するという、制御しにくい特性があります。

まずは自分のドメインの現在のルックアップ数を確認してみてください。上限に近づいている場合は、不要な include の削除やサービスの統合を検討し、DMARCポリシーの強化と合わせてメール配信の信頼性を確保していくことが重要です。