SPFフラット化：10回のルックアップ上限を解消する

10回のルックアップ上限とは

SPF（Sender Policy Framework）は、受信側メールサーバーがSPFレコードを解決するために10回を超えるDNSルックアップを実行しなければならない場合に、permerrorで失敗します。これは入れ子になったincludeステートメントが原因で起こります。レコードがあるプロバイダーをincludeし、そのプロバイダーがさらに別のサービスをincludeしていると、その各段階が上限にカウントされます。これを解消するには、再帰的なルックアップを静的なIPアドレスの一覧に置き換えるSPFフラット化を使う必要があります。

到達率を管理するエンジニアとして、この問題が最もよく表面化するのは「ベンダーの乱立」のときだと感じています。会社はまず1つのトランザクションメールのプロバイダーから始め、マーケティングツールを追加し、CRMを追加し、気づけばSPFレコードは砂上の楼閣になっています。11回目のルックアップが発生すると、受信側サーバーは検索をやめて恒久的なエラーを返します。つまり、メールは迷惑メールと判定されるだけでなく、認証チェックが根本的に失敗したために、完全に拒否される可能性があります。

ルックアップ上限の仕組み

RFC 7208によると、この上限はDNSインフラに対するサービス拒否（DoS）攻撃を防ぐために存在します。上限がなければ、悪意のある攻撃者が循環参照や膨大なincludeの連鎖を作り、1通のメールのために受信側サーバーに何百回ものクエリを実行させることができてしまいます。

何がルックアップとしてカウントされるか

SPFレコードのすべてのメカニズムがタダというわけではありません。次のものはDNSクエリを発生させます。

• include：最もよくある原因です。別のドメインのSPFレコードを参照するようサーバーに指示します。
• a：ドメインのAレコードを照会します。
• mx：ドメインのMXレコードを照会します。
• ptr：逆引きDNSを照会します（ただし非推奨であり、使用は避けるべきです）。
• exists：特定のドメインが存在するかを照会します。

ip4やip6のようなメカニズムは、IPアドレスがレコードに明示されているため、ルックアップを消費しません。

ルックアップの連鎖の構造

次のような仮のSPFレコードを考えてみましょう。

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

表面上は3回のルックアップです。しかし、_spf.google.comにさらに3つのincludeステートメントが含まれ、spf.protection.outlook.comに4つ含まれていれば、すでに10回に達しています。SendHQのレコードにもincludeがあれば、上限に達します。これが「includeの連鎖」です。

permerrorを特定する

上限に達しているかどうかわからない場合は、SendHQのメールDNSチェッカーでレコードを検証できます。生のログやヘッダー分析ツールでは、次のような結果が表示されます。

spf=permerror (too many DNS lookups)

これはsoftfail（~all）やfail（-all）とは異なります。permerrorは、SPFチェックを完了できなかったことを意味します。この場合、受信側は送信者が認可されているかを検証できないため、メールが破棄されたり、厳格なフィルターで判定されたりすることがよくあります。

SPFフラット化とは

SPFフラット化とは、すべてのinclude、a、mxメカニズムを解決し、ip4とip6のアドレスのフラットな一覧に変換する処理です。

例：変換前と変換後

変換前（再帰的）：

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

（_spf.example.comが1.2.3.4に、_spf.vendor.comが5.6.7.8に解決されると仮定します）

変換後（フラット化）：

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

レコードをIPの一覧に変換することで、ルックアップ回数は2回（またはそれ以上）から0回に減ります。受信側サーバーはすぐにIPを確認でき、追加のDNSクエリなしに送信者を検証できます。

フラット化のトレードオフ

フラット化は強力な解決策ですが、大きな保守負担を伴います。

1. IPが古くなる問題

includeステートメントを使う場合、IPアドレスの管理をプロバイダーに委ねています。Amazon SESやSendGridがインフラに新しいIPレンジを追加すれば、各社が自社のSPFレコードを更新するので、メールは引き続き送信されます。

これらのレコードを自社のDNSにフラット化すると、それらのIPの管理責任は自分たちに移ります。プロバイダーがIPを変更したのに、フラット化した一覧を更新しなければ、メールはSPF認証に失敗します。大量のトランザクションメールで手作業のフラット化が危険なのは、主にこのためです。

2. レコード長の制限

DNSレコードには最大長があります。TXTレコード内の1つの文字列は255文字に制限されています。複数の文字列を連結することはできますが、古いDNSパーサーの中には、非常に長いレコードをうまく扱えないものがあります。多くのプロバイダーをフラット化しすぎると、SPFレコードが大きくなりすぎて正しく処理されなくなる可能性があります。

includeの連鎖を解消する方法

10回のルックアップ上限に達している場合は、最も安全なものから最も踏み込んだものへと、次の順に解決策を試してください。

ステップ1：監査と整理

レコードに過去のプロバイダーが残っていないか確認してください。3年前に使うのをやめたサービスのincludeステートメントが今も残っているチームは少なくありません。代理でメールを送信しなくなったプロバイダーはすべて削除します。

ステップ2：トラフィックごとにサブドメインを使い分ける

これはアーキテクチャとして最も本格的な解決策です。すべてのサービスをルートドメインに置くのではなく、用途ごとに分けます。

