SPF フラットニング
SPF フラットニングは、SPF レコード内の include、a、mx メカニズムを背後の IP アドレスへ解決し、DNS ルックアップを RFC 7208 の上限である10回より下に保ちます。これによりレコードは有効なまま保たれ、正規のメールが認証を通り続けます。
SPF フラットニングとは、SPF レコードの中でルックアップを引き起こすすべてのメカニズム（include:、a、mx、ptr、exists、redirect=）を、その背後にある具体的な IP アドレスまで解決し、それらのアドレスを ip4: および ip6: のエントリとして直接公開する手法です。目的はシンプルで、メール受信側が強制する厳しい上限の内側にレコードを保ち、送信インフラが拡大しても正規のメールが認証され続けるようにすることです。
このページは SPF フラットニングに関するすべての情報のハブです。フラットニングとは何か、なぜ 10 回のルックアップ上限がこの問題を引き起こすのか、手順はどのように進むのか、そして本当のトレードオフとリスクがどこにあるのかを解説します。ここから、より具体的なタスクへ掘り下げられます。SPF レコードをフラットニングする方法、最適な SPF フラットニングツール、SPF フラットニングは DKIM と DMARC に影響するか、Cloudflare 上での実施方法、そしてフラットニングを SPF フラットニング対マクロ と比較する方法などです。
SPF フラットニングとは？
SPF レコードは v=spf1 で始まる単一の TXT レコードで、受信側メールサーバーに対して、あなたのドメインを代理してメールを送信できるホストがどれかを伝えます。サービス（CRM、マーケティングプラットフォーム、ヘルプデスク、トランザクションメールのプロバイダーなど）を追加するとき、通常はそのために include: を追加します。それぞれの include: は別のドメインの SPF レコードを指し、受信側は評価時にそのレコードを取得しなければなりません。こうした取得は DNS ルックアップであり、あっという間に積み上がります。
SPF フラットニングは、これらの間接的な参照をすべて事前に解決します。受信側に include:_spf.google.com を入れ子になった _netblocks レコードまで辿らせる代わりに、フラットニングされたレコードは単に背後にある IP レンジを列挙します。
- 変更前:
v=spf1 include:sendgrid.net include:_spf.google.com a mx -all - 変更後:
v=spf1 ip4:149.72.0.0/16 ip4:167.89.0.0/17 ip4:64.233.160.0/19 ip6:2a00:1450:4000::/36 -all
評価時に受信側はもはや include を再帰的に辿ったり、A/MX のターゲットを解決したりしません。接続元 IP を、公開された CIDR レンジと比較するだけです。これにより実行時の DNS ルックアップ数は実質ゼロになり、レコードは軽量で、高速で、信頼できるものに保たれます。
「10 回のルックアップ上限は、エンタープライズの SPF レコードが静かに壊れる最も一般的な単一の原因です」と、DuoCircle のゼネラルマネージャーであり AutoSPF の創業者である Brad Slavin は語ります。「2,000 を超える顧客ドメインの SPF を管理してきた経験では、故障モードは常に同じです。チームが新しい SaaS ツールを追加し、その include が合計を 10 の先へ押し上げ、正規のメールが失敗し始める。しかし、顧客が請求書やパスワードリセットのメールが届かないと苦情を言うまで、誰も気づかないのです。」
なぜ 10 回の DNS ルックアップ上限がフラットニングを強いるのか
RFC 7208 によれば、SPF 評価は 1 回のチェックあたり 10 回の DNS メカニズムルックアップ と 2 回の void ルックアップ に制限されています。いずれかの上限を超えると PermError が発生します。これは、あなたのメールが認証できないことを受信側サーバーに伝える恒久的な失敗です。サーバーは再試行せず、レコードの残りも評価しません。単にそこで停止し、あなたのドメインからのすべてのメッセージが SPF に失敗します。
厄介なのは、この上限は越えるまで見えないことです。1 つのプロバイダー経由で送信する小規模ビジネスは決して到達しません。しかし現代のメールスタックは、複数の ESP、CRM、サポートデスク、そして社内メールを日常的に積み重ねており、そのそれぞれが 1 つ以上のルックアップを追加します。Google Workspace だけでも、入れ子になった include を通じて 10 個のうち約 4 個を消費します。そこに Salesforce、Mailchimp、SendGrid、Zendesk を加えれば、簡単に 12〜15 に達します。11 番目のルックアップは決して評価されないため、その先に位置してしまったサービスは、静かに認可を失います。
各メカニズムがどのようにカウントされるかは次のとおりです。
| DNS ルックアップを引き起こす | ルックアップを 引き起こさない |
|---|---|
include:example.com | ip4:x.x.x.x[/CIDR] |
a、a:example.com | ip6:… |
mx、mx:example.com | all |
ptr（RFC 7208 では非推奨） | |
exists:domain | |
redirect=example.com |
ip4: と ip6: のメカニズムは解決を必要としないため、フラットニングはルックアップを引き起こすすべてのメカニズムを、ルックアップ不要のものに置き換えます。それこそが、フラットニングがコンプライアンスを保つ仕組みのすべてです。今日の自分の状況を素早く確認するには、SPF Checker でドメインを実行してみてください。すべての include を展開し、ルックアップ数をカウントします。
なぜフラットニングが到達性とセキュリティにとって重要なのか
10 回のルックアップ上限は単なる技術的な脚注ではなく、あなたのメールと受信トレイの間の経路上に直接位置しています。
到達性。 DMARC は SPF と DKIM に依存します。SPF レコードが PermError を返すと、DMARC はそれを失敗として扱い、正規のメールが隔離または拒否されることがあります。2024 年以降、Google、Yahoo、Microsoft は一括送信者に対して SPF、DKIM、DMARC による認証を求めており、非準拠のメッセージはスパムに振り分けるのではなく、そのまま拒否するようになりました。これらのプロバイダーは合わせて典型的な一般消費者向けリストの約 90% をカバーするため、1 つの上限超過レコードが、あなたのオーディエンスの大半への配信を一度に断ち切ってしまう可能性があります。
セキュリティ。 SPF が失敗すると、受信側サーバーは正規のメールとなりすましメッセージを区別する能力を失います。それこそが、フィッシングやビジネスメール詐欺（BEC）が突く隙間です。SPF を有効に、そして上限の内側に保つことで、あなたを、ドメインになりすます攻撃者から切り分ける認証シグナルが維持されます。
管理性。 ブランドが成長するにつれ、あなたを代理して送信するプラットフォームのリストも増えます。フラットニングは、広がりすぎた include の連鎖を、読み、監査し、把握しやすい 1 つのすっきりした IP レンジのリストへと折りたたみます。
SPF フラットニングの仕組み、手順ごとに
手動でも自動でも、フラットニングは同じパイプラインをたどります。
- 検出。 現在の SPF
TXTレコードを読み取り、ルックアップを引き起こすすべてのメカニズム（include、a、mx、exists、redirect）を特定します。 - 再帰的解決。 各
includeの連鎖を辿り、ターゲットの SPF レコードを取得し、上流のすべての内容が判明するまで再帰します。a/mxのターゲットをそのA/AAAAレコードへ解決し、IPv4 と IPv6 の両方のアドレスを集めます。 - 重複排除と圧縮。 重なり合うレンジをマージし、連続するブロックを
CIDR表記へ集約して、レコードをコンパクトに保ちます。 - 公開。 レコードを
v=spf1 ip4:… ip6:… -allとして書き直し、1 文字列あたり 255 文字のTXT上限を尊重し（必要なら複数の連結文字列に分割）、DNS を更新します。 - 検証。 構文を確認し、ルックアップ数が 0〜1 であることを検証し、テストメールを送信して
SPF=passとDMARC=passを確認します。
コマンドや DNS プロバイダー固有の詳細を含む完全なウォークスルーは、SPF レコードをフラットニングする方法 をご覧ください。
落とし穴：フラットニングされたレコードは一度きりの修正ではない
フラットニングはルックアップの問題を解決しますが、新たな問題を持ち込みます。動的な include: を静的な IP に置き換えると、それらの IP を最新に保つ責任を自分で負うことになります。プロバイダーは送信インフラを絶えずローテーションしますが、その際にあなたへ通知することはほとんどありません。
「SPF フラットニングについての誤解は、それが一度きりの修正だというものです」と、DuoCircle の CTO であり AutoSPF のフラットニングエンジンの設計者である Adam Lundrigan は語ります。「ベンダーの IP レンジは絶えず変わります。Google は 2025 年だけで _netblocks を 3 回ローテーションしました。自動的に再解決されないフラットニング済みレコードは古くなり、静かに正規の送信者の認可を外してしまいます。だからこそ AutoSPF は 15 分ごとに再スキャンするのです。」
これはフラットニングについて理解すべき最も重要な一点です。手作業で構築したフラットニング済みレコードは、公開した当日は正確でも、その後ゆっくりと古くなっていきます。プロバイダーが新しい IP レンジを追加すると、そのレンジからのメールは SPF に失敗し始め、しかもその失敗が静かであるため、通常はアラートではなく、跳ね返された請求書や届かなかったパスワードリセットからそれを知ることになります。1,200 ドメインにわたる AutoSPF のテレメトリでは、フラットニングによって PermError 率が 93% 低下し、最初の 30 日間で DMARC の合格率が 7〜12% 改善しました。ただし、それはレコードが最新に保たれていた場合に限ります。大量送信プロバイダーの ESP IP 変動の中央値は、週あたり 2〜4 回の変更です。
計画に入れておくべきその他のトレードオフは次のとおりです。
- レコードサイズ。 フラットニングは
TXTレコードを DNS のサイズ上限へ押し上げることがあります。UDP フラグメンテーションや切り詰めを避けるため、応答を約 1,000〜1,200 バイト未満に保つことを目指し、個々のアドレスを列挙するよりも集約されたCIDRレンジを優先しましょう。 - 過剰な認可。 一部の include は、実際に使用するよりもはるかに広範囲のインターネットを認可します。フラットニングの前に監査して絞り込むことで、攻撃対象領域を小さく保てます。
手動、スクリプト、それとも自動化？
フラットニングには 3 つの方法があり、それぞれリスクプロファイルが大きく異なります。
- 手動。 各 include の現在の IP を照会し、それらを集約し、手作業で公開します。無料で完全に自分の管理下にありますが、労力がかかり、プロバイダーが IP を変更した瞬間にドリフト（乖離）しやすくなります。小規模で静的な環境でのみ現実的です。
- スクリプト。 Python や Go のスクリプトが include を再帰的に辿り、
A/MXを解決し、CIDRレンジをマージし、スケジュールに従って API 経由で DNS へ反映します。再現可能で監査可能ですが、エッジケース、ループガード、継続的な信頼性は自分で担う必要があります。 - 自動化された（動的）サービス。 ホスティング型サービスが、あなたの include を継続的に再解決し、IP の変更を検知し、自動的に再公開します。これはメンテナンスの負担を完全に取り除きますが、その代わりに管理された依存関係を抱えることになります。
Google Workspace、Microsoft 365、SendGrid、Amazon SES のような動的プロバイダーを使うあらゆる組織にとって、自動化されたアプローチが強く推奨されます。フラットニングの難しさのすべては変動に追随し続けることにあり、それこそがまさに自動化が扱う部分だからです。各選択肢の完全な比較は、最適な SPF フラットニングツール にあります。
AutoSPF の位置づけ
AutoSPF の自動 SPF フラットニングサービス は、フラットニングを危険にするメンテナンスの問題に特化して構築されています。入れ子になった include を検出して展開し、A/MX/AAAA の連鎖を完全に解決し、レンジを重複排除して最小限の CIDR ブロックに圧縮し、10 回のルックアップ上限の内側にとどまる、検証済みでサイズを意識したフラットニング済みレコードを公開します。
これを際立たせる点が 2 つあります。
- 15 分ごとに再スキャンし、上流プロバイダーの IP が変わった瞬間にレコードを自動更新します。だからフラットニング済みレコードが静かに古くなることはありません。
- あなたの include が解決するのとまったく同じ IP に解決します。広すぎて過度に寛容なレンジもなく、過剰な認可もありません。フラットニング済みレコードは、実際の include が認可するホストだけを正確に認可し、それ以上は認可しません。
さらに、バージョン管理されたレコードとワンクリックのロールバック、カナリア/ステージング公開、そして現在のフラットニング済みセット外の IP からメールが届いたときのドリフトアラートも提供します。Route 53、Cloudflare、Google Cloud DNS、Azure DNS を含む主要な DNS プロバイダーと直接統合します。あらゆる変更の前後で、SPF Checker を使ってレコードがクリーンに解決することを確認できます。
DNS プロバイダー全体および大規模でのフラットニング
フラットニングの仕組みはどこでも同じですが、公開の仕方はプラットフォームによって異なります。たとえば Cloudflare では、TXT レコードをダッシュボードや API で管理し、その文字列分割の挙動を尊重する必要があります。詳細は Cloudflare SPF フラットニング で解説しています。
SaaS 規模（数千のテナント、複数の送信ストリーム）では、勝ちパターンは階層化です。メールストリームをサブドメインに分離し（たとえばマーケティング用に mkt.example.com、トランザクション用に tx.example.com）、redirect= で小さな正規レコードにポリシーを集中させ、変動の激しいプロバイダーを集約された ip4/ip6 セットへ完全にフラットニングし、差分ベースの公開でリフレッシュを自動化して、変更のないレコードが DNS 変動を引き起こさないようにします。負荷の大きい送信者をサブドメインに委譲することは、組織ドメインを軽く保ち、DMARC アライメントを簡素化することにもつながります。
フラットニングは DKIM や DMARC を変えるか？
フラットニングが変えるのは、認可された送信者を SPF でどう表現するか（include の代わりに ip4/ip6）だけであり、あなたのドメインの識別情報や DKIM 署名は変えません。フラットニングされた SPF が、MAIL FROM/Return-Path で使うドメイン上に公開されている限り、DMARC アライメントは影響を受けず、PermError を解消することで、SPF がアライメントされた識別子である場合には通常 DMARC の合格率を 改善 します。DKIM が一括送信者のアライメントをしばしば担う仕組みを含む完全な関係性は、SPF フラットニングは DKIM と DMARC に影響するか で解説しています。
フラットニング対 SPF マクロ
従来のフラットニングは include を静的な IP へ事前解決するため、絶えずリフレッシュが必要になります。SPF マクロは別の道を取ります。動的展開を使うことで、1 つのレコードが 10 回のルックアップ上限に決して達することなく、事実上無制限の数の送信者を認可できるのです。ただし、複雑さが増し、リゾルバのサポートが弱いという代償があります。どちらのアプローチが適しているかは、あなたのインフラとメンテナンスへの許容度によります。完全な内訳は SPF フラットニング対マクロ にあります。
よくある質問
SPF フラットニングを簡単に言うと何ですか？
SPF フラットニングとは、SPF レコード内の include:、a、mx の各メカニズムを、それらが解決する実際の IP アドレスに置き換えるプロセスです。これにより、受信側メールサーバーに DNS ルックアップを強いる代わりに、認可済み IP のできあがったリストを渡すことができ、RFC 7208 が定める 10 回のルックアップ上限の内側にレコードを保ち、認証失敗を防ぎます。
なぜ SPF フラットニングが必要なのですか？
フラットニングが必要になるのは、あなたのドメインが SPF 仕様の上限である 1 回の評価あたり 10 回の DNS ルックアップを超えたときです。その上限を越えると、SPF は PermError を返し、あなたのドメインからのすべてのメッセージが認証に失敗し、DMARC も失敗する原因になり得ます。ほとんどの組織は、それぞれ include を追加する複数のサードパーティ送信者を使っているため、成長するドメインは早々に上限に達し、コンプライアンスを保つためにフラットニングが必要になります。
SPF フラットニングはメールの到達性を改善しますか？
はい。ルックアップの過多や遅い上流 include によって引き起こされる PermError と TempError の状態を解消することで、フラットニングは SPF を確実に合格させ続けます。AutoSPF の顧客データでは、12〜18 回のルックアップから完全にフラットニングされたレコードへ移行することで、SPF 関連の DMARC 失敗が 80% 以上減少し、ピーク送信時のマーケティングメールの受信トレイ到達率が 10〜15% 改善しました。
フラットニングされた SPF レコードはどのくらいの頻度で更新すべきですか？
プロバイダーが IP を変更するのと同じ頻度です。SendGrid や Mailchimp のような変動の激しい ESP は 12〜24 時間ごとのリフレッシュが妥当で、Google Workspace や Microsoft 365 のような安定したスイートは毎日、静的な自己ホスト型レンジは毎週が目安です。手作業でメンテナンスするレコードはほぼ必ずドリフトします。AutoSPF は 15 分ごとに再スキャンし、上流のレンジが変わるたびに自動的に再公開することで、これを回避します。
手動の SPF フラットニングは安全ですか？
手動のフラットニングは、送信 IP がめったに変わらない小規模で静的な環境でのみ安全です。動的プロバイダーを使うあらゆるドメインでは、手作業で構築したレコードは、プロバイダーがインフラをローテーションした途端に古くなり、正規の送信者の認可を静かに外してしまいます。プロバイダーの変動に追随し続けることが難しい部分であるため、実運用の規模では自動フラットニングが強く推奨されます。
フラットニング後は -all と ~all のどちらを使うべきですか？
フラットニングされたリストが完全で、能動的に監視されていると確信できる場合は -all（ハードフェイル）を使いましょう。これは受信側になりすましメールを拒否する最も明確なシグナルを与えます。ロールアウト中や、まだ頻繁に送信者を追加している間は ~all（ソフトフェイル）を使います。良いやり方は、DMARC レポートがクリーンな合格期間を示すまで ~all を保ち、その後 -all へ引き締めることです。