SPF の参照上限：入れ子と送信経路を確認

SPF の DNS 参照上限は、配送に問題が出るまで見過ごされやすい DNS の課題です。送信サービス、CRM、ヘルプデスクを追加すると、SPF 評価がプロトコル上の上限を超え、通常のメールが判定対象になったり、遅延や拒否を受けたりする可能性があります。

SPF が全体構成で果たす役割は、ビジネスメールから確認できます。SPF はブランドの表示設定ではなく、受信側がメールを評価する際の認証手段の一つです。

このガイドでは、SPF の参照上限、数に含まれる項目、手動フラット化の維持責任、今後の成長にも対応しやすい構成を説明します。

SPF の DNS 参照上限とは

SPF の DNS 参照上限は、SPF 評価で DNS 参照を必要とする対象メカニズムと修飾子の数を制限します。RFC 7208では上限は 10 で、超過すると成功ではなく permerror を返します。

つまり SPF には参照予算があります。DNS 参照が必要な対象項目を 10 より多く評価した場合、実装は恒久エラーで評価を終える必要があります。Gmail 独自の挙動ではなく、SPF 標準の要件です。

RFC 7208 は対象項目を明示しています：include、a、mx、ptr、exists、redirect です。ip4、ip6、all 自体の評価では、この種の参照を必要としません。

この区別は重要です。レコードの長さばかり見ても評価コストは分かりません。短いレコードでも失敗し、長いレコードでも成功する場合があります。実際に評価される経路の負荷が問題になります。

何が SPF の参照上限に含まれるか

SPF の DNS 参照上限は、TXT レコードの単語数ではなく、DNS 参照を必要とするメカニズムと修飾子を数えます。入れ子の include も含むため、DNS 管理画面に見える数より、受信側が評価する数が多い場合があります。

以下の項目が予算を消費します：

include：別ドメインの SPF を評価し、そこで pass なら include が一致する場合があります。
a：ホスト名を IP アドレスに解決し、接続元と比較します。
mx：MX レコードと、そのサーバーのアドレスを解決します。
ptr：逆引き名を使いますが、利用は推奨されません。
exists：指定された A レコードの参照が結果を返すか確認します。
redirect：どのメカニズムも一致しない場合、別の SPF ポリシーに評価を引き継ぎます。

次の項目自体は SPF の参照予算を消費しません：

ip4
ip6
all

注意すべきなのは再帰です。自分のレコードが Microsoft を含み、その SPF がさらに別レコードを含む場合、対象となる下流の項目も合計に含まれます。事業者の SPF 構造が、自分の構成の依存関係になります。

6 個の送信サービスを追加したつもりでも、再帰後には 11 または 12 個の対象項目を評価する必要があるかもしれません。10 未満のつもりで SPF 上限を超えるのは、こうした場合です。

成長するチームが上限を超える理由

SPF の DNS 参照上限の問題は、ホスティング変更だけでなく、ツール追加後にも起こります。マーケティング、サポート、採用、CRM、トランザクション送信サービスが、利用するエンベロープドメインの SPF にそれぞれ include を求めます。そのドメインがルートドメインであることも少なくありません。

初期のレコードはシンプルです。以下の事業者値は例示であり、最新の案内を確認せずそのまま使わないでください：

v=spf1 include:_spf.google.com ~all

その後、ツールが増えます：

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com include:spf.hubspot.com include:amazonses.com ~all

この段階では、単独の送信ポリシーではなく、自分の管理外で変化する依存関係の連鎖を扱っています。

本番環境で上限の問題が突然起きたように見えるのはそのためです。自分の DNS を変えていなくても、事業者が内部 SPF を変更すると、昨日成功したメールが今日 permerror になる可能性があります。

問題が SPF 以外にも及ぶなら、TrekMail のメールが迷惑メールになる理由も確認してください。認証の不備と送信者評価の問題が併存する場合があります。

SPF の参照上限を超えたらどうなるか