• ルートドメイン（example.com）：社内メール（Google Workspace/Outlook）。
• トランザクション用サブドメイン（mail.example.com）：SendHQまたはAmazon SES。
• マーケティング用サブドメイン（news.example.com）：MailchimpまたはKlaviyo。

各サブドメインは、それぞれ独自のSPFレコードと、独自の10回のルックアップ上限を持ちます。これによりリスクが分離され、マーケティングツールの複雑なSPFの連鎖が、重要なトランザクションメールを壊すことを防げます。

ステップ3：動的SPFフラット化

動的フラット化とは、プロバイダーのincludeの連鎖をリアルタイムで監視し、DNSレコードを現在のIPアドレスで自動的に更新するサービスです。API経由で更新処理を自動化することで、「IPが古くなる」問題を解決します。

現代のメール配信におけるSPF

SPFは送信ドメイン認証というパズルの1ピースにすぎないことを理解しておくことが重要です。メールが受信側サーバーに受け付けられるようにするには、SPFをDKIMやDMARCと連携させる必要があります。これらの関係の詳しい解説は、SendHQのDKIM、SPF、DMARCガイドにあります。

受け付け、配信、受信トレイへの到達の違い

エンジニアとして、私は次の3つの段階を区別しています。

1. 受け付け：受信側サーバーが接続とメッセージを受け付けます。SPFのpermerrorにより、サーバーがSMTPレベルでメッセージを拒否することがあります。その場合、メッセージは受け付けられません。
2. 配信：メッセージが受け付けられ、ユーザーのメールボックス（またはフォルダ）に移されます。
3. 受信トレイへの到達：メッセージが迷惑メールフォルダではなく、メインの受信トレイに入ります。

SPFフラット化が解決するのは受け付けの問題です。受信トレイへの到達を保証するものではありません。受信トレイへの到達は、送信者レピュテーション、コンテンツ、エンゲージメント指標によって決まります。

AIエージェントに関する特別な考慮事項

API経由でメールを送信するAIエージェントが増えるにつれ、SPFの問題が起こるリスクも高まります。エージェントはさまざまなドメインから大量のメールを送信する可能性があるためです。エージェントのワークフローを構築する際は、メール送信を外部への副作用として扱ってください。

冪等性と承認

エージェントに、安全機構なしでループの中でメールを送信させてはいけません。冪等キーを使い、エージェントの再試行ロジックによって同じトランザクションメールが顧客に10回送信されることがないようにしてください。さらに、重要度の高いメールについては、API呼び出しの前にヒューマン・イン・ザ・ループの承認ステップを導入してください。

送信プロバイダーのコスト分析

SPFレコードにincludeするプロバイダーを選ぶ際は、送信量に応じたコストも考慮してください。2026年9月時点の料金に基づくと、次のとおりです。

• Amazon SES：à-la-carteで1,000通あたり0.10 USDです（Amazon SESの料金）。50,000通ならおよそ5 USDです。2026年7月21日に導入された新しい料金プランには、Essentials（1,000通あたり0.16 USD）、Pro（1,000通あたり0.22 USDに加えて105 USD/月/リージョン）、Enterprise（1,000通あたり0.23 USDに加えて500 USD/月）があります。
• Postmark：月額15 USDで10,000通、超過分は1,000通あたり1.80〜1.20 USDです（Postmarkの料金）。Postmarkのプランで50,000通送ると、およそ66 USDかかります。
• Resend：無料プランは月3,000通（1日100通まで）です。Proは月額20 USDで50,000通、超過分は1,000通あたり0.90 USDです（Resendの料金）。
• Mailgun：月額15 USDで10,000通、超過分は1,000通あたり1.80〜1.10 USDです（Mailgunの料金）。
• SendGrid：無料プランは現在60日間のトライアルで、Essentialsは月額19.95 USDからです（SendGridの料金）。

SPFトラブルシューティングのチェックリスト

ルックアップ上限の問題が疑われる場合は、次のチェックリストを確認してください。

• ルートドメインとすべての送信サブドメインでDNSチェックを実行します。
• include、a、mx、existsメカニズムの合計数を数えます。
• 各プロバイダーのincludeチェーンをたどり、ネストされたルックアップがあるか確認します。
• 未使用のプロバイダーを特定して削除します。
• トラフィックを専用サブドメイン（例：notifications.example.com）へ移行できるか評価します。
• それでも上限を超える場合は、動的SPFフラットニングを実装します。
• 最終レコードが文字列あたりの255文字制限を超えないことを検証します。

まとめ：SPFメカニズムの比較

メカニズム | DNSルックアップ | リスク | 推奨

ip4 / ip6 | なし | 低 | 静的IPに使用

include | あり | 高 | 控えめに使用し、連鎖を監視

a | あり | 中 | 可能なら避け、ip4を使用

mx | あり | 中 | 可能なら避ける

ptr | あり | 高 | 使用しない（非推奨）

SPFレコードを先回りして管理すれば、メールが迷惑メールフィルターに届く前から到達率を台無しにするpermerrorを避けられます。シンプルなAPIを使う場合でも、複雑なエージェントシステムを使う場合でも、DNSを簡潔に保つことが、トランザクションメールを確実に受け付けてもらうための最善の方法です。

送信ドメイン認証を管理するためのツール一式は、https://sendhq.cc をご覧ください。