SPFのDNSルックアップ回数を監視する方法｜include追加でPermErrorを防ぐ運用

自社ドメインから送るメールが増えると、Google WorkspaceやMicrosoft 365だけでなく、MA、CRM、問い合わせフォーム、採用管理、請求、サポートなど複数のサービスをSPFへ追加することになります。各ベンダーの手順どおりにincludeを足しても、受信側が評価するDNS参照の合計が上限を超えれば、SPFはPermErrorになり得ます。

SPFの安全余白は、見えているincludeの数ではなく、最も深い評価経路を再帰的に展開した後に残る参照枠で判断します。 include、a、mx、ptr、exists、redirectを依存先まで展開し、変更前後の最長経路、応答のない参照先、外部サービス側のTXT変更を継続して確認するのが基本です。

---

本記事のポイント

1. SPFの10回上限は、1行に見える記述数ではなく、再帰的な評価全体でDNS参照を伴う仕組みを数えます。
2. include追加前は、全送信元の評価経路、最悪経路の参照数、応答不能な参照先、DNS反映後の実送信結果を確認します。
3. 上限接近時は、未使用・重複依存の削除、送信ドメイン分離、安定IPだけの限定的な置換を優先し、変更前の値へ戻せる状態を保ちます。

---

SPFの10回制限は何を数えるか

RFC 7208では、SPF評価中にDNS検索を起こす仕組みとして、include、a、mx、ptr、existsとredirectを合計10回までに制限しています。上限を超えた評価はpermerrorを返します。この上限は「各SPFレコードにつき10回」ではなく、include先がさらに別ドメインをincludeする場合も含めた一つの評価全体に適用されます。

一方、ip4、ip6、allは、この10回制限の対象となるDNS参照を発生させません。expも通常の評価上限には数えません。ただし、レコードを短く見せるために外部サービスのincludeをIPへ機械的に置き換えると、ベンダー側の送信IP変更へ追随できなくなるため、参照回数だけで良し悪しを決めるのは危険です。

記述	10回上限への扱い	運用上の確認点
include	1回として数え、参照先の評価も同じ合計へ加える	参照先がさらにincludeする深さと分岐を確認する
redirect	評価された場合に数え、遷移先も同じ合計へ加える	allがあるとredirectは無視される。管理境界と意図を確認する
a・mx・exists	評価された各仕組みを数える	MXには、各MX名で参照できるA・AAAAアドレス数の別上限もある
ptr	数える	RFCでも使用非推奨。既存レコードに残っていないか確認する
ip4・ip6・all	数えない	IPを直書きする場合は変更責任と更新監視が必要

もう一つ見落としやすいのが、DNSで対象が見つからない「void lookup」です。RFCは、応答が空またはNXDOMAINになる参照を2回までに抑えるべきとし、その上限を超えた場合もPermErrorにすることを定めています。削除済みサービスのincludeや、入力ミスで存在しないドメインが残っていると、総数に余裕があっても別の制限へ近づきます。

受信側はSPFを左から順に評価し、一致した仕組みがあればそこで止まります。そのため、同じレコードでもGoogle Workspaceからのメールは早い位置でpassし、後ろに置いた別サービスだけが深いinclude経路を通ってPermErrorになることがあります。平常時に一つの送信元からテストして通っただけでは、全送信元の安全性を確認できません。

include追加前に確認する判断表

新しい配信サービスを導入するときは、DNS変更チケットに「ベンダーが指定した文字列」だけでなく、変更前後の再帰展開結果を添付します。SPFは同じドメインに複数レコードを置くものではありません。既存の一つのSPFへ、現在も実際に送信しているサービスだけを統合します。

確認項目	追加してよい状態	保留・再設計する状態
送信元の実在	Return-Pathに使うドメインと送信機能が確認できる	導入予定だけで、実際の送信ドメインが未確定
依存ツリー	include先を再帰展開し、全参照先と管理者が分かる	途中に取得不能、循環、存在しない参照先がある
最長評価経路	変更後も10回以内で、運用上の余白を残せる	特定送信元の経路だけ上限到達・超過がある
重複	同じサービス・同じドメインの依存が一度だけ	別名のincludeが同じ依存先へ重なっている
切り戻し	変更前TXT、TTL、担当者、復旧判断を記録済み	現在値の保存や変更権限の確認がない
受信結果	DNS反映後、全送信元の実メールでSPF passを確認	構文チェッカーだけで完了としている

参照回数は、最上位レコードの記述数ではなく「各送信元が実際に通り得る経路」ごとに出します。たとえば、業務メール、MA、問い合わせ通知、請求メールを別々に一覧化し、送信元IPまたは想定ホストから、どの仕組みが左から評価されるかを追います。最大値だけでなく、その経路で使ったinclude先、void lookup、取得したTXTのハッシュも残すと、外部サービス側の変更を差分として検知できます。

Google Workspaceの公式トラブルシューティングも、ネストしたincludeを含めて10回へ収めること、重複する仕組みや送信に使っていない第三者サービスを削除することを案内しています。DNS変更の反映には最長48時間かかる場合があるため、変更直後に古い応答と新しい応答が混在する時間を見込みます。

