SPFメール認証運用

SPFレコード10ルックアップ超過の対処

2026年5月1日ドメイン番人約 4 分で読めます

この記事でわかること

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

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

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

カウントされる 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 ルックアップ制限

超過しやすい典型ケース

よくある配置:

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 レコードの書き方もあわせて参照してください。

回避策 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 フラッタニングの仕組み

自動化サービス

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 レコード生成ツールで DNS 参照数を数えながら下書きを作れます（ip4: は参照数を増やしません）。

切り替え後の確認

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

まとめ

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

SPF 状態を診断

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