SPFのDNSルックアップとは？10回制限の仕組みと超過時の対処法を徹底解説

「SPFを設定しているはずなのに、Gmail宛のメールが迷惑メール扱いになる」「DMARCレポートを見たら、SPF PermError: too many DNS lookups という見慣れないエラーが頻発している」。複数のクラウドサービスやメール配信ツールを併用している企業で、こうしたトラブルが急増しています。

その原因のほとんどは、SPFレコードの構文ミスではありません。SPFには「DNSルックアップは10回まで」という、見落とされがちな仕様上の上限が存在しており、これを超えた瞬間にSPF認証は永続エラー（PermError）として扱われ、メールはなりすましと同じ扱いを受けてしまいます。

しかも厄介なことに、自社で記述したのは1〜2行のincludeだけでも、参照先がさらに参照を重ねていく「再帰的なルックアップ」によって、知らないうちに10回を超過しているケースがほとんどです。Google WorkspaceとMicrosoft 365を併用し、そこにマーケティングオートメーションツールを追加した時点で、すでに上限に達していたという事例も珍しくありません。

本記事では、SPFのDNSルックアップの仕組み、10回制限の根拠と背景、自社ドメインの現状を確認する具体的な方法、そして超過してしまった場合の対処法を、開発者・インフラ担当者の視点で徹底的に解説します。SPFフラット化やマクロ、サブドメイン分割といった手法のメリット・デメリットを比較し、最終的に「メール配信基盤側で解決する」という根本対策にも触れていきます。

SPFのDNSルックアップとは

SPF（Sender Policy Framework）は、メールの送信元IPアドレスがそのドメインから送信する正当なサーバーであることを、DNSを介して受信側に証明する送信ドメイン認証技術です。送信側ドメインのDNSに「送信を許可するIPアドレス」をTXTレコード（SPFレコード）として公開し、受信側のメールサーバーがそれを照合する仕組みになっています。

このとき、SPFレコードの中身を評価する過程で受信側メールサーバーが行うDNSへの問い合わせを、「DNSルックアップ」と呼びます。

DNSルックアップが発生するメカニズム

SPFレコードは、いくつかの「メカニズム（mechanism）」と呼ばれる要素で構成されます。このうち、評価のためにDNSへの問い合わせが必要となるメカニズムが存在し、それらが10回制限のカウント対象となります。

特に注意すべきはincludeの再帰性です。自社のSPFレコードに include:_spf.google.com と1行書いただけでも、_spf.google.com の中身がさらに別ドメインを include していれば、その先まで芋づる式にカウントされます。

SPFの基本的な評価フロー

受信側メールサーバーがSPF認証を行うときの流れは、おおよそ次の通りです。

1. 受信メールのMAIL FROM（エンベロープFrom）からドメイン名を取得する
2. そのドメインのDNSにTXTレコードを問い合わせ、SPFレコードを取得する（この最初の問い合わせはカウント対象外）
3. SPFレコードを左から順に評価し、includeやa、mxなどDNSルックアップを要するメカニズムに遭遇するたびに、追加のDNS問い合わせを実行する
4. 送信元IPアドレスがマッチするメカニズムが見つかればPass、見つからずに評価が終わった場合はFailやSoftFailなどの結果を返す
5. 評価の途中でDNSルックアップ回数が10回を超えると、その時点で評価を打ち切り、PermErrorを返す

このプロセスは受信側のメールサーバー側で実行されるため、送信側からは「いま自分のドメインのSPFが何回のルックアップを消費しているのか」を能動的に確認しなければ気付けないのが、見落とされやすい理由です。

SPFのDNSルックアップ10回制限の根拠と背景

SPFのDNSルックアップに「10回まで」という上限が設けられているのは、現行のSPF仕様であるRFC 7208に明文化されたルールに基づきます。仕様文書を読み解くと、なぜこの制限が設けられているのか、なぜ「10回」という具体的な数値なのかが見えてきます。

RFC 7208に明記された制限

SPFの仕様書「RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1」のSection 4.6.4「DNS Lookup Limits」には、次のように記述されています。

SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS.

つまり、「SPFの評価中に発生するDNSルックアップの総数を10回までに制限しなければならない」ことが、仕様として明確に義務付けられているのです。これは推奨ではなくMUST、つまり強制要件です。

カウント対象となるメカニズムはinclude、a、mx、exists、ptr、redirect修飾子であり、ip4、ip6、allはカウントされません。

