Defaults.Exposed › レポート

なぜSPFが失敗するのか？英国・EUの送信者が抱えるSaaS 10ルックアップ問題（2026年）

公開日 2026-07-09

2026-06-29時点のデータ · 方法論 v7。 261百万のグレード付きドメインを対象とした集計センサスデータです。評価方法をご覧ください。

英国・EUのSaaSツールを利用する企業でSPFが失敗する場合、最も可能性の高い原因は、これまで意識したことのないRFCの一つのルールです。DNSルックアップが10回を超えると、SPFは「fail」を返すのではなく、「PermError」を返します。これはレコードが存在しないとして扱われることを意味します。 すでに797,263以上のドメインがこの限界を越えています。さらに2,119,539のドメインがちょうど9〜10回のルックアップの位置にあり、新しいツールを一つ追加するだけで同じ崖から落ちる状況にあります。

SaaSツールを追加するとなぜSPFが壊れるのか？

SPFは、ドメインの代わりにメールを送信することを許可されたメールサーバーをリストアップすることで機能します。現代の企業は自社のメールサーバーを運用していません — 社内メールにはGoogle Workspace、メールキャンペーンにはMailchimp、営業シーケンスにはHubSpot、CRMアウトリーチにはPipedriveを使用しています。各プラットフォームはDNSに貼り付けるためのinclude:行を提供します。

問題は、すべてのinclude:がそれ自体DNSルックアップであることです。さらに、そのincludeの内部にあるすべてのレコードが、再帰的にさらなるルックアップを引き起こす可能性があります。RFC 7208 §4.6.4は10回というハードな上限を設けています。10回を超えると、受信メールサーバーは評価を停止し、PermErrorを返します — PermErrorはスパムに入る「ソフトな失敗」ではありません。SPFレコードが存在しないとして扱われることを意味します。メール認証はSPFの段階で失敗します。

これはDNSパネルでは確認できません。カウンターはライブ評価中にのみ発動します。可視のレコードに3つのinclude:行しかなくても、各ベンダーのSPFレコードが独自のサブインクルードを引き込むため、実際には12ルックアップ深くなっている場合があります。

すでに制限を超えているドメインはいくつあるか？

797,263以上です。 これは、100回以上参照されたすべてのSPF include:ターゲット（10,842件の個別ターゲット、全includeリファレンスの95.2%をカバー）を解決し、各ドメインの完全なチェーンを評価した後の数値です。表面上の数（レコードの可視行のみをカウントした場合）では約7,958が見つかります。チェーン評価後の数値は100倍大きく、これはほぼすべての被害がincludeターゲットの内部に見えない形で存在するからです。

ヨーロッパの企業に最も影響を与える可能性が高い状況：

ヨーロッパのホスティングプロバイダーと弱いSPFデフォルト設定

最初に選んだホスティングプロバイダーが重要です — 一つのSaaSツールを接続する前に、すでに10ルックアップのうちいくつかを消費するSPFデフォルト設定を行うものがあるからです。

センサスのヨーロッパドメインで使用されている大手ホスティングプロバイダーの中で：

IONOSは際立っています：IONOSホスティングドメインの1.0%がDMARCを適用しているため、圧倒的多数は実質的な送信者認証がまったくありません。OVHドメインはSPF厳格設定（43.7%）ではより良い結果を示していますが、DMARC適用では2.2%に落ちます — SPF単体では、From:ヘッダーにDMARCを紐付けることなく、エンベロープのみを保護し、受信者が見るものは保護されません。

Microsoft 365は良い意味で例外です：Microsoftホスティングドメインの85.0%が厳格なSPFを使用しています。これは主にMicrosoftのメールフローウィザードがデフォルトで-allを設定するからです。Google Workspaceはデフォルトで~all（softfail）を設定するため、そのドメインの92%が厳格な保護なしのままです。

60秒以内でSPF障害を診断する方法

最速の確認方法は、可視レコードだけでなく完全なルックアップチェーンを評価する無料ツールを使用することです。コマンドラインでnslookup -type=TXT yourdomain.comを実行し、表示されるすべてのinclude:を数えます。次に各レコードを調べ、そのレコードの数を数えます。includeが尽きる前に指が足りなくなったら、危険ゾーンにいます。

より確実なアプローチ：こちらでドメインを確認 — スキャナーが完全に解決されたチェーンを評価し、PermErrorにフラグを立て、どのメカニズムがルックアップ予算を消費しているかを示します。

3つの診断結果：

• PermError — すでに10回を超えています。送信するすべてのメールが受信者のSPFチェックで失敗します。
• 9〜10ルックアップ — 崖の端にいます。次のSaaS統合でその先へ転落します。
• hardfail (-all)の代わりにSoftfail (~all) — 制限以下ですが、レコードの設定が緩すぎて実質的な保護を提供していません。-all対~allの全体像についてはSPF設定ミスレポートをご覧ください。

