SPF レコードをフラットニングする方法

SPF レコードをフラットニングするとは、DNS ルックアップを引き起こすメカニズム（include:、a、mx、exists、ptr、redirect）を、それらが解決する明示的な ip4: および ip6: レンジに置き換えることです。その結果、まったく同じ送信者を認可しながらも、受信側サーバーに辿らせる DNS クエリははるかに少なく（理想的にはゼロに）なり、RFC 7208 の 10 回のルックアップ上限の内側に安全にとどまります。このガイドでは、その手順を段階的に説明し、フラットニングされたレコードがどのようなものかを示し、公開後にそれを正確に保つ方法を解説します。

このページは、より大きな SPF フラットニング ガイドの一部です。手作業を完全に省きたい場合は、SPF Checker がすべての include を展開し、数秒でルックアップ数をカウントします。

そもそもなぜ SPF レコードをフラットニングするのか

SPF 認証は、RFC 7208 のもとで 1 回の評価あたり 10 回の DNS ルックアップ に制限されています。すべての include:、a、mx、exists、redirect の項がその予算に対してカウントされ、それぞれが指し示すドメインの内部でさらに再帰的なルックアップを引き起こす可能性があります。マーケティングプラットフォーム、CRM、ヘルプデスク、請求サービスを追加すれば、1 つの v=spf1 レコードが静かに 15〜40 回のルックアップへと膨れ上がることがあります。

上限を越えると、受信側は PermError を返します。PermError は 1 通のメッセージを失敗させるだけではありません。レコード全体を無効にするため、認可されたすべての送信元からの正規のメールが SPF に失敗し始める可能性があります。何も大きな音を立てて跳ね返らないため、チームは顧客が請求書やパスワードリセットのメールが届かないと報告するまで気づかないことがよくあります。

フラットニングは、こうした間接的なメカニズムを 前もって 解決し、生の IP を公開することでこれを解決します。完全にフラットニングされたレコードを評価する受信側は、再帰的な DNS 走査なしのシンプルな IP マッチングを行うため、検証も速くなり、サードパーティの一時的な DNS 障害にさらされることもありません。

フラットニングされた SPF レコードはどのようなものか

以下は、3 つの include に依存する典型的な未フラットニングのレコードです。

v=spf1 include:_spf.google.com include:vendor.com include:vendor2.net -all

各 include は少なくとも 1 回のルックアップであり、Google の include だけでもさらにいくつかを入れ子にします。フラットニングすると、同じ認可が IP の直接リストになります。

v=spf1 ip4:203.0.113.5 ip4:192.168.1.1 ip4:185.23.45.67 -all

すべての認可済みアドレスがすでに明記されているため、評価時にルックアップは発生しません。ポリシーを厳格に保つために -all 修飾子は維持されています。

SPF レコードをフラットニングする方法、手順ごとに

ステップ 1: 現在のレコードを見つけて監査する

dig TXT yourdomain.com のクエリ（または DNS プロバイダーのダッシュボード）で既存の SPF レコードを取得し、v=spf1 の TXT レコードがちょうど 1 つ だけ存在することを確認します。同じ名前に複数の SPF レコードがあること自体が PermError です。ルックアップを引き起こすメカニズム（include、a、mx、exists、redirect、ptr）と、そのまま残せるコストのかからない ip4/ip6 エントリを区別して把握しておきます。

ステップ 2: ルックアップ数を数える

何かを変更する前に、予算をどれだけ超過しているかを測ります。ドメインを SPF Checker で実行してください。すべての include を再帰的に展開し、正確なルックアップ数を示します。8 以上、またはすでに PermError が見えているなら、フラットニング（または委譲）が妥当です。安定した include が 3 つ以下なら、フラットニングはまったく不要かもしれません。

ステップ 3: 各メカニズムを IP へ再帰的に解決する

これがフラットニングの核心です。ルックアップを引き起こすすべての項について、明示的なアドレスまで解決します。