Void Lookup（空ルックアップ）の2回制限

10回制限と並んで重要なのが、Void Lookup（空ルックアップ）の上限は2回というルールです。Void Lookupとは、DNSへの問い合わせ結果が「NXDOMAIN（該当ドメインなし）」または「空の応答」だった場合を指します。

RFC 7208 Section 4.6.4 では、評価中にこのVoid Lookupが2回を超えた場合も、PermErrorとして扱うよう規定されています。

実務上は、過去に使っていたメール配信サービスのドメインをincludeに残したままサービス側のDNSが消えていた、といったケースで突然このエラーが顕在化します。

なぜ「10回」という制限があるのか

制限の理由は、RFC 7208 Section 11.1「Processing Limits」に詳しく書かれています。要約すると、次の2点に集約されます。

DNSサーバーへの負荷集中の防止

includeの再帰参照が無制限であれば、悪意あるドメインや設定ミスによって、1通のメール認証だけで何百回ものDNS問い合わせが連鎖的に発生する可能性があります。世界中で1日数十億通単位で送受信されるメールごとにこれが起これば、DNSインフラ全体が深刻な遅延や障害を起こしかねません。

DoS（サービス拒否）攻撃の悪用防止

攻撃者がSPFレコードを意図的に深くネストさせたドメインを用意し、そのドメイン宛にメールを大量送信させることで、受信側DNSサーバーや権威DNSサーバーに過負荷を仕掛ける―いわゆる「SPFを悪用したDNS増幅攻撃」を防ぐ目的があります。

つまり10回という値は、メール認証としての実用性を担保しつつ、システム全体の安全性を守るための妥協点として設定された数字なのです。

「2026年現在」も増え続ける超過リスク

RFC 7208が公開された2014年当時、10回という制限は十分に余裕のある数字でした。しかし2026年現在、状況は大きく変わっています。

クラウドメールサービス（Google Workspace、Microsoft 365）、メール配信API、マーケティングオートメーション、顧客サポートツール、人事系SaaS、決済通知サービス。1社の送信ドメインから出るメールの種類は劇的に増え、それぞれが自社のincludeを要求します。シェアリングエコノミー的に外部サービスを組み合わせるほど、SPFレコードは肥大化していくのです。

実際、SPFレコードのチェックツール提供事業者の調査では、グローバルで約25〜30%のドメインがすでに10回制限に抵触している、あるいは抵触する寸前の状態にあると報告されています。

SPFのルックアップ制限を超えるとどうなるのか

10回制限を超えるとどうなるのか。結論を先に述べると、そのドメインから送信される全メールのSPF認証が永続的に失敗（PermError）として扱われ、最悪の場合は受信側で拒否、もしくは迷惑メールフォルダ送りになります。

PermErrorの実害

PermErrorが返ると、受信側メールサーバーは「このドメインのSPF設定は壊れている」と判断します。具体的な影響は以下の通りです。

メールの不達・迷惑メール判定

Gmail、Outlook、Yahoo!メールなど主要ISPは、SPFの結果を到達判定の重要なシグナルとして利用しています。PermErrorはFailと同等以上に厳しく扱われ、本来なら届くべき業務メール・通知メールが受信トレイに届かなくなります。

DMARCの認証失敗

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFまたはDKIMのどちらかがPassかつドメイン整合（alignment）が取れていれば成立します。SPFがPermErrorになればSPF側でのDMARCパスは不可能になり、DKIMだけに頼る不安定な状態になります。

ドメインレピュテーションの低下

認証失敗が継続すると、送信ドメインの評判スコアがじわじわと下がります。一度落ちた評判を回復するには、数週間から数か月のクリーンな送信実績が必要になることもあります。

Gmailガイドライン違反のリスク

2024年2月にGmailが強化したメール送信者ガイドラインでは、1日5,000通以上を送信するバルクセンダーに対してSPF・DKIM・DMARCの正しい設定を要求しています。Microsoft（Outlook）も送信者要件の厳格化を継続的に進めており、PermErrorを放置することはガイドライン違反に直結します。

「届いているように見える」罠

特に注意すべきは、PermErrorが発生していても一部のメールは普通に届いてしまうという現実です。受信側メールサーバーの実装やポリシーによって、SPF PermErrorの扱いには温度差があるためです。

