メールの到達率やスパム判定に大きく影響する「SPF（Sender Policy Framework）」ですが、設定を進める中で必ず直面するのがDNSルックアップ回数の制限（10回制限）です。
本記事では、SPFのDNSルックアップ制限の仕組みから、実務での回避方法までを体系的に解説します。
SPFとは何か
SPFとは、送信元のIPアドレスが正当なものかどうかを検証する仕組みです。
受信側サーバーは、送信元ドメインのDNSに登録されたSPFレコードを参照し、許可された送信元かどうかを判断します。
SPFレコード例（ダミー）
v=spf1 include:spf.example-service.com ip4:203.0.113.1 ~allinclude：外部サービスを許可ip4：特定IPを許可~all：それ以外はソフトフェイル
DNSルックアップ制限とは
SPFには仕様上、以下の制限があります。
- DNSルックアップは最大10回まで
この制限を超えると、以下の問題が発生します。
permerror（恒久的エラー）- SPF認証失敗
- メールが迷惑メール扱い、または拒否される可能性
ルックアップが発生する要素
SPFレコード内のすべてがカウント対象ではありません。
以下の指定がDNSルックアップを消費します。
| 要素 | ルックアップ |
|---|---|
| include | 1回 |
| a | 1回 |
| mx | 1回以上 |
| exists | 1回 |
| redirect | 1回 |
※ ip4 / ip6 はルックアップを消費しません
なぜ10回制限があるのか
SPFチェックはメール受信時に毎回実行されます。
もし無制限にDNS問い合わせが発生すると、
- サーバー負荷が増大
- メール処理の遅延
- サービス全体の安定性低下
といった問題が発生するため、仕様として制限されています。
よくある制限超過のパターン
1. includeの多用
v=spf1 include:spf.service-a.example include:spf.service-b.example include:spf.service-c.example ~all外部サービスを追加するほど、ルックアップ回数が増加します。
2. includeのネスト（多重参照）
include:spf.service-a.example
└ include:spf.sub-a.example
└ include:spf.sub-b.example一見少なく見えても、内部でルックアップが増殖します。
3. 複数サービスの併用
- クラウドメールサービス
- 外部配信サービス
- ECシステム（通販プラットフォームなど）
- マーケティングツール
複数併用すると、簡単に10回を超える構成になります。
DNSルックアップ回数の確認方法
オンラインツール
- SPFチェッカー系ツール
- DNS解析ツール
→ 展開結果とルックアップ回数を確認可能
コマンド確認（簡易）
dig TXT example.comただし、ネストされたincludeまでは確認できないため、ツール併用が推奨です。
制限を回避する方法
1. 不要なincludeの削除
- 使用していないサービスを削除
- 古い設定の見直し
2. SPFのフラット化（flatten）
includeの中身をIPアドレスに展開します。
v=spf1 ip4:203.0.113.1 ip4:203.0.113.2 ip4:203.0.113.3 ~allメリット：
- ルックアップ削減
デメリット：
- IP変更時に手動更新が必要
3. サブドメイン分割
用途ごとにSPFを分離します。
example.com → 社内メール
mail.example.com → 配信専用4. redirectの活用
v=spf1 redirect=_spf.example.comSPF設定を一元管理できます。
5. サービス構成の見直し
- 重複サービスの削減
- 配信経路の整理
実務上の注意点
SPF単体では不十分
メール認証は以下の組み合わせが重要です。
- SPF
- DKIM
- DMARC
見た目と実際の差に注意
include:spf.service-a.example
include:spf.service-b.example一見2回でも、内部で10回以上になるケースがあります。
まとめ
SPFのDNSルックアップ制限は、メール到達率に直結する重要な要素です。
押さえるべきポイント：
- SPFのルックアップは最大10回
- includeのネストで増加する
- サービス併用時は特に注意
- flattenや分割で対策可能
補足（構成例）
v=spf1 include:spf.example-service.com ip4:203.0.113.1 ~allこのようにシンプルな構成を維持することが、トラブル回避の基本です。
コメント