メカニズム	解決の仕方	結果
include:	ターゲットの SPF レコードを取得し、その メカニズムを再帰的に展開する	認可するすべての IP に対する ip4:/ip6:
a	そのドメインの A/AAAA レコードを解決する	アドレスごとに 1 つの ip4:/ip6:
mx	MX レコードを解決し、次に各メールホストの A/AAAA を解決する	各 MX ホスト IP に対する ip4:/ip6:
ptr	フラットニング しない — 非推奨で、遅く、信頼できない	削除する
exists:	通常フラットニングできない（実行時マクロに依存）	そのまま残すか、サブドメインに隔離する
ip4/ip6	すでに静的	変更せず残す

グラフを 深さ優先 で辿り、すでに訪れたドメインを記録して循環 include を検知できるようにします。include が解決スタック上にすでにあるドメインを指し示している場合は、無限にループせず、そこで停止して include のまま残します。

ステップ 4: CIDR を重複排除して集約する

再帰的な展開は重なりを生みます。2 つのベンダーが 1 つの IP を共有していたり、きれいに /24 へまとまる隣接した /25 ブロックをいくつも集めていたりすることがあります。すべてのアドレスを重複排除し、次に その和が完全に 1 つのプロバイダーの認可空間の内側にとどまる場合に限り、隣接するレンジをスーパーネットへ集約します。無関係なプロバイダー間で過度に集約すると、あなたが管理していない IP を認可することになります。これは最適化ではなく、セキュリティ上の後退です。

ステップ 5: レコードサイズに注意する

DNS TXT の文字列は 引用符付きセグメントあたり 255 文字 に制限されています。それより長いレコードは、同じレコード内の複数の連結文字列に分割する必要があります。実用的な目安として、UDP フラグメンテーションやミドルボックスの問題を避けるため、応答全体を約 450〜900 バイト未満に保ちましょう。フラットニングされたリストが大きすぎる場合は、それぞれ ip4/ip6 エントリのみを保持するヘルパーラベル（例: spf-a.example.com、spf-b.example.com）に IP を分割し、メインレコードからそれらを include します。各ヘルパーは 1 回のルックアップを消費するので、合計を 10 以下に保ちましょう。

ステップ 6: all 修飾子を付け直して検証する

元の終端メカニズムを付け加えます。本番の送信者には、厳格な適用のための -all が推奨されます。次に、レコードを SPF バリデーターで再実行し、構文がクリーンで、レコードがまだ 1 つだけで、ルックアップ数が想定どおりであることを確認します。慎重に移行する場合は、しばらく ~all で公開し、監視で合格率の安定が示された後に -all へ切り替えることができます。

ステップ 7: 低い TTL で公開し、その後引き上げる

公開の前に、間違いを素早く修正できるよう、レコードの TTL を 60〜300 秒に下げます。新しいフラットニング済みレコードを公開し、複数のパブリックリゾルバ（Google、Cloudflare、Quad9）から正しく解決することを検証し、SPF 合格率の低下がないか DMARC 集約レポートを注視します。安定したら、TTL を 1〜4 時間へ戻します。

落とし穴：フラットニングされたレコードは古くなる

ここに、手作業でフラットニングするほとんどの人がつまずく問題があります。フラットニングした瞬間、あなたのレコードはスナップショットになります。 Google、Mailchimp、Amazon SES、その他のプロバイダーが送信 IP をローテーションすると（大手 ESP は絶えずこれを行います）、ハードコードしたリストはもはや現実と一致しません。新しい IP からのメールは静かに SPF に失敗し、あなたは請求書の紛失やパスワードリセットの失敗に逆戻りします。ただし今回は、レコードが 見た目には 問題ないため、原因が見えません。

CDN を裏に持つ送信者やマーケティング送信者が最悪の常習犯です。1,200 以上のドメインにわたる AutoSPF の内部データによると、CDN を裏に持つ送信者は毎月 IP セットの 8〜15% を変動させるのに対し、社内メールサーバーは 0.5% 未満です。変動の激しいプロバイダーを無闇にフラットニングするのは、トラブルを招くことです。

実用的な要点は次のとおりです。

• 安定した送信元（オンプレミスのリレー、静的なクラウド IP）は積極的にフラットニングする。
• 変動しやすい ESP は include のまま残すか、ルートが 1 回のルックアップで include する mail-out.example.com のような委譲サブドメインの背後に隔離する。
• フラットニングを一度きりのものとして扱わない — 継続的な再解決が必要です。

