SPF void lookupの推奨上限2回｜3回目がPermErrorになる条件

診断で「応答が空の参照が多すぎます」または「参照先が存在しない項があります」と表示された場合の原因と対処を説明します。

結論 — 3回目に到達するとPermErrorになります

SPFの評価中に引いたDNSの問い合わせのうち、名前が存在しなかったもの（NXDOMAIN）と応答は返ったが回答が0件だったものを仕様では「void lookup」と呼びます。RFC 7208 セクション4.6.4は、この数を2回までに制限することを受信側に求めています。推奨値のまま実装している受信側では、3回目に到達した時点でSPFの結果がPermErrorになります。

2つの表示は、意味が違います。

後者は前者の原因の1つで、両方が同時に出ることもあります。

やることは、引いた先が見つからない項を減らすことです。ただし項の種類によって、直さないと1件目からPermErrorになるものと上限に達するまでは失敗の直接の原因にならないものがあります。次の節の表で分かれます。

機構ごとに、引くものも影響も違います

SPFレコードに並ぶ項のうち、DNSを引くのは6種類です。何を引くか、どうなるとvoid lookupに数えられるか、1件だけでもPermErrorになるかは、それぞれ違います。

aが引く型は接続の種類で決まります。RFC 7208 セクション5.3は「using the type of lookup (A or AAAA) appropriate for the connection type」と定めています。IPv4で接続してきた送信元にはA、IPv6ならAAAAです。

mxは2段階です。セクション5.4は「check_host() first performs an MX lookup on the <target-name>. Then it performs an address lookup on each MX name returned」と定めています。MXを引き、返ってきた各ホストのアドレスをさらに引きます。

existsだけは接続の種類によらず常にAを引きます（セクション5.7、"even when the connection type is IPv6"）。

includeの参照先は、上限とは別に失敗の原因になります

表のとおり、includeとredirectだけは扱いが違います。参照先を引いてSPFレコードが無かった場合、void lookupの数とは関係なく、その時点でPermErrorになります（セクション5.2、セクション6.1）。1件目でもです。

したがって「使う予定があるから残しておく」という判断が成り立つのはa・mx・existsの側だけです。includeの参照先が引けない状態は、上限に達していなくても直す対象になります。参照先にSPFレコードが無い場合の直し方はSPFレコードの書式エラーを直すで扱っています。

数えないもの

DNSの問い合わせが失敗した場合（SERVFAIL、タイムアウト）は、void lookupに数えません。ただし、認証に影響しないという意味ではありません。この場合の評価結果はtemperrorになり（RFC 7208 セクション4.4）、受信側は一時的な失敗として扱います。

ip4:・ip6:・allはDNSを引かないため、いくつ書いてもこの数には入りません。

いまの状態を確かめる

自分のSPFレコードを次のコマンドで確認できます。

dig +short txt example.jp

example.jpの部分を自分のドメインに置き換えてください。表示された文字列から、上の表でDNSを引く6種類に当たる項を書き出します。

メール認証の診断にドメインを入力すると現在のvoid lookupの数と推奨上限、および引いた先が見つからなかった項が表示されます。

項ごとに確かめるときは、+shortを使いません

dig +shortは応答の中身だけを出すため、名前が存在しない（NXDOMAIN）のか、名前はあるが該当のレコードが無い（NODATA）のか、問い合わせ自体が失敗したのかを区別できません。どれも出力が空になります。この3つは扱いが違うので、通常のdigでステータスを見てください。

dig txt {includeに書いてあるドメイン}

出力のstatus:を見ます。

• status: NXDOMAIN … 名前が存在しません。void lookupに数えられます
• status: NOERRORかつANSWER: 0 … 名前はありますがTXTがありません。void lookupに数えられます
• status: NOERRORかつANSWER: 1以上 … 応答があります。数えられません。ただし返ってきたTXTにv=spf1で始まるものが無ければ、includeの場合は別の理由でPermErrorになります
• status: SERVFAIL … 問い合わせに失敗しました。設定の誤りとは限らず、権威DNSの障害や設定不備でも起こります。時間をおいて引き直してください

a:の参照先はAを引きます。exists:の参照先も同じくAです。

dig a {ホスト名}

mxは2段階なので、まずMXを引きます。

dig mx {ドメイン名}

status: NXDOMAINならその時点でvoid lookupに数えられます。MXが返ってきた場合は、返ってきた各ホスト名についてさらにdig aで確かめてください。

直す

見つからなかった項について、次のどれに当たるかを決めます。

削除するときは、その項だけを取り除きます。ほかの項には触れません。

（変更前）
v=spf1 include:_spf.example.jp a:old.example.jp ip4:203.0.113.10 ~all