複数のSaaSツールを使用する場合のSPF修正方法

永続性の順に3つのアプローチがあります：

1. 監査と整理。 まず現在のレコードにあるすべてのinclude:をリストアップします。もはや使用していないプラットフォームを削除します — 古いESP、以前の契約のCRMツール、テストしたが放棄したプラットフォーム。これは無料で、多くの場合いくつかのルックアップを回収できます。削除した各include:は1〜3つのサブルックアップを除去できる可能性があります。

2. SPFレコードのフラット化。 SPFフラット化は、すべてのinclude:ターゲットを基盤となるIPレンジに解決し、ip4:とip6:メカニズムとして直接レコードに書き込みます。IPメカニズムはルックアップを引き起こさないため、フラット化されたレコードは何十もの送信元をリストアップしながら、ルックアップ数をゼロに保てます。欠点は、ベンダーが送信IPを更新するたびに再フラット化が必要なことで、これは予告なく発生します。ほとんどの企業は有料のSPFフラット化サービス（PowerDMARC、EasyDMARC、Dmarcianなどが提供）を使用するか、監視ワークフローを構築します。

3. SPFマクロの使用。 RFC 7208マクロを使用すると、includeのチェーンではなく、チェックごとに1回のDNSルックアップを実行して動的に応答するレコードを構築できます。マクロにはDNSホスティングのサポートと実装作業が必要ですが、多くのSaaS送信者を持つ組織にとってアーキテクチャ的にクリーンなソリューションです。

SPFを修正した後は、DMARCの適用と組み合わせてください — DMARCなしのSPFは、受信者が見るFrom:アドレスではなく、エンベロープ送信者のみを認証します。

よくある質問

SPFレコードはDNSツールで通過するのに、なぜメールヘッダーで失敗するのか？ ほとんどのDNSルックアップツールは、自分のレコードに表示されているメカニズムのみをカウントし、それらのメカニズムが引き起こすサブルックアップはカウントしません。2つのinclude:行しかなくても、各ベンダーのレコードにさらに数個含まれている場合、制限を超えることがあります。チェーン評価ツール（または受信メールサーバー）だけが完全な深さをカウントします。実際のチェーン数を確認するにはドメインを確認してください。

SPFが失敗するとメールはスパムに入るのか？ PermError（ルックアップが多すぎる）は、認証のSPFの段階が結果なしを返すことを意味します — 実質的には不在です。DMARCはSPFとDKIMの両方を評価します；DKIMが通過すれば、SPF PermErrorにもかかわらずDMARCは通過できます。どちらも通過しない場合、DMARCは失敗し、結果はDMARCポリシーに依存します。p=noneでは、メールはまだ届きますが失敗がログに記録されます。p=quarantineまたはp=rejectでは、メールはフィルタリングまたはバウンスされます。DKIMだけに依存しないようにSPFを修正してください。

典型的なSaaSスタックは何回のルックアップを使用するか？ センサスのp99 SPFレコードはすでに9ルックアップにあります — 何も追加する前から制限ギリギリです。Google Workspaceレコードは3〜4ルックアップを追加し、Mailchimpは1〜2、HubSpotは現在の設定によって1〜3追加します。3つの主流ツールとホスティングプロバイダーのデフォルトだけで10回を超えるには十分です。

SPFフラット化は安全か？ 最新の状態を保てば安全です。フラット化はinclude:チェーンを静的なIPレンジに変換します — ベンダーが送信IPをローテーションし、再フラット化しない場合、そのベンダーのメールを拒否し始めます。ほとんどの組織は、手動で管理するのではなく、IP変更を監視するマネージドフラット化サービスを使用します。

SPFは何年もこのままなのに、なぜ突然失敗するのか？ ベンダーがSPFレコードを更新しているからです — あなたのレコードではなく。SaaSプラットフォームが新しい送信IPレンジを追加したり、別のincludeをネストするたびに、あなた側の変更なしにチェーンコストが上昇します。10ルックアップ制限はメッセージ受信時にライブで評価されるため、火曜日の朝のベンダー変更が火曜日の午後にはSPFを壊す可能性があります。

SPFを修正するとメール配信率は向上するか？ 認証失敗の原因を除去することで、一貫した配信の前提条件が整います — 特にGoogleとYahooが一括送信者向けにDMARCアライメントを適用するようになった現在は重要です。SPF単体では全体像ではありません：完全なメール認証のためにDKIMとDMARCと組み合わせてください。

SPFを無料でチェック

SPFレコードがルックアップ制限を超えているかどうか、またはドメインを保護するには設定が弱すぎるかどうかわからない場合は、無料チェックを実行してください。完全に解決されたチェーンを評価し、予算がどこで消費されているかを正確に示します。

ドメインを確認 → · SPFを修正 → · SPF PermErrorレポート → · SPF設定ミスレポート → · SPF採用成熟度モデル → · DMARCを修正 → · 集計データのみ。データはEU内で保存・処理されています。