AutoSPF で再フラットニングを自動化する

ベンダーが IP を変えるたびにステップ 1〜7 を手作業で行うのは現実的ではありません。これこそが AutoSPF の自動 SPF フラットニングサービス が作られた目的です。上記の決定論的なフラットニングアルゴリズムを継続的に実行します。15 分ごとに include を再スキャン し、上流プロバイダーの IP が変わると、DNS プロバイダーの API を通じて 公開済みレコードを自動更新 します。アトミックなスワップ、段階的な TTL、そしてカナリアチェックが失敗した場合のワンクリックロールバックを備えています。

決定的に重要なのは、AutoSPF が あなたの include が解決するのとまったく同じ IP に解決する ことです。過度に広い CIDR マージで認可を広げることは決してないため、意図しない送信者を誤って認可してしまうことはありません。ルートには小さく安定したレコードを保ち、AutoSPF がバックグラウンドでそれを正確に保ちます。

どの送信元をフラットニングし、どれを委譲すべきかを判断するには、最適な SPF フラットニングツール のガイドをご覧ください。IP のハードコード自体を避けたい場合は、SPF フラットニング対マクロ でアプローチを比較してください。そしてフラットニングの前に、その変更が他の認証レコードを乱さないことを確認しておく価値があります。SPF フラットニングは DKIM と DMARC に影響するか をご覧ください。

よくある質問

SPF レコードのフラットニングは DKIM や DMARC を壊しますか？

正しく行えば、いいえ。フラットニングは SPF が認可する IP を変えるだけで、DKIM 署名や DMARC アライメントには手を触れません。リスクは間接的なものです。古くなったフラットニング済みレコードが正規のメールで SPF に失敗し始めると、それが DMARC の合格率を引き下げる可能性があります。レコードを再解決し続ければ、両方とも健全に保たれます。

フラットニングされた SPF レコードは何回の DNS ルックアップを使いますか？

完全にフラットニングされたレコードは、評価時に ゼロ 回の DNS ルックアップを使います。すべての認可済み IP が ip4:/ip6: として明示的に列挙されているからです。変動しやすい include をいくつか残したり、IP をヘルパーラベルに分割したりすると、そのそれぞれが 1 回のルックアップを追加します。ただ、合計を RFC 7208 の上限である 10 以下に保ってください。

ptr や exists のメカニズムをフラットニングできますか？

一般にできません。ptr は非推奨で、遅く、単純に削除すべきです。exists: は通常、実行時マクロ（チェック時に MAIL FROM や HELO を評価する）に依存するため、静的な IP リストに縮約できません。exists はそのまま残すか、ルックアップの影響を抑えるために委譲サブドメインに隔離してください。

フラットニングされた SPF レコードはどのくらいの頻度で更新が必要ですか？

送信者が IP を変えるのと同じ頻度です。社内メールサーバーは数週間安定していることもありますが、主要な ESP や CDN は毎日アドレスを変えることがあります。だからこそ手動フラットニングは脆く、AutoSPF は 15 分ごとに再スキャンし、上流の IP セットが変わるたびに更新されたレコードを自動的に公開します。

フラットニングされたレコードが大きくなりすぎたらどうなりますか？

DNS TXT レコードは 1 文字列あたり 255 文字に制限されており、大きすぎるレコードは UDP フラグメンテーションのリスクを負います。フラットニングされた IP リストが大きすぎる場合は、それぞれ ip4/ip6 エントリのみを保持するヘルパーラベルに分割してメインレコードから include するか、変動しやすいプロバイダーをサブドメインに委譲します。応答全体を約 900 バイト未満、ルックアップを 10 以下に保つことを目指しましょう。

SPF レコードを手動でフラットニングすべきですか、それともツールを使うべきですか？

手動フラットニングは一度きりの修正には有効ですが、IP をローテーションするプロバイダーには追随できません。手作業でフラットニングしたレコードは、上流のレンジが変わった途端に静かに送信者の認可を外してしまいます。AutoSPF のような管理型ツールは、再帰的な解決、重複排除、サイズ管理、そして継続的な再フラットニングをあなたの代わりに処理します。だからこそ、単一の静的な送信者を超えるあらゆるケースで推奨されるアプローチなのです。