SPFの「10回制限」とは？超過の原因と、ルックアップを減らす方法
SPFで最も多いトラブルのひとつが、DNSルックアップの10回制限です。数え方と、超えたときの対処をまとめます。
公開: 2026年11月13日
10回制限とは何か
SPFの仕様（RFC 7208）は、受信側がSPFを評価するときに行うDNSの問い合わせを、1回の評価につき最大10回までに制限しています。攻撃者が、非常に多くのDNS問い合わせを発生させるSPFレコードを使って、受信サーバーに負荷をかけることを防ぐための決まりです。
この上限を超えると、SPFの結果は permerror（恒久的なエラー）になり、認証は失敗として扱われます。SPFそのものが壊れた状態になるため、DKIMが有効でなければ、DMARCも通りません。正規のメールが迷惑メールになったり、拒否されたりする原因になります。
何が「1回」に数えられるのか
数えるのは、DNSの問い合わせを必要とする機構（メカニズム）と修飾子です。
| 数える | 数えない |
|---|---|
include、a、mx、ptr、exists、redirect | ip4、ip6、all |
注意すべきは、includeの先にあるSPFレコードの中身も、すべて合算される点です。自分のレコードにはincludeが3つしか書いていなくても、その先のレコードがさらにincludeやmxを含んでいれば、その分も加わります。また、mxは1回と数えますが、MXが指す各ホスト名のアドレスを引く処理にも、別枠の上限（1つのmxにつき10件まで）があります。
もう一つ、存在しない名前を指す参照（void lookup）が2件を超えると、permerrorとして扱う実装があります（仕様上の推奨）。使っていないサービスのincludeを残したままにすると、この制限にも触れやすくなります。
超えてしまう典型的な原因
- メール配信サービス、問い合わせ管理、請求書システム、CRM、チャットツールなどを導入するたびに、
includeを追加してきた。 - Google WorkspaceやMicrosoft 365などの大手サービスの
includeが、内部で複数の参照を持っていて、1つで複数回分を消費している。 - 解約したサービスの
includeが残っている。 - 古い
mxやa、ptrを、念のため残している。ptrは仕様でも非推奨とされています。
ルックアップを減らす方法
1. 使っていないものを消す
最初にやるべきことです。解約したサービス、実際には使っていない送信元を洗い出し、includeを削除します。これだけで、10回以内に収まることが少なくありません。
2. ptr・不要なmx・aをやめる
自社のメールサーバーのアドレスが固定なら、mxやaを、ip4やip6の直接指定に置き換えられます。ip4はDNS問い合わせを発生させません。ただし、IPアドレスが変わったときに自分で書き換える必要があります。
3. 送信目的ごとにサブドメインを分ける
社員が使う日常のメールはexample.co.jp、メルマガや通知メールはmail.example.co.jpのように、送信目的ごとにサブドメインを分けます。SPFはドメインごとに評価されるため、それぞれが10回の枠を持てます。DMARCの整合性の面でも、役割ごとの管理がしやすくなります。
4. SPFフラット化を検討する（注意つき）
include先のIPアドレスを、あらかじめ展開してip4で並べる方法を「フラット化」と呼びます。ルックアップ数は大きく減りますが、サービス側がIPアドレスを変更しても、こちらのレコードは自動では更新されません。古いIPのまま放置すると、正規のメールが失敗します。自動で追従するフラット化サービスを使うか、定期的に手動で更新する運用が必要です。
レコードの長さにも注意
SPFレコードはTXTレコードに置きます。1つの文字列は255文字までなので、長くなる場合は文字列を分割して登録します。レコード全体が長くなり過ぎると、DNS応答がUDPの標準サイズ（512バイト）を超え、環境によっては取得に失敗することもあります。ルックアップ数だけでなく、長さも定期的に確認してください。
確認と運用のコツ
- 変更のたびに、ルックアップ数を数え直す。DMARC・なりすまし対策チェックは、現在のルックアップ数と上限（10）を表示し、超過や接近を警告します。
- 新しい送信サービスを導入する前に、ルックアップの余裕があるかを確認する。
- SPFレコードは、ドメインにつき1つだけ。複数あると、それだけで無効になります。
- 送信元の管理台帳（どのサービスが、どの目的で、どのドメインから送るか）を作っておくと、整理が楽になります。
よくある質問
ルックアップ数が10回ちょうどなら、問題ありませんか？
10回までは許容されますが、余裕がありません。送信サービスを1つ追加しただけで、超えてしまいます。普段から、7〜8回程度に収めておくと安心です。
SPFを-allにするか~allにするか、迷っています。
-allは、許可していない送信元を失敗とするもので、より厳格です。~allは、疑わしいものとして扱う、ゆるやかな指定です。DMARCを併用する場合は、どちらでも運用できます。送信元の管理が整理できているなら、-allが推奨されます。
includeを減らせない場合は、どうしたらよいですか？
メールの用途ごとに、サブドメインを分ける方法が最も安全です。それでも難しい場合に、フラット化を検討しますが、送信サービス側のIPアドレスの変更に、追従する運用が必要になります。