SPF の参照回数制限: 数え方と超過の対処法

SPF の参照回数制限の要点は単純です。SPF ポリシーの評価で DNS 参照を発生させる項が 10 個を超えると、受信側は処理を中止して恒久的なエラーを返すことがあります。DNS 管理画面では正常に見える設定でも、実際の認証に失敗する可能性があるのです。ドメインメールを整理しているなら、まず小規模企業向けのビジネスメールを読み、その後で問題が表面化しやすいこの部分を見直してください。

多くのチームが同じ状況に陥ります。Google Workspace に続いて Microsoft 365、Mailchimp、CRM、ヘルプデスクを追加し、そのたびに「この include を追加するだけです」と案内されます。数か月後、SPF レコードの構文は正しくても、運用時の評価でエラーが発生します。メールが迷惑メールに振り分けられたり、一部が返送されたりしても、レコードを一見しただけでは原因がわかりません。

幸い、対処はたいてい地道な整理です。不要な項を削除し、本当に必要な場合以外は `mx` を使わず、マーケティングメールをサブドメインへ移してください。メインドメインの設定は簡潔に保ちます。

SPF の参照回数制限とは？

SPF の参照回数制限は、評価中に DNS 参照を発生させる SPF の項について RFC が定める上限です。受信側は、ネストした `include` の連鎖も含め、評価経路全体で 10 個を超える対象項を処理してはいけません。ポリシーが上限を超えると SPF は `permerror` を返すことがあり、メールは重要な認証結果を得られなくなります。

この規則はRFC 7208で定義されています。SPF が大量の DNS トラフィックを発生させたり、DNS 増幅に悪用されたりするのを防ぐためのものです。任意の推奨事項ではなく、プロトコルの制限です。

見落としがちなのは、SPF の参照回数制限が累積で適用されることです。最上位のレコードで 10 回、各 include の中でさらに 10 回使えるわけではありません。実際の評価経路全体で共通の枠を使います。

SPF のメカニズム	参照の負担	実務上の判断
`include:`	1	一般的だが、ネストした include で負担が増えやすい
`a`	1	小規模な構成では使えるが、不要なことも多い
`mx`	1+	送信元を許可する用途には通常向かない
`ptr`	1+	使用を避ける。RFC 7208 も強く非推奨としている
`exists`	1	使用例は少なく、設定を誤りやすい
`redirect=`	1	特定の設計では有効だが、制限に数えられる
`ip4` / `ip6`	0	SPF 評価時に DNS を参照しない
`all`	0	最終的な方針のみを指定し、参照は発生しない

正常に見えるレコードが参照回数制限で失敗する理由

SPF の参照回数制限では、最上位の TXT レコードの見た目は重要ではありません。実際の評価経路で include、redirect、`a`、`mx` などの DNS を使う項がどれだけ処理されるかが問題です。表の負担は簡略化した目安であり、実際の DNS パケット数そのものではありません。

例を見てみましょう。

`v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all` を公開して、参照は三つだけだと考えたとします。しかし、Google や Microsoft のレコードは、その先で別のレコードを参照することがあります。表示されるレコードが短くても、評価経路まで短いとは限りません。

そのため、SPF の参照回数制限の問題は初日ではなく後から現れることがあります。ベンダーが自社の SPF ツリーを変更すると、自分では DNS を編集していなくても、評価時の負担が増える可能性があります。

もう一つの落とし穴は、空の参照、いわゆる void lookup です。RFC 7208 は、実装がこれを二つまでに制限することを推奨しています。データのない応答や `NXDOMAIN` を返す DNS 参照が対象です。include の誤記が一つなら必ず失敗するとは限りませんが、無効な参照が二つあると問題になることがあります。すると、SPF の参照回数制限に加え、総数がまだ 10 未満でも `permerror` のリスクが生じます。

Google が公開している送信者要件も、認証の重要性を示しています。一括送信者の認証が不足していたり壊れていたりすると、迷惑メールへの振り分けや受信拒否につながる可能性があります。Google の文書では、こうした送信者に SPF、DKIM、DMARC を求めており、要件を満たさないメールは拒否または迷惑メールに分類されることがあります。Google の送信者要件に関する FAQを参照してください。

SPF の参照枠の使用量を計算する方法

SPF の参照回数制限を調べるには、最上位の SPF レコードから、実際の評価経路で DNS 参照を発生させる項を数えます。自分の設定だけでなく、ベンダーのレコードの下位参照も対象です。再帰ツリーを展開して想定される経路を調べ、実際に評価される経路が 10 を超えるなら、認証に失敗する可能性があります。

最上位のレコードから確認します。

dig +short txt example.com

出力例:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

続いて、参照先のドメインをそれぞれ調べます。

dig +short txt _spf.google.com

dig +short txt spf.protection.outlook.com

`ip4`、`ip6`、または評価を終えるポリシー項だけになるまで追跡してください。

次の方法で数えます。

実際に評価する include、a、mx、ptr、exists、redirect をそれぞれ数えます。
include 先のレコードで評価されるネストした項も数えます。
ip4、ip6、all は数えません。
データを返さない include の参照先を記録します。空の参照による問題の原因になり得ます。

TrekMail でドメインを設定する際に DNS を手早く確認するなら、DNS ステータスの確認と必要な DNS レコードの文書から始めるとよいでしょう。

SPF の参照回数制限でよくある設定ミス

SPF の参照回数制限の問題は、多くの場合、同じミスの積み重ねで起きます。メインドメインにベンダーを追加し続ける、古いプロバイダーを残す、`mx` で許可を済ませる、更新手順なしに手作業でフラット化するといったものです。特殊な技術問題というより、DNS 設定の保守不足が規模の拡大とともに表面化します。

