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

2026-03-03T00:00:00+00:00

</div>

転載元</strong>
この記事は Zenn</a> に掲載した記事の転載です。</p> </div> </div> </p>

Table of Contents</summary> </details>
はじめに</h2>
「ある日突然、自組織からのメールが取引先に届かなくなった」——そんな事態が、メール配信サービスを複数利用している組織で実際に起こり得ます。原因は、SPF（Sender Policy Framework）のDNSルックアップ上限です。</p>
外部のメール配信サービスを導入するたびにSPFレコードへ include</code> を追加していくと、気づかないうちに上限へ近づきます。しかも、上限超過のトリガーは自組織の操作ではなく、外部サービス側の設定変更かもしれません。</p>
本記事では、SPFのDNSルックアップ上限の仕組みを解説し、上限超過のリスクと対策を整理します。</p>
SPFの仕組みとDNSルックアップ上限</h2> SPFは、メールの送信元ドメインが「どのサーバーからの送信を許可しているか」をDNSのTXTレコードで宣言する仕組みです。受信側メールサーバーは、送信元IPアドレスがSPFレコードに含まれているかを検証し、正当な送信元かどうかを判断します。</p> SPFレコードの例を示します。</p> v=spf1 ip4:192.0.2.0/24 include:spf.example.com ~all</span></span></code></pre> この例では、192.0.2.0/24</code> のIPレンジからの送信と、spf.example.com</code> が許可する送信元を正当とみなします。</p> SPFの検証は受信側メールサーバーで行われます。メールを受け取ったサーバーが送信元ドメインのSPFレコードをDNSに問い合わせ、送信元IPが許可されているかを確認します。この検証過程でDNSルックアップが発生しますが、RFC 7208（Section 4.6.4）により、1回のSPF検証で実行できるDNSルックアップは最大10回と制限されています。この制限は、SPF検証によるDNSサーバーへの負荷を防ぐために設けられたものです。</p> すべてのメカニズムがDNSルックアップを消費するわけではありません。消費するメカニズムとしないメカニズムを表にまとめます。</p> メカニズム / 修飾子</th> DNSルックアップ</th></tr></thead> ip4</code> / ip6</code></td> 0回（IP直接指定のためDNS不要）</td></tr> a</code></td> 1回</td></tr> mx</code></td> 1回（＋MXレコードが指すAレコードの解決）</td></tr> include</code></td> 1回＋参照先のSPFレコード内のルックアップ</td></tr> redirect</code></td> 1回</td></tr> exists</code></td> 1回</td></tr> </tbody></table> 重要なのは include</code> の挙動です。include</code> は参照先のSPFレコードをさらに評価するため、参照先に include</code> や a</code> が含まれていれば、それらも合算されます。つまり、1つの include</code> が実際には複数回のルックアップを消費する場合があります。</p> includeの入れ子で上限に近づく実例</h2> 架空の組織 example.or.jp</code> を例に考えます。この組織では業務メールに加えて、メールマガジン配信に3つの外部サービスを利用しています。SPFレコードは以下のようになっています。</p> 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</span></span></code></pre> 各エントリのDNSルックアップ数を確認します。</p> エントリ</th> DNSルックアップ</th></tr></thead> ip4:192.0.2.0/29</code></td> 0回（IP直接指定）</td></tr> ip4:198.51.100.1</code></td> 0回（IP直接指定）</td></tr> include:spf.mail-a.example</code></td> 1回</td></tr> include:spf.mail-b.example</code></td> 1回＋内部で3回 = 4回</td></tr> include:spf.mail-c.example</code></td> 1回</td></tr> include:spf.bizmail.example</code></td> 1回</td></tr> 合計</strong></td> 7回 / 上限10回</strong></td></tr> </tbody></table> 一見すると余裕がありそうですが、問題は spf.mail-b.example</code> の内部構造です。このSPFレコードは以下のようになっています。</p> v=spf1 exists:%{i}.spf.mail-b1.example exists:%{i}.spf.mail-b2.example include:spf.mail-b3.example ~all</span></span></code></pre> include</code> 1つで4回のルックアップを消費しています。そして、この内訳は外部サービス側の設定に依存しています。</p> ここに大きなリスクがあります。外部サービスがインフラ変更に伴いSPFレコードへ include</code> や a</code> を追加すれば、自組織が何も変更していなくてもルックアップ数が増加します。たとえば spf.mail-b.example</code> が内部で1つ include</code> を追加するだけで、合計は8回になり、上限までわずか2回です。さらに別のサービスも同様の変更をすれば、上限を超えてしまいます。</p> 上限を超えるとどうなるか</h2> SPFのルックアップ数が10回を超えると、SPFの検証結果は permerror</code>（恒久的エラー）になります。これは「SPFレコードが壊れている」とみなされる状態です。</p> permerror</code> が発生すると、受信側メールサーバーの設定に応じて以下のいずれかが起こります。</p> メールが拒否される（バウンス）</li> 迷惑メールフォルダに振り分けられる</li> DMARCのSPF判定がfailとなり、DMARCポリシー次第でメールが拒否される</li> </ul> 特に厄介なのは、この問題が自組織側からは気づきにくい点です。送信自体は正常に行われ、送信者にはエラーが返らない場合もあります。受信側で静かにスパム判定されるため、「最近メールの返信が来ない」「メルマガの開封率が急落した」といった間接的な兆候で初めて気づくことになります。</p> 自分のドメインのルックアップ数を確認する方法</h2> dig</code> コマンドでSPFレコードの内容を確認できます。</p> dig</span> +short TXT example.or.jp</span> |</span> grep</span> spf</span></span></code></pre> 表示されたSPFレコードに含まれる include</code> 先も再帰的に確認する必要があります。</p> dig</span> +short TXT spf.mail-b.example</span></span></code></pre> 手動での再帰的な確認は手間がかかるため、オンラインツールの利用も有効です。</p> MXToolbox SPF Record Lookup</strong> — SPFレコードの内容とDNSルックアップ数を自動計算してくれる</li> dmarcian SPF Surveyor</strong> — SPFレコードの構造をツリー表示で可視化できる</li> </ul> これらのツールにドメイン名を入力するだけで、現在のルックアップ数と上限までの余裕を確認できます。定期的にチェックしておくことをお勧めします。</p> 対策</h2> SPFルックアップ上限の問題に対して、短期的な対策と中長期的な対策があります。</p> まず短期的な対策として、メール送信経路を棚卸しします。SPFレコードに登録されている include</code> やIPアドレスが、現在も使われているかを確認します。利用を終了したサービスの include</code> が残っていると、ルックアップ数を無駄に消費するだけでなく、そのサービスのIPレンジが自ドメインの正当な送信元として許可されたままになります。これはなりすましに悪用されるリスクでもあります。</p> 次に、メール配信サービスの統合を検討します。メルマガ配信に複数のサービスを併用している場合、1つに統合すれば include</code> の数を減らせます。配信実績の分析も一元化でき、コスト管理も簡素化されます。</p> これらの根本対策とは別に、技術的な回避策も存在します^{1</a></sup>。ただし運用上の注意点があるため、まずは送信経路の整理を優先すべきです。</p>} 最後に、中長期的な対策としてDMARCポリシーの段階的強化があります。DMARCはSPFとDKIMの認証結果に基づいて、認証失敗時のメール処理方針を宣言する仕組みです。ポリシーは以下の順で強化します。</p> p=none</code>（監視モード）でDMARCレポートを収集し、全送信経路の認証状況を把握する</li> 全経路でSPF・DKIMがpassすることを確認したうえで p=quarantine</code>（隔離）に移行する</li> 一定期間の監視後、問題がなければ p=reject</code>（拒否）に移行する</li> </ol> 送信経路が整理されていれば、この移行は技術的には難しくありません。逆に、送信経路が乱立したままでは各経路の認証状況を把握すること自体が困難であり、DMARC強化は事実上不可能です。</p> まとめ</h2> SPFのDNSルックアップ上限10回は、メール配信サービスを複数利用する組織にとって見落とされがちなリスクです。外部サービスの include</code> は入れ子構造でルックアップ数が膨らみ、しかも外部サービス側の変更で自組織のルックアップ数が増加するという、制御しにくい特性があります。</p> まずは自分のドメインの現在のルックアップ数を確認してみてください。上限に近づいている場合は、不要な include</code> の削除やサービスの統合を検討し、DMARCポリシーの強化と合わせてメール配信の信頼性を確保していくことが重要です。</p> 技術的な回避策としてSPF MacroとSPF flatteningがあります。SPF Macroは exists</code> メカニズムと変数を組み合わせてルックアップ数を抑える手法です。SPF flatteningは include</code> 先のIPアドレスを直接 ip4</code> / ip6</code> で記述してルックアップを削減する手法です。ただしflatteningは参照先のIPが変更されたときに追従が必要なため、自動化ツールなしでの運用は推奨しません。 ↩</a></p> </li> </ol> </section>

Coded Chords - Mail

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