つまり「自社は問題ない」と思っていても、実際にはGmail宛の到達率だけが下がっていたり、特定の取引先（厳格なフィルタを使うエンタープライズ企業）にのみメールが届かなくなっていたりするケースがよくあります。DMARCレポートを定期的に確認しない限り、この異常には気付けません。

放置していると、ある日突然「重要な顧客への通知メールが2週間届いていなかった」といった事態に発展します。

SPFのDNSルックアップ回数を確認する方法

自社ドメインのSPFが現在何回のDNSルックアップを消費しているかは、ツールやコマンドで簡単に確認できます。導入前・運用中の両方で、定期的なチェックを習慣にすべきです。

主要なオンラインチェックツール

代表的なツールを3つ紹介します。

MXToolbox SPF Record Lookup

公式サイト：https://mxtoolbox.com/spf.aspx

世界で最も広く使われているメール診断ツールです。 でドメイン名を入力すると、SPFレコードの内容、各メカニズムが何回のDNSルックアップを消費しているか、構文エラーの有無、PermError/Void Lookupのリスクを一覧表示してくれます。英語サイトですが、SPF Record PublishedやSPF Record Deprecated Recordsなどのチェック項目は直感的に理解できます。

Dmarcian SPF Surveyor

公式サイト：https://dmarcian.com/spf-survey/

で利用できる無料ツール。SPFレコードをツリー構造で可視化してくれるため、「どのincludeが何回消費しているか」を視覚的に追跡できます。ネストの深い構造をデバッグする際に特に有用です。

Kitterman SPF Record Testing Tool

公式サイト：https://www.kitterman.com/spf/validate.html

で利用できる老舗ツール。シンプルな構文チェックとルックアップ回数の確認に向いています。

コマンドラインでの確認

GUIツールに頼らず、digやnslookupで直接DNSを照会する方法もあります。

# Linux/Mac
dig +short TXT example.com

# Windows
nslookup -type=TXT example.com

ただし、digコマンドではincludeの再帰的な参照までは自動展開してくれません。すべての参照先を1つずつ手動で辿るのは現実的でないため、ルックアップ回数の正確な計測には専用ツールの利用が圧倒的に効率的です。

確認すべき4つの指標

SPFレコードを診断する際に、最低限チェックしておきたい指標を表にまとめます。

特に「現在は7〜8回でも、新しいクラウドサービスを1つ追加した瞬間に超過する」というケースが頻発するため、7回以下を目標値にしておくと運用上の余裕が生まれます。

ルックアップ上限を超えてしまう典型パターン

実際にSPFのDNSルックアップが10回を超えてしまうのは、どんなケースなのでしょうか。現場でよくあるパターンを具体的に見ていきます。

主要クラウドサービスのルックアップ消費量

代表的なメール送信サービスをincludeした場合に消費されるDNSルックアップ回数の目安を、表にまとめます（2026年時点の参考値。各サービスの仕様変更により増減します）。

たとえば「Google Workspaceで業務メールを送信し、Microsoft 365も併用しており、Amazon SESでサービス通知メール、HubSpotでマーケティングメールを送る」という構成では、それだけで 4 + 3 + 2 + 2 = 11回 となり、すでに上限を超過しています。

よくある超過シナリオ

ここでは4つのシナリオを紹介します。

複数のクラウドメールサービス併用

本社はGoogle Workspace、買収した子会社がMicrosoft 365を使っている。両方を include し、さらにバックアップ系のIPアドレスやセキュリティゲートウェイのレコードを追加した結果、上限を超えるパターン。

MAツール・CRM・サポートツールの積み増し

事業部単位で「うちはこのツールを入れたい」と外部SaaSを次々に契約。それぞれがSPFのincludeを要求するため、気付けば肥大化しているパターン。情報システム部門が把握していないshadow ITも一因。

削除し忘れた過去のサービスのinclude

以前使っていたメール配信サービスを解約したにもかかわらず、SPFレコードから該当のincludeを削除し忘れているパターン。サービス側のドメインが消えていれば、Void Lookupとしてカウントされる二重リスクも。

参照先サービスの仕様変更

自社のSPFは何も変えていないのに、ある日突然PermErrorが発生し始めるケース。これは、include先のクラウドサービスが内部で参照しているSPFを変更し、ルックアップ回数が増えたためです。includeの中身は自社では制御できないという、SPF運用最大のリスクが顕在化したパターン。

SPFのDNSルックアップ上限を回避する5つの対処法

ルックアップ回数が上限に近づいてきた、あるいはすでに超えてしまった場合の対処法を、難易度と効果の観点から5つ紹介します。

