Defaults.Exposed › レポート
SPF PermErrorレポート：表面的なカウントが示すよりも100倍多くのドメインが10ルックアップ制限を超えて壊れている（2026年）
公開日 2026-07-03
数値は2026-06-29時点 · 方法論v7、加えて2026-07-03に実行したチェーン価格算定パス。 261百万件の採点済みドメインからなるセンサスにおいて、100回以上参照されているすべてのSPF
include:ターゲットを解決し — 全include参照の95.2%をカバーする10,842件のターゲット — そのマップに対して各ドメインの保持チェーンを価格算定しました。未解決の末端ターゲットはゼロとして数え、チェーンの内容は解決日時点のものを反映しているため、この見出しは保守的で下限寄りの近似値です。だからこそ「少なくとも」と述べています。集計値のみであり、個別事業者のレコードでは決してありません。採点方法をご覧ください。
SPFの10ルックアップ制限を超えて壊れているドメインはいくつあるか？
少なくとも797,263 — なぜなら、SPFには規格そのものに自己破壊機構が組み込まれており、そのトリガーは所有者が見えないところに隠れているからです。 RFC 7208 §4.6.4は、1回のSPFチェックを10回のDNSルックアップに制限しています。10回を超えると、受信者は処理を止めてPermErrorを返し、PermErrorのレコードは何も保護しません。レコード自体に見えているルックアップだけを数えると — 大半のツールがそうしており、本レポート以前の私たち自身のセンサスもそうしていました — 約8,000件の違反ドメイン（正確には7,958件）が見つかります。それらのレコードが実際に引き込む include: チェーンを価格算定すると、その数は**797,263に達します。およそ100倍の規模です。**
なぜ所有者はそれが来るのを見えないのか？
なぜなら、その予算は他人のレコードによって消費されるからです。include:onetool.example.com はあなたのDNSパネルでは1行として読めます — しかし受信者はそのレコードも取得しなければならず、そこに含まれるすべてのルックアップ機構を再帰的に数えます。3つのincludeを持つレコードは11回のコストになり得ます。あなたが制限を超えた日、あなた自身のゾーンでは何も変わっていません。プロバイダがもう1つincludeをネストし、あなたのSPFは警告なしに死んだのです。
さらに悪いことに、DMARCはPermErrorをSPFレグの失敗として扱います — したがって、この方法でSPFを壊してしまったドメインは、いまや自らの認証の半分を失敗させていることになります。
チェーン価格算定で分かったこと
| 発見 | ドメイン数 |
|---|---|
| 10ルックアップ制限を超過、チェーン価格算定済み | 797,263 |
| 見える機構だけを数えて制限を超過 | 7,958 |
制限を超過しながら厳格な -all で終わっている | 112,215 |
| ちょうど9〜10ルックアップ — 崖っぷち | 2,119,539 |
この表には2つの物語があります — 3つ目、崖っぷちについては下に独立したセクションを設けています：
- 表面的なカウントは破綻の約99%を見逃しています。 見える機構のカウントは7,958件を見つけますが、チェーンの価格算定は797,263件を見つけます。損害のほぼすべては、includeがincludeしているものから継承されています。
- 壊れたレコードのうち112,215件は
-allで終わっています。 それらの所有者はすべてを正しく行いました — 壁を登り、厳格な終端を選んだ — のに、includeが1つ多かったことですべてが無効になりました。厳格に見えて壊れているというのは、メールセキュリティにおいて最も過酷な失敗モードです。
2.1百万件のドメインがツール1つで崖から落ちる状態にある
現時点では問題ない読者を心配させるべき数値がこれです：2,119,539件のドメインがちょうど9または10ルックアップに解決されます — 今日は制限内ですが、誰かがもう1つプラットフォームを接続した日に死にます。これは全SPF公開者のおよそ66件に1件であり、分布の形状とも一致しています。99パーセンタイルのSPFレコードはすでに9ルックアップに位置しています。マーケティングツールをもう1つ登録し、その「このincludeを追加するだけ」という一行を貼り付ければ、朝食時には制限内だったレコードが昼食時には無効になります。
誰の責任か？ ますます、スタックの責任
最大手のプロバイダは静かにSPFをフラット化しました — Googleの _spf.google.com とMicrosoftの spf.protection.outlook.com は、いまや内部ルックアップコストがゼロのプレーンなIPリストに展開されます（本分析中に両者をライブDNSに対して検証しました）。破綻は別のところから来ます：3段深くネストするホスティングパネルのチェーン、それ自体で7〜10ルックアップかかるincludeを持つ地域プロバイダ、そしてSaaSの正直な積み重ね — メールボックスにニュースレターにCRMにヘルプデスク、それぞれが「たったひとつのinclude」です。ほとんど誰も、意図的に11番目のルックアップを追加しません。それは合理的な決定の総和として到来します。
あなたのものを確認して修正する方法 — 無料
- 本当の合計を数える — 私たちの無料チェックがあなたのチェーンを解決します。あるいは任意のSPFルックアップカウンターを使ってください。
- 無駄な重みを取り除く：使うのをやめたツール、重複したinclude、そして非推奨の
ptr機構。 - 自分が管理するものだけをフラット化する。 深いincludeをそのIPブロックに置き換えることは、自分自身のインフラには有効ですが、サードパーティのIPは予告なく変わります。
- 大量送信者にはサブドメインを与える。
news.yourdomain.comからのニュースレターは、独自のレコードと独自の10ルックアップ予算を得ます。
よくある質問
SPFの10 DNSルックアップ制限とは何ですか？
RFC 7208 §4.6.4は、1つのSPFレコードを評価するのに最大10回のDNSルックアップを許可します — すべての include: の内側のルックアップを再帰的に数えます。これを超えるとPermErrorを返します。レコードは無効として扱われ、保護を提供しません。
SPF PermErrorとは何を意味しますか？ 恒久的な評価エラーです — 受信者があなたのレコードを処理できなかった（ルックアップが多すぎる、複数のレコード、または構文の破損）ため、あなたのドメインを使えるSPFがないものとして扱います。DMARCはこれをSPFレグの失敗として数えます。
SPFルックアップ制限を超えているドメインはいくつありますか？ 私たちのチェーン価格算定パスによれば、139百万件のSPF公開者のうち少なくとも797,263件 — チェーンを解決せずに見える7,958件の約100倍です。さらに2,119,539件が9〜10ルックアップに位置し、制限までinclude1つの状態です。
PermErrorがあると私のメールは配信されなくなりますか？ たいていはなりません — 受信者はSPFなしで処理を進め、あなたのメールはDKIMと評判に乗ります。機能しなくなるのは保護です：偽装者はもはや拒否されず、あなたのメールのすべてのDMARCチェックはSPFレグを失います。それは高くつくまで目に見えません。
SPFのルックアップ数を減らすにはどうすればよいですか？
未使用のincludeと ptr を削除し、自分自身のインフラを ip4:/ip6: にフラット化し、大量送信者をサブドメインに移し、新しいツールを追加するたびに数え直してください。修正ガイドが手順を案内します。
あなたの本当の数を知る
見えている機構はあなたのルックアップ数ではありません — 解決された数こそが受信者が計算するものであり、それは30秒でチェックできます。
あなたのドメインをチェック → · SPFを修正 → · SPF成熟度モデル → · SPFレコード2つ＝ゼロ → · ptrの罠 → · 集計データのみ。データはEU内で保存・処理されます。