（変更後）
v=spf1 include:_spf.example.jp ip4:203.0.113.10 ~all

上はa:old.example.jpだけを外した例です。本サイトの診断は、この表示に対して貼り付け用の設定値を作りません。どの項を残すかは、いま契約しているサービスによって決まり、DNSからは判定できないためです。自分のレコードから該当する項だけを外してください。末尾のallに付ける修飾子についてはSPFレコードのall修飾子の違いで扱っています。

レコードを変更したら、メール認証の診断でもう一度診断してください。表示が消えていれば、診断が使ったリゾルバから見た限りでは直っています。DNSの応答には有効期間（TTL）があり、受信側が変更前の値をまだ持っていることがあります。

DNS上で直っていることと実際のメールが認証を通ることは別です。送信テストを行い、届いたメールのAuthentication-Resultsヘッダーでspf=の値を確認してください。

2回という上限は、参照回数10回の上限とは決め方が違います

引いた先が見つからない項は減らしてください。そのうえでこの上限の性質を知っておくと直したあとの確認のしかたが変わります。

RFC 7208 セクション4.6.4は、同じ節の中で2つの上限を定めています。規範の強さが違います。

参照回数10回のほうはMUSTです。

SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".

10回を超えたら、受信側はPermErrorを返さなければなりません。

応答が空の参照のほうはSHOULDです。

SPF implementations SHOULD limit "void lookups" to two. An implementation MAY choose to make such a limit configurable. In this case, a default of two is RECOMMENDED. Exceeding the limit produces a "permerror" result.

実装が上限を設定できるようにしてよく、その場合の既定値として2が推奨される、と続きます。上限値を送信側へ通知する標準的な仕組みは無いため、2回以下にしておくのが安全です。

この上限が設けられた背景はセクション11.1にあります。存在しない名前を並べたSPFレコードが、受信側のDNS問い合わせを増幅させる攻撃に使えるためです。

参照回数10回の上限を超えている場合は、別の対処になります。SPFのDNS参照回数が10回を超える原因と直し方を確認してください。

SPFがPermErrorになってもDMARCが必ず失敗するとは限りません

SPFがPermErrorになるとそのメールのSPFの結果はpassになりません。ただしDMARCは、SPFとDKIMのどちらか一方がFromのドメインと整合した形で成功していれば通ります（RFC 9989 セクション5.3.5。整合の定義はセクション4.4）。DKIM-Signatureのd=で指定されたドメインがFromのドメインと整合していれば、SPFがPermErrorでもDMARCは合格しえます。

DKIMが通る場合もありますが、SPFの修正は必要です。DKIMを設定していないドメインではDMARCが通る経路が無くなり、SPF単体で判定している受信側もあります。DKIMの状態を調べる手掛かりはDKIMが設定されていない可能性がありますと出たときにあります。

調べ方と数値の読み方

Majestic Millionに掲載されている.jpドメイン19,535件を2026-08-23に測りました。DNSへの問い合わせは75,786回です。測定に使ったスクリプトはscripts/measure-spf-policy.mjsで、集計値はjp-spf-policy-2026-08-23.jsonとして公開しています。

母集団はMajestic Millionが参照元サブネットの数で並べた一覧からの抽出で、.jpドメイン全体からの無作為抽出ではありません。分母は、SPFレコードが1本だけの15,369件です。SPFレコードが2本以上あるドメインは、その時点でPermErrorになり各レコードの項を評価しないため除いています（RFC 7208 セクション4.5）。

3回以上を観測したのは10ドメインです。2回のドメインは30件あり、推奨上限には達しているものの、超えてはいません。同じ状態の項があと1つ増えると超えます。

a・mx・existsの参照先の名前が存在しなかった項を持つドメインは116件でした。これは各機構の1段目の問い合わせがNXDOMAINだった場合の件数で、mxが返した各ホストへの問い合わせは含みません。

この表は、実際のメール1通が受ける評価の回数とは別のものです。 本サイトの診断は送信元のIPアドレスを持たないため、レコードに書かれた項を最後まで展開した場合の値を数えています。実際の評価は、送信元がどれかの機構に一致した時点で終わります（RFC 7208 セクション4.6.2）。したがって次の両方が起こりえます。

• 実際より多く出る方向 … 途中で一致して評価されないはずの項まで数えている
• 実際より少なく出る方向 … mxの2段目、existsのAが無い場合、ptrを数えていない。参照回数が10回を超えた時点でそれ以上たどっていない。参照先を確認できなかったドメインが7件ある

数値は、本サイトの診断がこの条件で観測したものとして読んでください。どの項がなぜ残っていたのか（解約なのか、書き間違いなのか）は測っていないため、この表から原因の内訳は読み取れません。