Cloudflare SPF フラットニング

ドメインの DNS に Cloudflare を使っている場合、肥大化した SPF レコードを Cloudflare がフラットニングしてくれるのか気になるかもしれません。手短な答えはノーです。Cloudflare はネイティブの SPF フラットニングを提供していません。Cloudflare は DNS レコードをホストし、そのグローバルネットワーク全体で高速に配信しますが、SPF レコードを通常の TXT レコードとして扱い、あなたに代わって include: メカニズムを IP アドレスへ書き換えることは決してありません。

これが問題になるのは、SPF に厳格な上限があるからです。RFC 7208 のもとで、SPF チェックは 10 回の DNS メカニズムルックアップに制限されています。レコード内のすべての include:、a、mx、ptr、redirect がルックアップを消費し、入れ子の include もカウントされます。その上限を越えると、受信側サーバーは PermError を返します。これは、レコードの残りがどれだけ正しくても、あなたのドメインからのすべてのメッセージの認証を壊す恒久的な失敗です。SPF フラットニング がその修正です。ルックアップの多い include: メカニズムを、解決された ip4: および ip6: アドレスに置き換え、レコードを上限より下へ戻します。

このガイドでは、Cloudflare が SPF をフラットニングするかどうか（しません）、Cloudflare DNS 上にあるレコードをフラットニングする方法、フラットニングされた TXT レコードを Cloudflare ダッシュボードで公開する方法、そして AutoSPF でそれを自動的に正確に保つ方法を扱います。

Cloudflare はネイティブの SPF フラットニングを提供しているか？

いいえ。Cloudflare の DNS 製品は権威 DNS ホスティングであり、あなたが入力したとおりの TXT 内容を正確に公開します。SPF レコードを解析したり、include を解決したり、それらを IP へ折りたたんだりはしません。SPF フラットニングを実行するトグル、ページルール、Email Routing 設定はありません。

Cloudflare Email Routing は受信メールを転送し、送信に使う場合は独自の SPF include を追加しますが、あなたの送信 SPF レコードを管理したりフラットニングしたりはしません。v=spf1 文字列が 10 回のルックアップを越えて押し進んでいても、Cloudflare は大きすぎるレコードを喜んで配信し、受信側にそれを拒否させます。フラットニングは、手動またはツールで自分で行い、その結果を Cloudflare に公開しなければならないものです。

Cloudflare DNS 上にホストされた SPF レコードをフラットニングする方法

フラットニングの仕組みは、誰が DNS をホストしていても同じです。Cloudflare はたまたま完成したレコードを公開する場所にすぎません。完全なウォークスルーが欲しい場合は、SPF レコードをフラットニングする方法 をご覧ください。以下は Cloudflare の文脈でのプロセスです。

1. 送信者を棚卸しする。 あなたのドメインを代理してメールを送信するすべてのサービスを列挙します。Google Workspace または Microsoft 365、マーケティングプラットフォーム（Mailchimp、Sendgrid など）、CRM、ヘルプデスク、そしてあらゆるトランザクションプロバイダーです。

2. 現在のレコードを読む。 Cloudflare ダッシュボードでドメインを開き、DNS → Records に移動し、v=spf1 で始まる TXT レコードを見つけます。それに含まれるすべての include: を書き留めます。

3. 各 include をその IP へ解決する。 各 include: メカニズムについて、それが指す SPF レコードを実際の ip4: および ip6: レンジまで解決します。次のようなレコードが、

   v=spf1 include:_spf.google.com include:mailchimp.com include:sendgrid.net ~all

   このようにフラットニングされるかもしれません。

   v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:198.2.128.0/18 ip6:2001:4860:4000::/36 ~all

4. 修飾子を保つ。 末尾の ~all（ソフトフェイル）または -all（ハードフェイル）を維持します。フラットニングは中間のメカニズムを変えるのであって、ポリシーを変えるのではありません。

5. フラットニングされたレコードを公開する — 単一の TXT レコードとして Cloudflare に戻します（手順は下記）。

落とし穴として、それらの解決された IP は恒久的ではありません。Google や Microsoft のようなプロバイダーは送信レンジを定期的にローテーションします。今日あなたが手作業でフラットニングしたレコードは、来月には静かに古くなり、レコードは見た目こそクリーンでも、変わった IP からのメールが SPF に失敗し始めます。これは、Cloudflare を含むあらゆる DNS ホスト上での手動フラットニングの最大のリスクです。トレードオフは 最適な SPF フラットニングツール で比較してください。

Cloudflare ダッシュボードでフラットニングされた TXT レコードを追加する

フラットニングされた文字列ができたら、Cloudflare で公開します。

1. dash.cloudflare.com でサインインし、ドメインを選択します。
2. 左サイドバーで DNS → Records をクリックします。
3. 古い v=spf1 TXT レコードが存在する場合は、2 つ目を追加するのではなく それを編集 します。ドメインにはちょうど 1 つの SPF レコードが必要です。2 つの v=spf1 TXT レコードは PermError を引き起こし、認証を失敗させます。
4. 新規に追加するには、Add record をクリックして次のように設定します。
   • Type: TXT
   • Name: @（これはルートドメインを表します）
   • Content: 完全にフラットニングされた v=spf1 … ~all 文字列を貼り付けます
   • TTL: Auto のままにします
