SPFのDNS lookup 10回制限を超えたときの整理方法
送信サービスを足すたびにincludeを追加していくと、SPFはDNS参照10回の上限を超えてエラーになります。数え方、超えたときに起きること、不要な記述の見つけ方、整理の順番を設定例つきで説明します。
メール配信サービスや請求書システムを導入するたびに、「SPFにこの1行を追加してください」と案内されます。言われたとおりに include を足していくと、ある日、SPFが静かに壊れます。SPFには受信側がDNSを参照する回数の上限(10回)があり、超えるとSPF全体がエラーになるからです。
何が「1回」に数えられるか
SPFの記述のうち、受信側が追加でDNSを調べる必要があるものが数えられます(RFC 7208 4.6.4)。
| 記述 | 数えるか | 補足 |
|---|---|---|
include: | 数える | include 先の中身もさらに数える(入れ子) |
a mx | 数える | 1つにつき1回 |
ptr | 数える | RFC 7208 でも使わないよう求められている記述 |
exists: | 数える | |
redirect= | 数える | |
ip4: ip6: | 数えない | IPアドレスを直接書くだけ |
all | 数えない |
注意したいのは入れ子です。include:_spf.google.com は1回に見えますが、その先にさらに include があれば、それも合計に入ります。大手のサービスほど中で複数の include を使っていることがあり、3〜4個並べただけで上限に近づくことがあります。
また、参照した先にレコードが無い「空振り」は2回までという別の上限もあります。解約したサービスの include が残っていると、こちらに引っかかることもあります。
超えると何が起きるか
10回を超えると、受信側はSPFの結果を「permerror(恒久的なエラー)」とします。つまり、一覧に入っている正規のサーバーから送ったメールも、SPFでは本物と確認されません。
DMARCは、SPFかDKIMのどちらかがFromのドメインと一致して合格すれば合格です。そのため、DKIMを独自ドメインで署名しているサービスからのメールは届き続け、問題に気づきにくくなります。DKIMの署名が無い送信元があると、そこだけDMARCで不合格になり、p=quarantine や p=reject にした瞬間に届かなくなります。
自分で確認する方法
1. 今のSPFを取り出す
dig +short TXT example.jp | grep spf1
Windowsでは nslookup -type=TXT example.jp を実行し、v=spf1 で始まる行を探します。2行以上あれば、それだけでSPFは無効になっているので、まず1行にまとめます。
2. include の中身をたどる
dig +short TXT _spf.google.com
のように include 先を1つずつ調べ、中にある include・a・mx などを数えていきます。手作業が大変なら、SPFを入力すると参照回数を数えてくれる無料のチェックツールが各社から出ています。複数のツールで結果が同じか確かめると安心です。
3. 一覧表にする
| 記述 | 何のサービスか | 今も使っているか | 参照回数(入れ子込み) |
|---|---|---|---|
| include:_spf.google.com | 社内メール | 使っている | (ツールで確認) |
| include:配信サービスA | メールマガジン | 2年前に解約 | (ツールで確認) |
| mx | 旧サーバーの名残? | 不明 | 1 |
「何のサービスか分からない」行があるのが普通です。担当者や制作会社に確認します。
整理の順番
1. 使っていないサービスを外す
解約した配信サービス、乗り換え前のレンタルサーバー、試用しただけのツール。いちばん効果が大きく、リスクも小さい作業です。
2. 「SPFに書かなくてよい」include を外す
SPFが確認するのは、Fromのアドレスではなく、送信時に使われる「エンベロープの送信者」(Return-Path)のドメインです。配信サービスの多くは、Return-Path にサービス側のドメインを使います。その場合、自社のSPFにそのサービスを書いても、受信側はそもそも自社のSPFを見ません。
このようなサービスは、DMARCの合格をDKIM(独自ドメインでの署名)で取るのが基本です。サービスの案内を確認し、「Return-Path をサービス側のドメインで送っていて、独自ドメインのDKIM署名を設定済み」であれば、自社のSPFから include を外せる可能性があります。外す前に、DMARCの集計レポートでそのサービスからのメールがDKIMで合格していることを確かめてください。
3. a mx ptr を見直す
Webサーバーやメールサーバーから実際には送っていないのに、昔のテンプレートのまま a や mx が入っていることがあります。送っているなら固定のIPアドレスを ip4: で書けば回数を消費しません。ptr は外します。
4. それでも足りなければ、サブドメインに分ける
メールマガジンは news.example.jp、システム通知は info.example.jp のように送信元のドメインを分けると、SPFもドメインごとに別になり、回数の上限も別々に数えられます。DMARCの初期設定(relaxed)では、サブドメインのDKIM署名も親ドメインのFromと一致するとみなされます。
5. 最後の手段として IPアドレスで書く(フラット化)
include の中身を ip4: に展開すると回数は減りますが、サービス側がIPアドレスを変えたときに追随が必要です。自動で更新する仕組みが無いなら、おすすめしません。
整理後の設定例
変更前(例):
v=spf1 a mx include:_spf.google.com include:配信A include:配信B include:請求書C ptr ~all
変更後(例):
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:請求書C -all
例では、解約済みの配信A・Bを外し、自社サーバーを ip4: で書き、ptr を削除しています。末尾を ~all から -all にするのは、DMARCのレポートで正規の送信元がすべて合格しているのを確かめてからにしてください。
よくある誤解
- 「SPFの1行の文字数の上限の話」:違います。数えるのは文字数ではなく、DNSを参照する回数です
- 「エラーなら受信側が無視してくれる」:permerror はSPFの不合格として扱われ、DMARCの判定にも響きます
- 「include を足すたびに案内どおりにしているから正しい」:各サービスは自社の1行しか見ていません。合計の回数を見るのは、ドメインを持っている会社の役目です
Webサイト診断の診断ではこう判定します
なりすましメール対策診断の「SPFの参照回数」(5点)は、include の入れ子を含めてDNS参照を実際に数え、10回以内なら合格、10回を超えたら0点です。参照先の名前解決に失敗した場合は、推測で判定せず「測定できず」とします。あわせて「SPFが1つだけ」(5点。2件以上は無効扱いのため0点)と「SPFの末尾の指定」(-all で5点、~all で4点、?all または指定なしは1点、+all は0点で全体の上限40点)も確認します。
制作会社・保守会社への依頼文の例
件名:SPFレコードの整理(DNS参照10回制限)のお願い
当社ドメイン(example.jp)のSPFが、DNS参照の上限(10回)を
超えている可能性があります。次の対応をお願いします。
1. 現在のSPFに含まれる各記述が、どの送信サービスのものかの一覧化
2. 解約済み・未使用のサービスの記述の削除
3. 独自ドメインのDKIM署名で認証できているサービスについて、
SPFへの記載が必要かどうかの確認
4. 変更後の参照回数の確認(10回以内)と、変更前後のレコードの共有
DMARCの集計レポートで、変更後も正規のメールが合格していることを
確認したうえで作業を完了としてください。
まず参照回数を確認する
SPFの参照回数、重複、末尾の指定が分からない場合は、無料のご相談で確認します。整理と再設定を任せたい場合はなりすましメール対策 設定代行、整理のあとDMARCを強めていくならDMARC段階導入・監視をご覧ください。SPF・DKIM・DMARCの役割の違いはこちらの記事、DMARCを強める前の確認はDMARC p=noneからrejectへ移行する前に確認すること、
よくある質問
10回を超えていても、メールは普通に届いているようです。直す必要はありますか?
あります。DKIMで合格しているメールはDMARCにも合格するため、今は問題が表に出ていないだけかもしれません。DKIMの署名が無い送信元や、署名が壊れる転送経路では、SPFのエラーがそのまま不合格につながります。DMARCを強める前に必ず直してください。
「SPFフラット化」のサービスを使えば解決しますか?
include を IPアドレスの一覧に置き換えて回数を減らす方法で、有効な場合もあります。ただし、送信サービス側がIPアドレスを変えると追随が必要です。自動で追随するサービスを使うか、手作業なら定期的な見直しが前提になります。まずは不要な記述を外す方が先です。
参照資料
- RFC 7208 Sender Policy Framework (SPF)(2026.10.01 確認)
- RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)(2026.10.01 確認)
- Google Workspace 管理者ヘルプ:メール送信者のガイドライン(2026.10.01 確認)