主な例は次のとおりです。

ミス	問題点	改善策
古いベンダーを残す	参照枠を浪費し、リスクを広げる	送信に使わなくなったサービスを削除する
送信許可に `mx` を使う	受信用 MX ホストが送信元とは限らない	実際の送信元を明示的に許可する
`ptr` を使う	遅く、非推奨で、障害を招きやすい	削除する
すべて同じドメインから送る	マーケティングとトランザクションメールが SPF の枠を共有する	サブドメインごとにメールの流れを分ける
手作業でフラット化する	ベンダーが IP を変更すると認証が失敗し得る	更新を自動化するか、フラット化を避ける

表示上の複雑さと実際の複雑さを混同しがちな点にも注意が必要です。ベンダーの include が一つでも、展開すると複数の参照項を消費することがあります。SPF の参照回数制限がある以上、「送信サービスをもう一つ追加するだけ」という判断は危険です。

業務に転送、エイリアス、独立したメールボックスのどれを使うかも、送信元の設定と密接に関係します。関連記事としてドメインメールのエイリアスとメールボックスの違い、メールエイリアスによる転送も参照してください。

メールへの影響を抑えて SPF の参照回数を減らす方法

SPF の参照回数制限に対処するには、対症療法を重ねるより、ポリシーを簡素化するほうがリスクを抑えやすくなります。まず不要な送信元を削除し、次に大量送信するシステムをサブドメインへ移します。フラット化は、自動更新を維持できる場合に限って検討してください。

1. 不要な設定を取り除く。

使っていないベンダーと `ptr` を削除します。`mx` は、必要な送信元を明示的に許可する設定に置き換えます。一度整理するだけで、問題のあるポリシーがSPF の参照回数制限内に戻ることもあります。

2. サブドメインでメールの流れを分ける。

成長中のチームでは、これが実用的な対策になりやすいでしょう。

; Primary company mail
example.com.              TXT  "v=spf1 include:spf.trekmail.net -all"

; Marketing mail
marketing.example.com.    TXT  "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"

; Transactional app mail
notify.example.com.       TXT  "v=spf1 include:amazonses.com -all"

各サブドメインには独自の SPF ポリシーと参照枠があります。メインドメインの負担を減らし、SPF の参照回数制限を管理しやすくできます。

3. フラット化は最後の手段にする。

フラット化では、include を直接指定した IP 範囲に置き換えます。

; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all

; After
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

参照の負担をほぼゼロに減らせますが、保守作業が増えます。ベンダーが IP を変更するとレコードが古くなり、認証に失敗する可能性があります。フラット化するなら更新を自動化してください。

従来の方法と新しい方法: TrekMail で参照回数制限を管理する

SPF の参照回数制限への従来の対応は、メールボックス業者、マーケティング基盤、リレーをメインドメインに追加し続け、DNS 設定の経緯がわからなくなるようなものでした。新しい方法は依存関係を減らし、送信元の役割を最初から分離します。

従来の方法: 混み合ったメインドメインの SPF レコードに古いプロバイダーが残り、マーケティングと日常のメールが混在し、送信許可の管理責任も曖昧になります。

新しい方法: メールボックスのホスティングを簡潔にし、大量送信をサブドメインへ分離して、メインドメインの SPF ポリシーに余裕を持たせます。

TrekMail は、この構成の簡素化に役立つ可能性があります。有料プランの管理された送信について、説明されている DNS 設定では SPF に `include:spf.trekmail.net` を追加します。この include 自体は一つの参照項として数え、下位の参照は別途確認します。紹介されている料金は月額 $3.50 からで、独自ドメイン、IMAP メールボックス、キャッチオール、転送、組み込みの移行ツール、API アクセスが記載されています。有料プランにはクレジットカードが必要な 14 日間の無料試用が案内されています。Nano は試用ではない継続無料のプランとして説明され、BYO SMTP を使います。利用前に最新の料金、機能、条件を確認してください。

Nano では TrekMail をメールボックス層として使い、送信は SES、Mailgun、その他のリレーに任せる構成も考えられます。メインのポリシーがSPF の参照回数制限を超えないよう、サブドメインを整理してください。運用については TrekMail のカスタム SMTP（BYO）、管理された TrekMail SMTP、ダッシュボードからの移行開始の文書で確認できます。

ドメインを集約する場合は、複数ドメインのメールホスティングと自分のドメインでのメール設定も参考になります。

まとめ: SPF の参照回数制限を超えないために

SPF の参照回数制限を守るには、SPF を必要以上に複雑にしないことが大切です。メインドメインの送信元は必要なものに絞り、一括送信やアプリのメールはサブドメインへ移します。新しいツールを追加するたびにベンダーの include を再確認し、ポリシーが 10 に近づいたら早めに負担を減らしてください。

SPF の参照回数制限は RFC 上だけの特殊な話ではなく、運用上の厳格な制約です。ベンダーを追加し続けると管理が難しくなります。レコードを短く保ち、DNS の管理責任を明確にしてください。五つのベンダーで限られた認証経路を共有すると、夜中の 2 時までメールヘッダーを調べることになりかねません。

構成を簡素化したい場合、TrekMail ではユーザーごとの課金ではない定額の複数ドメインホスティング、共有ストレージ、組み込みの IMAP 移行、BYO SMTP または TrekMail 管理の SMTP が案内されています。最新の提供内容はTrekMail の料金ページで確認するか、TrekMailへアクセスしてください。