DNSルックアップを継続監視する7段階

1. 送信元台帳を作る。 ドメイン、Return-Path、サービス名、利用部門、管理者、送信用途、停止予定を記録します。表示FromだけではSPFの対象を特定できないため、実際のメールヘッダーも保存します。
2. 現在のSPFを一つに確定する。 対象ドメインのTXT応答からv=spf1を抽出し、複数存在、構文不良、末尾の方針が意図どおりかを確認します。
3. 依存先を再帰展開する。 includeとredirectの先をたどり、a、mx、exists、ptrも含めて評価経路を作ります。取得不能、循環、空応答は正常値に丸めず、別の警告として残します。
4. 送信元別に最長経路を数える。 左からの評価と一致条件を考慮し、各正規送信元が通り得る経路の最大参照数を出します。運用上の警告値は、将来のベンダー変更を吸収できるようプロトコル上限より低く設定します。
5. 基準値と差分を保存する。 取得日時、全参照ドメイン、TXT値のハッシュ、最長参照数、void lookup数、TTLを保管します。外部include先の値や依存数が変わったら、DNS変更をしていなくても再評価します。
6. 変更前後と定期実行で再検査する。 自社のDNS変更前、反映後、新規送信サービスの本番開始前に必ず実行し、その後も組織で定めた周期で監視します。上限接近、参照不能、レコード複数化を通知対象にします。
7. 実メールで結果を照合する。 すべての送信元から外部受信箱へ送り、Authentication-Results、Return-Path、SPF結果を確認します。構文とDNS参照が正常でも、想定と異なるReturn-PathならSPFは別ドメインで評価されています。

監視結果は「現在8回」のような一つの数字だけにしません。対象送信元、評価経路、依存先、前回との差分を一緒に通知します。これにより、担当者は新サービスの追加が原因なのか、既存ベンダーがinclude先を増やしたのか、削除済みドメインが応答しなくなったのかを判断できます。

SPF passだけでは、表示Fromとの整合やなりすまし対策全体は完結しません。DKIMとDMARCを併用し、DMARC集計レポートの読み方で正規送信元の結果を継続確認します。配信基盤全体の観測項目はメール到達監視ツールの要件、到達率の基礎はメール到達率を改善する考え方も参考になります。

上限接近・PermError時の減らし方と切り戻し

PermErrorを検知したら、いきなりレコードを短縮するのではなく、影響する送信元と評価経路を固定します。変更直前のTXT、TTL、依存ツリー、テスト結果を保存し、まず未使用のinclude、重複している依存、存在しない参照先、非推奨のptrを候補にします。削除対象はサービスの管理者へ送信停止を確認し、メールログとDMARCレポートでも利用実態を照合します。

対処	適する条件	主なリスク
未使用・重複includeの削除	送信停止と利用実態を確認できる	隠れた通知経路を止める可能性
送信ドメイン・サブドメインの分離	用途ごとのReturn-Pathと責任者を分けられる	DKIM、DMARC、バウンス処理も合わせて設計が必要
安定IPへの限定的な置換	ベンダーが固定IPを正式に公開し、変更監視できる	IP変更への追随漏れ。動的な配信基盤には不向き
ベンダー統合・送信機能停止	同じ用途のサービスが重複している	移行中に新旧双方が必要な期間を見落とす
変更前レコードへ切り戻す	変更直後にPermErrorや正規送信元のfailが増えた	新サービス側の送信を一時停止する判断が必要

Microsoft Learnの公式ガイドは、Microsoft 365のincludeを固定IPへ展開しないよう注意しています。Microsoft 365のIPは変更され得るためです。他の外部サービスで安定したIPへ置き換える場合も、ベンダーの公式情報、変更履歴、確認日、担当者を記録し、変更のたびに検査します。

用途ごとにサブドメインを分ける方法は、各ドメインに独立したSPF上限を持たせられます。ただし、見かけ上の上限回避だけを目的にすると、Return-Path、DKIMセレクタ、DMARCアライメント、バウンス管理がばらばらになります。取引メールとマーケティングメールを分ける設計は、トランザクションメールとマーケティングメールの分離手順のように、送信責任と監視までまとめて行います。

切り戻し条件は変更前に決めます。たとえば、正規送信元でPermErrorまたはfailが発生した、参照不能ドメインが増えた、最長経路が想定値を超えた場合です。DNS反映中は新旧応答が混在するため、変更前のポリシーでも正規メールが通る移行期間を確保します。切り戻した後は、配信キューをむやみに再送せず、影響時間帯、送信元、受信結果、バウンスを照合します。ブロックが発生した場合の復旧はメールブロックリスト登録時の初動も参照してください。

SPFのDNSルックアップ監視でよくある質問

関連ページと関連記事

• メール到達率を改善する方法
• DMARC集計レポートの読み方
• メール到達監視ツールの要件
• トランザクションメールとマーケティングメールの分離手順
• メールブロックリスト登録時の初動