ドメイン番人
SPFメール認証DNSトラブルシューティング

SPF include 入れ子と10ルックアップ計上

ドメイン番人約 5 分で読めます
目次

この記事でわかること

  • 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 レコードの書き方を一読しておくと理解が早くなります。

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

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

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

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

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

include 入れ子のツリー構造

典型ケース: 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
  • ドメイン番人のドメイン診断: include ツリーとルックアップ消費数をワンクリックで確認可能

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

10 ルックアップ上限のチェックフロー

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

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

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

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

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

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

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

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

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

関連記事

次の一歩は無料診断から。

無料診断を試す →相談したい方はこちらから