SPFの「DNSルックアップ10回制限」とは — permerrorの原因と減らし方

SPFには、検証中のDNS参照が10回を超えると、SPF全体がエラー（permerror）になるという仕様上の制限があります。エラーになると、正しく書いてあっても「SPFを設定していないのと同じ」扱いになります。

やっかいなのは、自分のレコードは短く見えても超えることです。配信サービスを増やしていったある日、突然メールが届かなくなる——という形で表面化します。

なぜ10回で打ち切られるのか

SPFの検証は、受信側が1通ごとにリアルタイムで行います。もし参照が無制限なら、悪意ある人が「参照が延々と続くレコード」を作って受信サーバーに負荷をかけられてしまいます。これを防ぐために、RFC 7208で上限が10回と定められています。

この制限は受信側が機械的に適用するものです。「うちは大丈夫だろう」という例外はありません。

何が「1回」に数えられるのか

数えられるのは、DNSへの問い合わせを発生させる仕組みです。

⚠️ 最大の落とし穴：include: の先にある include: も数えられます。自分のレコードに include: が3つしかなくても、その3つの中にそれぞれ3つずつ入っていれば、合計で3＋9＝12回になり、超過します。

自分が何回使っているか調べる

無料診断にドメインを入れると、SPFレコードの内容が表示されます。include: の数を数え、そのうえで各 include: 先のレコードも確認してください（配信サービスの公式ドキュメントに書かれていることが多いです）。

「10回を超えているかどうか」を正確に測るには、SPFの展開結果を数えてくれる専用ツールを使うのが確実です。数字が9〜10に近いなら、次に1つサービスを足した時点で壊れます。余裕を持って対処してください。

減らし方 — 効果の大きい順

1. 使っていない include: を削除する（最優先）

いちばん多い原因が、解約したサービスの設定が残っていることです。数年前に使っていた配信サービス、乗り換え前のメールサーバー、試しただけのツール。これらが1回ずつ枠を消費し続けています。

SPFに書かれている include: を1つずつ見て、「今も使っているか」を確認してください。使っていないものを消すだけで、多くの場合は解決します。

💡 消す前に必ず、現在のレコードをコピーして保存してください。判断に迷うものは残し、確実に使っていないものだけを消します。

2. 送信用途ごとにサブドメインを分ける

「本体ドメインからは業務メール、news.example.co.jp からは一斉配信」のように分ければ、それぞれのドメインが独立して10回の枠を持てます。

枠が増えるだけでなく、一斉配信の評判が悪化しても業務メールに影響しないという利点もあります。長期的にはこれがいちばん healthy な形です。

3. a / mx を ip4: に置き換える

a や mx は、実際にはIPアドレスを引くためのショートカットです。IPが固定なら、直接 ip4: で書けば0回になります。自社サーバーのIPが変わらないなら、この置き換えは安全です。

4. SPFフラット化 — おすすめしません

include: の中身をすべて展開して ip4: の羅列に置き換える手法があります。参照回数は0になりますが、強くはおすすめしません。

配信サービスが送信IPを変更したとき、あなたのSPFは古いIPのまま取り残されます。相手は「SPFレコードを更新してください」と告知しませんし、include: なら自動で追従するはずだった変更が、突然の配信不能として現れます。自動追従を捨てる代償だと理解したうえでのみ選んでください。

やってはいけない回避策

• SPFレコードを2本に分ける — 制限は回避できません。それどころか2本あること自体がpermerrorになります
• +all にする — 「誰でもこのドメインを名乗ってよい」という宣言です。なりすまし対策の意味が完全になくなります
• ptr を使う — RFCで非推奨とされており、受信側で無視されることがあります

設定値を作り直す

設定する値をつくるで、お使いのサービスに合った1本のSPFレコードを作成できます。複数のサービスを併用している場合も、正しく1本に統合した形で出力されます。作った値は依頼文に載せて、DNS管理者にそのまま渡せます。