5. Save をクリックします。

Cloudflare 固有の注意点がいくつかあります。

• レガシーの SPF 型ではなく TXT を使う。 Cloudflare は、現代の DNS の慣行と同様に、SPF を TXT レコードとして公開します。廃れた SPF レコード型は使いません。
• プロキシステータスは適用されない。 SPF は TXT レコードなので、気にすべきオレンジ雲のプロキシトグルはありません。常に権威 DNS として配信されます。
• 255 文字の文字列上限に注意する。 単一の DNS TXT 文字列は最大 255 文字です。長いフラットニング済みレコードは、1 つの TXT レコード内で複数の引用符付き文字列に分割する必要があります。Cloudflare はこの連結を処理しますが、レコードはできるだけ無駄なく保ちましょう。

公開後は、伝播のために数分待ち、それから SPF Checker でレコードを確認し、構文が有効で 10 回のルックアップ上限の内側にいることを検証します。

Cloudflare ホストのドメインで AutoSPF を使う

手動フラットニングは今日の PermError を解決しますが、メンテナンスの問題を持ち込みます。上流プロバイダーがレンジを変えるたびに、フラットニングされた IP が古くなるのです。AutoSPF のホスト型 SPF フラットニングサービス はその隙間を閉じ、Cloudflare DNS とクリーンに連携します。

AutoSPF が Cloudflare 構成にどう収まるかは次のとおりです。

• クリーンな SPF レコードを 1 つ Cloudflare に保ち、それが AutoSPF がホストするルックアップを指します。AutoSPF がその単一のメカニズムの背後であなたのすべての include を解決するため、可視のレコードは余裕をもって 10 回のルックアップの内側にとどまります。
• AutoSPF は 15 分ごとに再スキャン し、上流プロバイダーの IP が変わると、フラットニングされた結果を自動的に更新します。だから、新しくローテーションされた Google や Microsoft のレンジからのメールは、あなたが Cloudflare に再び触れることなく SPF を通り続けます。
• あなたの include が解決するのとまったく同じ IP に解決します。過剰な認可も、当て推量も、攻撃対象領域を広げる広いレンジもありません。送信者が使うものだけを正確に認可し、それ以上は認可しません。

AutoSPF は DNS プロバイダー非依存なので、特別な Cloudflare 統合を必要としません。上記と同じ DNS → Records → Add record のフローを使って Cloudflare ダッシュボードで 1 つのレコードを公開すれば、あとは AutoSPF がフラットニングと継続的なメンテナンスを引き受けます。

フラットニングはあなたのより広い認証スタックとも相互作用します。include を折りたたむことが他のレコードに何か変化をもたらすか気になる場合は、SPF フラットニングは DKIM と DMARC に影響するか をご覧ください。（手短に言えば、影響しません。DKIM と DMARC は独立して評価されます。）

よくある質問

Cloudflare は SPF レコードを自動的にフラットニングしますか？

いいえ。Cloudflare は権威 DNS ホストであり、あなたが入力した TXT レコードを正確に配信し、include: メカニズムを IP アドレスへ解決することは決してありません。フラットニングは、あなた自身が、あるいは AutoSPF のような専用ツールで行い、その結果を Cloudflare に公開するものです。

Cloudflare でフラットニングされた SPF レコードを追加するには？

Cloudflare ダッシュボードでドメインを開き、DNS → Records に移動します。既存の v=spf1 TXT レコードを編集する（または Type TXT、Name @ で 1 つ追加する）か、フラットニングされた v=spf1 … ~all 文字列を貼り付けて Save します。PermError を避けるため、ドメインごとに SPF レコードは 1 つだけに保ちましょう。

なぜ私の Cloudflare の SPF レコードは PermError を引き起こすのですか？

RFC 7208 のもとで、SPF チェックは 10 回の DNS ルックアップに制限されています。レコードの include: メカニズムがその上限を超えると、あるいは誤って 2 つの v=spf1 レコードを公開すると、受信側は PermError を返し、すべてのメッセージで SPF が失敗します。レコードを 10 回のルックアップより下へフラットニングすれば解決します。

Cloudflare でフラットニングされた IP アドレスは古くなりますか？

はい、手動でフラットニングした場合は。Google や Microsoft のようなプロバイダーは送信 IP レンジをローテーションするため、手作業でフラットニングしたレコードは静かにドリフトし、SPF に失敗し始めることがあります。AutoSPF は 15 分ごとに再スキャンし、上流の IP が変わるたびにフラットニングされたレコードを自動更新することで、これを回避します。

DNS が Cloudflare 上にある場合、AutoSPF を使えますか？

はい。AutoSPF は DNS プロバイダー非依存で、特別な Cloudflare 統合は不要です。AutoSPF を指すクリーンな SPF レコードを 1 つ Cloudflare に公開すれば、AutoSPF がフラットニングを処理し、10 回のルックアップ上限の内側にあなたを保ち、送信者の IP が変わるにつれて自動的に更新します。

Cloudflare では SPF を TXT レコードにすべきですか、それとも SPF レコードにすべきですか？

常に TXT レコード型を使ってください。レガシーの専用 SPF レコード型は廃れており、現代の DNS では使われません。Cloudflare では Type TXT、Name @ を選び、v=spf1 の内容を貼り付けます。