## この記事でわかること

- SPF の `include:` が入れ子（ネスト）になる仕組み
- RFC 7208 が定める 10 ルックアップ上限の正確な数え方
- Google Workspace + SendGrid + Mailchimp 併用で上限超過する典型例
- 確認ツールと、超過時の解消フロー

## SPF include の入れ子とは

SPF レコードは `include:` ディレクティブで他ドメインの SPF を取り込めます。たとえば `include:_spf.google.com` を書くと、Google が公開する SPF レコードがそのまま自社レコードの一部として評価されます。

問題は、その取り込み先の SPF が **さらに別の `include:` を含む**ケースです。Google の `_spf.google.com` は内部で `include:_netblocks.google.com`、`include:_netblocks2.google.com`、`include:_netblocks3.google.com` を呼び出しています。これが「入れ子（ネスト）」の状態です。

SPF の基本構造を未確認の方は、先に[SPF レコードの書き方](/blog/spf-setup-guide)を一読しておくと理解が早くなります。

## RFC 7208 の 10 ルックアップ上限

RFC 7208 Section 4.6.4 は、SPF 評価時の DNS 問い合わせ回数を **最大 10 回** に制限しています。これは受信側 MTA が無限ループや DoS を回避するための仕様で、超えた時点で評価結果は `permerror`（永続的エラー）となります。lookup 超過以外の PermError 原因とあわせて知りたい方は[SPF が PermError になる5つの原因](/blog/spf-permerror-causes)を参照してください。

カウント対象になるのは以下の機構です。

- `include:` 1 個につき 1 ルックアップ
- `a` 機構 1 個につき 1 ルックアップ
- `mx` 機構 1 個につき 1 ルックアップ
- `ptr` 機構 1 個につき 1 ルックアップ（非推奨）
- `exists:` 1 個につき 1 ルックアップ
- `redirect=` 1 個につき 1 ルックアップ

ここで重要なのは、**入れ子の include も親の総ルックアップ数に再帰的に加算される**点です。`ip4:` `ip6:` `all` はノーカウントですが、入れ子の中で使われている `include:` は親の枠を消費します。

![include 入れ子のツリー構造](/blog/spf-include-nesting/nesting-tree.svg)

## 典型ケース: Google + SendGrid + Mailchimp

中小企業でよくある構成で実際に数えてみます。

```
v=spf1 include:_spf.google.com
       include:sendgrid.net
       include:servers.mcsv.net -all
```

書いてある `include:` は 3 つ。一見余裕に見えますが、内部を展開すると次の通りです。

- `include:_spf.google.com` … 親 1 + 内部 `_netblocks.google.com` / `_netblocks2.google.com` / `_netblocks3.google.com` で計 4 ルックアップ
- `include:sendgrid.net` … 親 1 + 内部の地域別 include 数個で計 3〜4 ルックアップ
- `include:servers.mcsv.net` … 親 1 + 内部 include で計 2〜3 ルックアップ

合計はおおよそ **9〜11 ルックアップ**。Mailchimp が地域別レコードを増やすタイミングや SendGrid のレンジ追加で簡単に上限を超えます。Microsoft 365 を併用していれば確実に超過します。

### 上限超過時に何が起きるか

評価結果が `permerror` になると、受信側はポリシーに従って処理を変えます。

- Gmail はポリシー次第で **SPF fail と同等**に扱い、迷惑メール判定の対象にする
- Microsoft 365 は SCL（Spam Confidence Level）を上げ、Junk フォルダへ分類しやすくなる
- DMARC 評価では SPF 認証が「失敗」となり、DMARC ポリシーが `quarantine` / `reject` だと配信不可になる

つまり「メールが届かない」「営業メールが迷惑メールに入る」という、ビジネス影響の大きい症状として表面化します。

### 確認方法

現状の include ツリーとルックアップ消費数を可視化するには、次の選択肢があります。

- **無料ツール**: dmarcian SPF Surveyor、MXToolbox SPF Record Lookup、EasyDMARC SPF Checker
- **ドメイン番人の[ドメイン診断](/diagnose)**: include ツリーとルックアップ消費数をワンクリックで確認可能

ツールごとの仕様差については、同 PR で公開予定の SPF オンラインチェッカー比較記事もあわせて参照してください。

![10 ルックアップ上限のチェックフロー](/blog/spf-include-nesting/check-flow.svg)

## 超過していたときの解消フロー

1. **不要 include の削除**: 過去に解約した SaaS や試用しただけのツールが残っていないか確認。半年〜1 年放置で 2〜4 ルックアップ削れる例が多い
2. **サブドメイン分割**: 配信用途を `mail.example.co.jp` などへ切り出し、ルートの SPF を軽量化
3. **SPF フラッタニング**: include を `ip4:` 直書きへ展開してルックアップを消す。詳細は[SPF 10 ルックアップ超過の対処](/blog/spf-flattening)を参照

順序としては「削除 → 分割 → フラッタニング」が安全で、フラッタニングは最終手段です。SaaS 側の IP 変更追従が必要になるため、運用負荷とのトレードオフを理解してから採用してください。

### 中小企業が取り組む際の優先順位

社内に専任のメール管理者がいない中小企業の場合、まず「現在の SPF を一度も棚卸ししたことがない」というケースが圧倒的多数です。実務的には次の順番で進めるのが現実的です。

- 月初に `dig TXT example.co.jp` でレコード本文を取得し、include を 1 行ずつ確認する
- 解約済みツールの include を削除し、変更後 24〜48 時間は配信ログを観察する
- それでも 9 ルックアップ以上残るなら、サブドメイン分割の設計を検討する

レコード変更直後は受信側のキャッシュが更新されるまで 1〜2 時間かかるため、テスト送信は余裕を持って行ってください。DMARC レポートを受け取っていれば、変更後の `spf=pass` 比率を翌日には確認できます。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。