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

- SPF の 10 ルックアップ制限とは何か
- 制限超過で起きる Permerror と影響
- フラッタニング・サブドメイン分割など現実的な回避策

## 10 ルックアップ制限の正体

SPF(RFC 7208)は、受信側が送信元 IP を検証するときに DNS への問い合わせ回数を **最大 10 回** に制限しています。これを超えると検証結果が `permerror`(永続的エラー)となり、Gmail や Outlook ではポリシーによっては **SPF fail と同等扱い** で迷惑メール判定の対象になります。ルックアップ超過は PermError の一因に過ぎず、ほかの原因とあわせて[SPF が PermError になる5つの原因](/blog/spf-permerror-causes)で整理しています。

### カウントされる SPF 機構

- `include:` (例: `include:_spf.google.com`)
- `a:` 機構
- `mx:` 機構
- `exists:` 機構
- `redirect=`

`include:` は **入れ子で再帰的にカウント**されます。たとえば `include:_spf.google.com` は内部で 4〜5 個の `include:` を呼ぶため、それだけでルックアップを 5 個程度消費します。

### カウントされない要素

- `ip4:` `ip6:` (DNS 問い合わせを伴わないため何個書いても OK)
- `all` 機構

つまり **IP 直書きはノーカウント**、これが回避策の核心になります。

![SPF 10 ルックアップ制限](/blog/spf-flattening/lookup-count.svg)

## 超過しやすい典型ケース

よくある配置:

```
v=spf1 include:_spf.google.com include:spf.protection.outlook.com
       include:_spf.salesforce.com include:sendgrid.net
       include:mailchimp.com include:_spf.kintone.com -all
```

これだけで実質 12〜18 ルックアップ。Google Workspace と Microsoft 365 を併用、SaaS が複数、配信ツールも複数、というありがちな構成で簡単に超えます。

`/diagnose` 等の検証ツールで現状の SPF ルックアップ数を確認してから手を打つのが安全です。SPF 設定の基本は[SPF レコードの書き方](/blog/spf-setup-guide)もあわせて参照してください。

## 回避策 1: 不要な include を削除

最も効果的かつ推奨される対応です。

- 過去に解約した SaaS の include が残っていないか
- 試用しただけのメール配信ツールの include が残っていないか
- 重複した include がないか

これだけで 2〜4 ルックアップ削れることが珍しくありません。SaaS 解約時に SPF 整理を忘れる中小企業は多く、半年から 1 年放置で容量超過しているケースが目立ちます。

## 回避策 2: SPF フラッタニング(平坦化)

`include:` を全部展開して **`ip4:` 直書きに変換**する手法。`ip4:` はルックアップにカウントされないため、何個並べても問題ありません。

### メリット

- 即効性がある(SPF レコードを書き換えるだけ)
- DNS レコード 1 件で完結

### デメリット

- **SaaS 側が IP を変更すると SPF が壊れる**(配信失敗)
- DNS レコードが長大化し、TXT 1 レコードに収まらなくなる場合あり(連結記述の制約)

![SPF フラッタニングの仕組み](/blog/spf-flattening/flattening-flow.svg)

### 自動化サービス

EasyDMARC、Valimail、PowerDMARC などのサービスは、フラッタニング後の SPF を **動的に更新**してくれます。月額数千円から IP 変更追従の手間を肩代わりするため、自前運用が難しいWeb 担当者向け。ただしランニングコストが発生します。

## 回避策 3: サブドメイン分割

ルートドメインの SPF を最小限にし、用途別にサブドメインを分ける戦略です。

```
example.co.jp        → 社員のメール (Google Workspace)
mail.example.co.jp   → 配信ツール (SendGrid, Mailchimp)
notify.example.co.jp → 通知メール (Salesforce)
```

それぞれのサブドメインで個別の SPF レコードを持つため、ルックアップ枠を消費せずに済みます。配信ツール側の Header From をサブドメインに変える必要がありますが、根本解決として最も筋が良い方法。

## 回避策 4: ip4 直書きの部分採用

サードパーティの IP レンジが安定しているなら、`include:` の代わりに `ip4:` を直書きする選択もあります。たとえば AWS SES のように IP レンジを公式に公開しているサービスは候補。ただし監視と更新の運用負荷を負う前提です。`ip4:` 中心のレコードを組み立てるなら、[SPF / DMARC レコード生成ツール](/tools/dns-record-generator)で DNS 参照数を数えながら下書きを作れます（`ip4:` は参照数を増やしません）。

## 切り替え後の確認

レコード変更後は **DMARC レポートで SPF 検証結果を必ず確認**してください。一時的に既存のメールが fail することがあります。レポートの読み方は[DMARC レポートの見方](/blog/dmarc-report-reading)を参照。

## まとめ

- SPF は DNS ルックアップ 10 回まで。超過で Permerror、配信不可リスク
- まず不要 include の削除、次にサブドメイン分割、必要ならフラッタニング
- 変更後は必ず DMARC レポートで検証

## SPF 状態を診断

無料の[ドメイン診断](/diagnose)で、現在のルックアップ消費数・リスクの高い include を 3 分でチェックできます。10 個に近づいているドメインは早めの整理をおすすめします。