不要なincludeを削除する（即効性あり）

最も簡単で効果が高いのが、使っていない外部サービスのincludeを削除することです。

• 現在も契約しているメール送信サービスはどれか
• 過去に使っていて解約済みのサービスのincludeが残っていないか
• 同じサービスを重複してincludeしていないか
• 部署単位で独自に追加されたincludeはないか

これらを棚卸しすると、平均して1〜3回分のルックアップを削減できるケースがほとんどです。SPFレコードに変更を加える前後で、必ず本番送信のテストを行い、認証結果に問題がないことを確認しましょう。

aやmxを直接ip4に置き換える

自社で管理しているメールサーバーをSPFに含めている場合、a:mail.example.comやmxのような記述ではなく、ip4:203.0.113.10のようにIPアドレスを直接記述することで、ルックアップを消費しなくなります。

ただしIPアドレス変更時のメンテナンスコストが発生するため、頻繁にIPが変わる環境では非推奨です。

サブドメインを分けて運用する

ドメインそのものを分割する手法も有効です。たとえばexample.comを1つのSPFで管理するのではなく、用途別に以下のように分けます。

• 業務メール用：example.com（Google WorkspaceのみをSPFに記載）
• マーケティング配信用：marketing.example.com（MAツールのみ）
• システム通知用：notify.example.com（メール配信APIのみ）

各サブドメインのSPFレコードがシンプルになり、ルックアップ回数を大幅に削減できます。ただし、サブドメインごとにDKIM・DMARCの設定や、IPレピュテーションの管理も別個に必要になる点に注意してください。

SPFレコードのフラット化

SPFフラット化（SPF Flattening）とは、includeやa、mxなどのDNSルックアップを伴うメカニズムを、すべてip4/ip6に展開して書き直す手法です。

（フラット化前）
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

（フラット化後）
v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20
       ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14
       ip4:104.47.0.0/17 ~all

ルックアップ回数を0回近くまで削減できる強力な手法ですが、3つの大きな注意点があります。

SPFフラット化サービス・自動更新ツールを使う

手動フラット化の運用負担を解消するため、SPFのフラット化を自動で行うホスティング型サービスを導入する選択肢もあります。代表的なものに、PowerDMARCのPowerSPF、DMARCLYのSafeSPFなどがあります。

これらのサービスは、includeで参照されるサービスのIPアドレスを定期的に監視し、変更があれば自動的にSPFレコードを更新してくれます。SPFのルックアップ回数制限とTXTレコードの文字数制限を同時に解決できるのが利点です。一方で、月額費用が発生する点、外部サービスにSPF管理を依存する点はトレードオフとなります。

5つの対処法を比較表で整理

より根本的な解決策：メール配信基盤の集約

ここまで紹介した対処法は、いずれもSPFレコードそのものを工夫するアプローチです。しかし、もう一段階上のレベルで考えると、「そもそも自社ドメインから送信する経路を集約する」という根本対策があります。

配信経路を集約することのメリット

複数のクラウドメールサービスやSaaSをそれぞれ個別に契約し、SPFにincludeを積み増していくのは、運用負担と認証エラーリスクの両面で限界があります。これに対して、メール配信API・SMTPリレーを提供する専用サービスに送信経路を集約することで、以下のメリットが得られます。

• 自社のSPFレコードに記述するincludeを1つに統合できる
• IPレピュテーション管理を専門事業者に任せられる
• SPF・DKIM・DMARCの設定をワンストップで対応できる
• 送信元IPの変更や追加もサービス側で吸収してくれる
• 配信ログ・バウンス処理を一元管理できる

特に、SaaSやWebサービスを開発する企業にとって、「自社アプリケーションからのトランザクションメール」「マーケティングメール」「業務通知メール」を1つの配信基盤に集約する設計は、SPF問題の根本解決に直結します。

SPFのDNSルックアップ問題を解決するならメール配信システムを活用する

ここまで解説してきたSPFのDNSルックアップ問題は、結局のところ「自社ドメインから送信される経路をどう設計・運用するか」というインフラ全体の問題です。複数のクラウドサービスを併用するのが当たり前になった今、SPFの設定だけで完結させるには限界があります。送信基盤を専門のメール配信システムに集約することで、includeの肥大化を抑えつつ、到達率と運用効率を同時に高められます。

メール配信システムを使うメリット