SPF の DNS 参照上限を超えると、評価は permerror を返します。受信側の処理は一律ではありませんが、正常な SPF 成功ではなく、エラーの認証結果を渡すことになります。

これは運用で過小評価されがちです。上限に近いところまで守っていても、部分的な成功にはなりません。

状態	受信側の結果	考えられる影響
対象参照項目が 10 未満	予算内。ただし別のエラーはあり得る	適切なメカニズムに一致すれば SPF が成功できる
対象参照項目が 10 超	Permerror	メールがフィルター、遅延、拒否の対象になる場合がある
SPF permerror と DKIM fail	ほかの有効な署名がなければ、成功したアライン済み認証経路がない	DMARC が失敗する可能性があり、処理は受信側による
SPF permerror と DKIM pass	認証方法ごとに結果が異なる	有効でアラインした DKIM なら DMARC は成功できる

Google の送信要件も認証とアラインメントに関係します。Gmail へ大量に送る場合は、適用要件に沿って SPF と DKIM を監視し、SPF を不要な配管設定と考えないでください。認証成功は受信トレイ到達の保証ではありません。Google のメール送信者ガイドラインを参照してください。

関連する制限も二つあります：

結果が空の参照、void lookups。RFC 7208 は実装でこれを二回に制限することを推奨しています。include の誤記や廃止されたドメインが、名前不存在や必要な応答の欠如を返すと、permerror に関係する場合があります。
DNS 応答サイズ。大きな応答は切り詰められ、別の転送方式が必要になる場合があります。問題のあるネットワークでは一時エラーやタイムアウトも起こり得ます。

SPF のフラット化が常に最適とは限らない理由

SPF の DNS 参照上限に直面すると、include を直接 IP に置き換えるフラット化が簡単に見えます。その項目の参照予算は不要になりますが、新しい維持責任が生じます。

手動フラット化の例です：

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

評価コストは低くても、SaaS 事業者は基盤を変更し、範囲を追加し、供給元を変えます。古いレコードでは正規送信が許可されなくなったり、廃止範囲が長く許可されたままになったりする可能性があります。

維持しにくい方法は、事業者をルート SPF に詰め込み、複雑になるたびに IP を手動で展開することです。

より整理された方法は、送信機能を適切なサブドメインへ分け、ポリシーを狭く保ち、アラインした DKIM を使うことです。SPF には実際のエンベロープドメインの分離が必要で、可視の From 変更だけでは効果がありません。責任範囲が見えやすくなりますが、評判の完全な分離は保証されません。

TrekMail がこの構成を管理しやすくするかはプランによります。現行ドキュメントでは独自ドメイン、IMAP メールボックス、catch-all、移行、転送、BYO SMTP またはマネージド SMTP が案内されています。無料プランの BYO SMTP と有料プランのマネージド SMTP の有無は、最新条件を確認してください。機能と課金はプラン次第です。DNS は必要な DNS レコード、送信手段は独自 SMTP（BYO）に記載されています。

SPF 上限に対応する持続可能な方法

SPF の DNS 参照上限への長期的な対策として、送信経路の分離が役立つ場合があります。社内の通常メール、マーケティング、サポート、トランザクションメールが別のエンベロープサブドメインを使えば、それぞれの SPF 評価に予算を持たせられます。DMARC のアラインメントも確認します。relaxed では適切な組織ドメインを基準にでき、strict では完全一致が必要です。評判への影響は別途監視します。

構成例：

ルートドメインを個人の業務メールに使う。例：alice@company.com。
マーケティング用サブドメイン。例：newsletter.company.com。
サポート用サブドメイン。例：support.company.com。
トランザクション用サブドメイン。例：updates.company.com。

以下は例示です。事業者の最新値を確認し、そのまま適用しないでください：

company.com TXT "v=spf1 include:_spf.google.com ~all"
newsletter.company.com TXT "v=spf1 include:servers.mcsv.net ~all"
support.company.com TXT "v=spf1 include:mail.zendesk.com ~all"
updates.company.com TXT "v=spf1 include:sendgrid.net ~all"

