Defaults.Exposed › 修正 › Guides
SPF PermError: メールを壊さずに「DNS ルックアップ過多」を修正する方法（2026）
公開日 2026-07-08
データ基準日：2026-06-29 · 方法論 v7。 261 百万件のグレード済みドメインに対する集計センサスデータ。グレード方法についてはこちら。
139 百万件の SPF 公開者のうち、Defaults.Exposed による 261,086,232 件のドメインセンサスによると、少なくとも 797,263 件のドメインが SPF の 10 回 DNS ルックアップ上限を超えています。10 を超えると受信者は停止して PermError を返します：SPF が無効化され、DMARC は PermError を失敗としてカウントします。
修正には厳密な順序があり、ほとんどのガイドは逆から始めています。実際の解決されたルックアップを数え；不要・未使用の include を削除します — それだけでほとんどのレコードが修正されます；大量送信者を独自の SPF 予算を持つサブドメインに移動します；フラット化は最後の手段としてのみ、そして自動化された再フラット化によってのみ行います。静的フラット化は腐敗して配信を静かに壊すからです。
「SPF PermError: DNS ルックアップ過多」とはどういう意味か？
RFC 7208 §4.6.4 はすべての SPF チェックを 10 回 DNS ルックアップに制限しています。10 を超えると、受信者は停止して PermError を返します — レコード全体が、予算超過の部分だけでなく、壊れたものとして扱われます。同じセクションには、あまり知られていない 2 番目の上限も追加されています：最大 2 回の「無効ルックアップ」（回答または NXDOMAIN が返らないクエリ）で、解約したサービスへの不要な include: エントリーが 2 件あるだけで SPF を無効化できます。
結果は「SPF なし」よりも悪い：DMARC は PermError を SPF 失敗として扱うため、自分の SPF を壊すドメインはすべての DMARC 評価の SPF レッグで未認証になります。DKIM がセットアップされていないか転送中に壊れると、そのメールは DMARC を完全に失敗します。
1 つのセンサー数値がこの失敗モードの残酷さを示しています：112,215 件のドメインが、ルックアップオーバーフローにより無効化された厳格な -all レコードを公開しています — -all をまったく公開している 54,655,923 件のドメインから。オーナーは大変な部分をやりました — 厳格な終端を選択しました — そして include が 1 つ多すぎてレコード全体がオフになりました。厳格に見えますが壊れています。完全なデータは SPF PermError レポートをご覧ください。
何も変えていないのに SPF が壊れたのはなぜか？
予算のほとんどが他人のレコードによって消費されるからです。すべての include: は再帰的に評価され、その中の各ルックアップメカニズムがあなたの 10 に対してカウントされます。DNS パネルの 1 行が解決後 4〜5 ルックアップになることがあります。プロバイダーが 1 つ多く include をネストすると、あなたのゾーンに 1 つの変更もなく SPF が死にます。
大手プラットフォームは問題ではありません：Google と Microsoft は両方とも自分の SPF をフラット化しています — _spf.google.com と spf.protection.outlook.com はプレーン IP リストに展開され、内部ルックアップはゼロです（2026 年 7 月のライブ DNS に対して確認済み）。実際の崩壊は、数層深くネストされたホスティングパネルの include チェーンから、そして正直な SaaS の積み上げから来ます — メールボックスに加えてニュースレター、CRM、ヘルプデスク、それぞれが「1 つの include だけ」。誰も意図的に 11 番目のルックアップを追加しません；合理的な決定の合計として到着します。これが崖っぷちがこれほど混んでいる理由です：2,119,539 件のドメインがちょうど 9〜10 解決ルックアップにいます — 全 SPF 公開者の約 66 件に 1 件で、今日は問題なく、誰かがもう 1 つ include を貼り付けた日に無効化されます。99 パーセンタイルの SPF レコードはすでに 9 ルックアップに解決されます。スタックが SaaS 中心の場合は、SaaS ツールの SPF 失敗ガイドがベンダーごとのバージョンをカバーしています。
SPF レコードのどの部分が DNS ルックアップとしてカウントされるか？
| メカニズム | ルックアップコスト | 注記 |
|---|---|---|
include: | 1 + 内部のすべて、再帰的に | ほぼすべての崩壊の原因 |
a | それぞれ 1 | 自ドメインの bare a でも |
mx | それぞれ 1（プラス MX ホストの A ルックアップ） | よく忘れられる |
ptr | 1 — 2014 年から廃止 | 理由に関わらず削除すること |
exists: | それぞれ 1 | 稀 |
redirect= | 1 + ターゲットレコードの内容 | include と同様にカウント |
ip4: / ip6: | 0 | これがフラット化が機能する理由 |
-all / ~all / ?all | 0 | 修飾子は無料 |
見えている行ではなく、解決された合計を数えてください。4 つの include が 4 ルックアップにも 14 ルックアップにもなり得ます。
メールを壊さずに「DNS ルックアップ過多」を修正する方法
- DNS に触れる前に無料スキャンを実行する。 完全な include チェーンを解決し、実際のルックアップ数を表示します。これにより実際の問題を修正します — パネルに表示されるレコードではなく。（SPF が全くないと言う場合、それは別の失敗です — 「SPF レコードが見つからない」を参照してください。）
- まず不要・未使用の include を削除する。 2023 年に解約したツール、マイグレーション後に残った古いホストの include、重複、任意の
ptrメカニズム。不要な include は二重に有害です：ルックアップ予算を消費しかつ通常は無効ルックアップの発生源です。ほとんどの予算超過レコードはこのステップだけで 10 未満に戻ります。レコードに以前のプロバイダーのメカニズムがまだある場合は、マイグレーションクリーンアップガイドに従ってください。 - 残りの各 include が何かをしているか確認する。 受信者はReturn-Path（RFC5321.MailFrom）ドメイン、From ヘッダーではなくに対して SPF を評価します — そして多くの SaaS ツールは Return-Path に自分のバウンスドメインを使うため、あなたのレコードの include は予算を消費するだけで何もしません。Return-Path にあなたのドメインを使うサービスの include のみを保持；残りは代わりにベンダーのカスタムドメイン DKIM を有効にしてください。
- 大量送信者をサブドメインに移動する。
news.yourdomain.comからのニュースレター、mail.yourdomain.comからのトランザクションメール。各サブドメインは独自の SPF レコードと新しい 10 ルックアップ予算を持ち、1 つのストリームの問題が他に波及しなくなります。 - そのあとでフラット化を検討する — そして自動化されたフラット化のみ。 以下を参照してください。
- 再スキャンして確認する — 10 を快適に下回っていることを目指してください。ちょうど 10 にいると 2.1 百万件の崖っぷちドメインに再び参加したことになります。次に、SPF の修正ページのスキャンが他にフラグを立てるものを処理してください。
SPF レコードをフラット化すべきか？
フラット化は include をゼロルックアップの ip4:/ip6: ブロックに置き換えます。機能します — そして手作業でやると、遅延した配信停止になります。
| アプローチ | ルックアップ数 | 時間経過とともに |
|---|---|---|
| 削減 + サブドメイン（ステップ 2〜4） | 通常 10 未満に戻る | 安定；プロバイダーが自分の IP を管理 |
| 自動化されたフラット化（サービスまたはスケジュールジョブが再解決して再公開） | ほぼ 0 | プロバイダーの IP 変更を追跡；安全 |
| 一度限りの手動フラット化 | ほぼ 0 — 今日は | 静かに腐敗：プロバイダーが IP をローテーションし、正規のメールが SPF に失敗し始めるが、あなたの側にはエラーなし |
プロバイダーは定期的に送信 IP をローテーションし、誰にも知らせません。静的 IP リストは貼り付けた日は正確で、数か月以内に静かに間違いになります — 失敗が他の人があなたのメールを受信しないとして現れるため、遅れて気づきます。削減とサブドメインで上限を下回れるなら、そこで止めてください；サードパーティの IP ブロックを恒久的な修正としてレコードに手でコピーしないでください。
よくある質問
SPF PermError はメールの配信が止まることを意味するか？ すぐにではありません — それが危険な理由です。DMARC は PermError を SPF 失敗としてカウントするため、配信は完全に DKIM に依存します；DKIM が欠落しているか転送中に壊れると、DMARC に失敗します。センサスの 139 百万件の SPF 公開者のうち（2026-06-29 時点）、少なくとも 797,263 件がこの状態にあります — ほとんどが知らずに。
レコードには 4 つしか include がないのに、10 ルックアップを超えるのはなぜか？ include は再帰的にカウントされます：各 include の中（そしてその include の中）のすべてが予算に課金されるため、4 つの見える行が 14 ルックアップに解決されることがあります。目で数えるのではなく解決ツールで数えてください — チェーンの解決方法が PermError レポートがおよそ 100 倍多くの壊れたドメインを表面のカウントより見つけた方法です。
-all で終わっているから保護されているはずでは？
レコードが評価される場合のみ。センサス（2026-06-29 時点）では、112,215 件のドメインの厳格な -all レコードがルックアップオーバーフローにより無効化されていることが判明しました。PermError レコードの厳格な修飾子は何も保護しません。
上限は include ごとに 10 ルックアップか、それともレコード全体に対してか？ 評価全体に対してです：RFC 7208 §4.6.4 は完全なチェックを 10 に制限し、さらに最大 2 回の無効ルックアップを制限します。各サブドメインは独自のレコードと予算を持ちます — これがステップ 4 が機能する理由です。
ip4 と ip6 のエントリーは上限に向かってカウントされるか？ いいえ — IP メカニズムは何もコストがかかりません。これがまさにフラット化がカウントを減らす理由です。
オーナーにレポートを送る
クライアントまたは雇用主のためにこれを修正している場合は、証拠で作業を終えてください。変更後に無料スキャンを再実行し、採点済みレポートをビジネスオーナーに転送してください：平易な言葉、日付付き、PermError が消えた。これがサイバー保険の更新と次の顧客セキュリティアンケートに必要なアーティファクトです — 「DNS レコードをいくつか変更しました」と文書化された前後の比較の違いです。
ドメインを無料で確認する
実際の解決されたルックアップ数を確認できます — そして SPF、DKIM、DMARC の他のすべてを — プライベートにオーナーのみで。
ドメインを確認 → · SPF を修正 → · SaaS ツールの SPF 失敗 → · GoDaddy で SPF をセットアップ → · グレード方法について → · 集計データのみ。データは EU で保存・処理されます。