エンジニア・システム担当者にとって、専用のメール配信システムを使うメリットは、SPFのルックアップ問題の解消だけにとどまりません。送信ドメイン認証・到達率・運用工数のすべてをサービス側に任せられる点が、自社運用に比べた大きな価値となります。

• SPF・DKIM・DMARC対応の標準化
  最新のメール認証技術にサービス側で対応しているため、自社で複雑なDNS設計をする負担が減る
• IPレピュテーション管理の委譲
  送信元IPの評判維持を専門事業者が運用するため、自社で個別IPを管理する必要がない
• 到達率の継続的な向上
  キャリア・ISP別の送信ロジックや配信エンジンのチューニングで、自社運用より高い到達率が期待できる
• API連携・SMTPリレーによる柔軟な統合
  既存システムや業務フローへの組み込みが容易で、開発リソースを節約できる
• エラー管理・ログ管理の自動化
  バウンス処理や送信ログ分析を自動化でき、運用工数を削減できる

特にSPFのincludeを1つに集約できる効果は大きく、自社ドメインのSPFレコードがシンプルになることで、Gmailガイドラインへの準拠と運用負荷の軽減を同時に実現できます。それぞれのニーズに合うサービスを以下で紹介します。

おすすめのメール配信システム「blastengine」

blastengine（ブラストエンジン）は、お客様のシステムとSMTPリレーやAPIで連携することで、トランザクションメールや一斉配信を安定して行えるメール配信サービスです。SPのinclude:spf.besender.jpを1行追加するだけで、自社からの大量メールを高い到達率で配信できる送信基盤を構築できます。

• API連携・SMTPリレー
  既存システムへの組み込みが容易で、複雑なメールサーバー構築が不要
• 99％以上の高いメール到達率
  国内キャリア・ISPへの個別送信ロジックで確実にメールを届ける
• SPF/DKIM/DMARC対応
  最新のメール認証技術に標準対応し、なりすまし・迷惑メール判定を回避
• IPレピュテーション管理
  blastengine側で送信元IPの評判を常に高く維持
• バウンスメール自動対応
  エラーメール管理を自動化し、エンジニアの運用負荷を大幅に削減
• 業界最安クラスの料金
  初期費用無料、月額3,000円〜で大量配信も低コストで実現

複数のクラウドサービスのincludeで肥大化したSPFレコードをスリム化し、Gmailなど主要プロバイダのガイドラインに準拠した送信環境を構築したい企業に最適です。メールアドレス入力のみで無料トライアルが可能ですので、まずは気軽にお試しください。

ブラストエンジン公式サイト：https://blastengine.jp/

おすすめのメール配信システム「ブラストメール」

ブラストメール（blastmail）は、15年連続で導入社数シェアNo.1を獲得している日本最大級のメール配信システムです。27,000社以上の導入実績に裏打ちされた高い到達率と、シンプルな操作画面が支持されており、HTMLメール作成からセグメント配信まで管理画面上で完結できます。マーケティング部門・営業部門の担当者が手動でメールマガジンや一斉配信を運用するシーンに最適です。

• シンプルな管理画面：HTMLメールやテキストメールを直感的に作成でき、専門知識不要
• 迷惑メール判定対策（SPF/DKIM）：送信ドメイン認証に標準対応し、到達率の維持に貢献
• 効果測定：開封率・クリック率・エラーカウントを管理画面で確認可能
• フィルタ配信（セグメント配信）：読者属性や行動履歴で配信対象を絞り込める
• 充実したサポート体制：電話・メール・チャットで導入前から利用中まで手厚くフォロー

低価格と豊富な実績を両立しており、初めてメルマガを運用する企業から大規模配信を行う企業まで、あらゆるニーズに対応しています。

公式サイト：シェア1位のメール配信システム「ブラストメール」

まとめ

SPFのDNSルックアップ10回制限は、複数のクラウドサービスを併用する企業にとって、いつ顕在化してもおかしくないリスクです。記述上は1〜2行のincludeでも、再帰的なルックアップによって気付かないうちに上限を超え、Gmail宛のメールが届かなくなるケースが急増しています。

定期的な棚卸しとチェックツールでの可視化を習慣にしつつ、根本対策としてはメール配信基盤の集約を検討するのが、2026年現在の現実解です。SPFレコードをスリムに保ち、到達率と運用効率を両立させたいエンジニアは、blastengineのようなSMTPリレー・API連携型のメール配信サービスを選択肢に加えてみてください。