SPF include 10 個制限の超過対処｜3 つの解決策
目次
この記事でわかること
- SPF の「DNS ルックアップ 10 個制限」が存在する理由（RFC 7208）
- 制限を超えると起きること（Permerror → SPF=fail 扱い）
- 3 つの解決策（Flattening / サブドメイン分離 / 不要 include 削除）の比較
- 自社にどの解決策が向いているかの判断基準
なぜ「10 個制限」があるのか
SPF の仕様（RFC 7208 Section 4.6.4）は、SPF レコードの評価中に発生する DNS ルックアップ回数を 10 個まで に制限しています。
理由はシンプルで、include: や redirect= を無制限にネストできてしまうと、1 通のメール検証のために DNS リゾルバが大量のクエリを撃つことになり、メール受信側の負荷が上がる からです。攻撃者が悪意ある SPF を仕掛けて DoS の踏み台にする懸念もあります。
カウント対象は include / a / mx / ptr / exists / redirect の 6 種類。ip4: / ip6: / all は DNS ルックアップが不要なのでカウントされません。
制限を超えると何が起きるか
10 個を超えた SPF レコードは、受信側で SPF=permerror（永続的なエラー）として処理されます。fail ではなく permerror 扱いになるのが厄介な点で、DMARC のアラインメント評価でも「SPF が pass しなかった」として扱われ、DMARC ポリシーが quarantine / reject なら メールが届かなくなります。lookup 超過以外にも PermError を引き起こす原因はあるため、全体像はSPF が PermError になる5つの原因で整理しています。
典型的な発症パターン:
- Google Workspace（
_spf.google.com）+ Microsoft 365（spf.protection.outlook.com）+ Salesforce + Mailchimp + Sendgrid と include を積んだら 10 個を超えた - 親会社の SPF を継承するために
include:parent-group.example.comを 1 つ追加した瞬間に超過 - include 先の SaaS 側が内部で
includeをネストしており、自社では include 1 個でも実際は 3〜4 個カウントされていた
「先週まで届いていたのに、今週から取引先に届かない」現象の典型的な犯人がこの 10 個超過です。
なお、include のネスト構造がどう数えられるかは SPF include のネストとは で詳しく解説しています。
解決策 1: 不要 include の削除（最優先で検討）
最も安全で副作用がない解決策は「もう使っていない SaaS の include を削除する」ことです。
実務で SPF が肥大化する原因の多くは、過去に試して解約した SaaS の include が残りっぱなしになっているケース。Web 担当者が DNS 編集権限を持っていない組織だと、SaaS 解約時に SPF を整理し忘れたまま放置されがちです。
棚卸し手順:
- 現在の SPF を
dig TXT example.comで取得 - 各
include:ホスト名から SaaS を特定（_spf.google.com→ Google Workspace、spf.protection.outlook.com→ Microsoft 365、など） - 過去 90 日以内にそこから実際にメールを送っているか を Authentication-Results 等で確認
- 送っていない SaaS の include を削除
「過去 90 日送信ゼロ」が確認できた include は遠慮なく外して構いません。唯一の副作用は「あとでその SaaS を再契約したら SPF を戻し忘れる」だけで、ドキュメント化しておけば回避できます。
解決策 2: サブドメインへ送信元を分離
メインドメイン（example.com）と、送信専用サブドメイン（mail.example.com / news.example.com）で SPF レコードを別々に持たせる構成です。
example.com→ 主に取引メール用（Google Workspace / Microsoft 365 のみ include）mail.example.com→ トランザクションメール用（Sendgrid / Postmark など）news.example.com→ マーケティング配信用（Mailchimp / HubSpot など）
それぞれのサブドメインで SPF を「10 個に収まる範囲」に独立して設計できるため、最も将来性のある解決策です。
ただし送信元アドレスを noreply@news.example.com のようにサブドメインに切り替える必要があるため、実装難度は高めです。差出人ブランドの統一感が崩れる懸念もあるので、リブランディングのタイミングで導入するのが現実的でしょう。
DMARC との関係性は DMARC ポリシー段階強化ガイド で関連解説をしています。
解決策 3: SPF Flattening（フラッタニング）
Flattening は、include で参照している SaaS の IP アドレスリストを手元で展開して ip4: / ip6: で直書きする手法です。
例:
Before: v=spf1 include:_spf.google.com -all
After: v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ... -all
ip4: / ip6: は DNS ルックアップを伴わないので、ルックアップ数を一気に 0 に圧縮できます。
ただし最大の欠点は「include 先の SaaS が IP を追加・変更すると、自社の SPF が古くなって SPF=fail になる」こと。Google Workspace や Microsoft 365 の送信 IP は不定期に変わるため、手動で Flattening した SPF は数ヶ月で破綻するリスクがあります。
実務的な選択肢:
- 専用ツール（PowerDMARC / EasyDMARC / DMARCian の SPF Flattening 機能など）で自動更新する
- マネージド SPF サービス（年額数万円〜数十万円）で IP 更新を任せる
- 自前運用は「定期的に再展開する CI ジョブ」を組まないと事故る
Flattening の具体手順は SPF Flattening とは に詳しくまとめているので、採用するならそちらを必ず読んでから取り組んでください。
3 つの解決策の選び方
| 状況 | おすすめ |
|---|---|
| SaaS 解約後の include が残っている | まず解決策 1（削除）で 1〜2 個落とせるか確認 |
| 取引メールと配信メールを分けたい | 解決策 2（サブドメイン分離）が長期的に有利 |
| すぐ実効的に lookup を 0 に近づけたい | 解決策 3（Flattening）を専用ツール経由で |
| 上記をどう判断すべきか迷う | 棚卸しを先にやってから次の手を決める |
特に解決策 3 を「自前手動」で導入するのは強く非推奨です。SaaS 側の IP 変更を追従できず、半年後にメールが届かなくなる事故を毎月のように見かけます。
設定後の検証は SPF/DKIM/DMARC の確認方法 を参照してください。
まずは現状を把握しましょう
ドメイン番人の 無料ドメイン診断 で、SPF のルックアップ数と現在の状態を 30 秒でチェックできます。「10 個に対して残り何個か」を診断結果で確認できます。
SPF Flattening の導入支援、棚卸し代行、サブドメイン分離設計などは お問い合わせ からどうぞ。
関連記事: SPF Flattening とは / SPF include のネスト解説 / SPF/DKIM/DMARC の確認方法