実際に別々に評価するエンベロープドメインには、それぞれ 10 個の対象項目の予算があります。一つの過密な SPF への共通依存を減らせる場合がありますが、各レコードの確認は引き続き必要です。

分離は評判の分析にも役立ちます。ただし、悪いマーケティング慣行が共有 IP や組織ドメインの評価を通じて別経路に影響する可能性があります。評判の防火壁が自動でできるわけではありません。

新規ドメインには TrekMail のドメインの追加と DNS 検証が参考になります。旧事業者から移る場合、IMAP 移行の概要にある機能はメールボックスデータをコピーできます。ただし DNS、アプリ設定、送信経路は自動で移らず、無停止の移行も保証されません。

SPF の参照予算を確認する方法

SPF の DNS 参照上限は推測でなく測定します。元の TXT を取得し、include と入れ子レコードを追い、想定する評価経路のコストを確認してください。

まず dig を使います：

dig txt example.com +short

dig txt _spf.google.com +short

dig txt spf.protection.outlook.com +short

続いて実行経路の対象 DNS 参照項目を、入れ子も含めて数えます。一致した時点で評価が終わる場合があるため、実際の送信 IP も使って調べます。

実用的な手順：

実際のエンベロープドメインまたはサブドメインの SPF TXT を取得する。
include、a、mx、exists、redirect を列挙する。非推奨の PTR があれば、それも含める。
入れ子 SPF を解決し、調査を繰り返す。
メールを送らなくなったと確認できるツールを除く。
手動フラット化の前に、適切な送信経路を実際のエンベロープサブドメインへ分けることを検討する。

同じ名前の SPF 重複も確認します。TrekMail は同じホストで複数 SPF を公開せず、許可送信元を単独の SPF TXT レコードにまとめるよう案内しています。一つの TXT レコードが複数の文字列に分かれている場合は、別レコードの重複とは異なります。関連資料はドメインでメールを作成する方法、複数ドメインのメールホスティング、imapsyncです。

整理された構成での TrekMail の役割

TrekMail はSPF の DNS 参照上限をなくしません。ホスティングサービスがプロトコルの制限を撤廃することはできません。ただし、機能によって制限を考慮した設計を支援できる場合があります。

特に二つの利用者層に関係します。

個人創業者や小規模チームはルートドメインの業務メールを簡潔なポリシーに保ち、必要に応じて BYO SMTP やマネージド SMTP を選べます。代理店や MSP は顧客経路を分け、ドメイン登録をまとめて管理できます。費用やアカウント管理の削減効果は利用状況とプランによります。

従来型と整理された方法：

従来型：追加メールボックスやドメインの費用を理由に、業務メール、エイリアス、アプリ、マーケティングを同じ事業者と SPF に集める。

整理された方法：複数ドメインの基盤で IMAP メールボックスをまとめつつ、実際のエンベロープサブドメインで送信を分け、事業者の変更後にも SPF を確認する。

本文の条件では Starter は月額 $3.50 からです。無料プランは $0、10 ドメイン、5GB の共有ストレージ、BYO SMTP と記載されています。有料プランにはマネージド SMTP、より高い上限、追加の自動化が含まれる場合があります。最新条件を確認し、TrekMail の料金で構成費用を比較してください。

まとめ：SPF の参照上限を設計条件として扱う

SPF の DNS 参照上限は特殊な例外ではなく、プロトコルの固定要件です。ツールが増えるなら、超過してからではなく定期的に評価コストを確認してください。

permerror が出るまで待たず、送信元を一覧にし、不要な include を除き、適切な経路を実際のエンベロープサブドメインへ分けます。ルートドメインは簡潔に保ちましょう。重要な業務メールのリスクを減らす助けになりますが、配送は保証されません。

一つまたは多数のドメインでこの構成を運用するため、TrekMail は現行プランに応じて独自ドメイン、IMAP メールボックス、共有ストレージ、移行、各種 SMTP 手段を提供します。費用と制限はプラン次第です。無料開始の条件はtrekmail.net、比較はtrekmail.net/pricingで確認してください。