SPFフラット化（フラットニング）とは？ 仕組み・手順・リスクを解説

送信ログを確認した際に、「SPF PermError」と表示されていたことはありませんか？これは、SPFレコードを正常に評価できなかった場合に示される認証結果です。

原因の一つとして、DNSルックアップ回数の上限（最大10回）超過が挙げられます。複数のSaaSやメール配信サービスを利用している場合は、DNSの参照回数が増えやすく、正規の送信元から送ったメールであっても、認証エラーになることがあります。

このような場合に対処法として行われるのが「SPFフラット化（フラットニング）」です。具体的には、DNSルックアップを減らすためにincludeの参照先を展開し、IPアドレスをSPFレコードに直接記述します。ただし、送信サービス側のIPアドレス変更に追随しにくくなる、更新作業が煩雑になるなど、運用上の注意点もあります。

本記事では、SPFフラット化の仕組みや実施方法、注意点とあわせて、フラット化の代替策についても解説します。

SPFフラット化（フラットニング）とは

SPFフラット化は、SPF認証におけるDNSルックアップ回数の上限（10回）超過を回避するための手法です。SPFレコード内の includeなどで参照されるIPアドレスを取得し、SPFレコードに直接記述することで、DNSルックアップ回数を減らします。

まずは、SPF認証においてDNS参照がどのように行われているのかを見てみましょう。

SPFにおけるDNS参照の仕組み

SPFは、受信サーバーが送信元のIPアドレスと、エンベロープFromドメインのSPFレコードに記載された情報を照合し、正規の送信元かどうかを確認する仕組みです。この検証の過程で、DNS上に公開されたSPFレコードを参照します。

特に include メカニズムを使用すると、指定された別ドメインのSPFレコードを参照して評価するため、DNSルックアップ回数が増えやすくなります。さらに、その参照先にもinclude が含まれている場合、参照が連鎖的に増えていきます。

例えば、下図のようにinclude:example.com を指定した場合、まず example.com のSPFレコードを参照します。その中に include:spf1.example.com や include:spf2.example.com が含まれているため、それらのSPFレコードもさらに参照します。

このように、SPFレコードが入れ子構造になっているとDNSルックアップ回数が増え、構成によっては上限に達することがあります。

SPF includeの役割や設定方法については、以下の記事で詳しく解説しています。
SPF includeとは？ 役割・設定方法・DNSルックアップ上限超過の解消法を解説｜ベアメールブログ

DNSルックアップ回数の制限と超過時のエラー

SPFには、DNSルックアップを発生させるメカニズムや修飾子の評価数を、SPF評価全体で最大10回までに制限する仕様があります（RFC 7208）。これはDNSへの過度な負荷を防ぐために定められたもので、include だけでなく a、mx、ptr、existsの各メカニズムやredirect修飾子も対象となります。

複数のSaaSやメール配信サービスを利用している場合、それぞれのサービスをinclude で追加することでDNSルックアップ回数が増え、気づかないうちに上限を超えてしまうことがあります。

上限を超えると、SPFの認証結果は「PermError」となり、SPF認証を正常に完了できません。PermErrorをどのように扱うかは受信側のポリシーによって異なりますが、受信拒否や迷惑メール判定につながるケースもあります。

SPFのDNSルックアップの回数制限について、詳しくは以下の記事で解説しています。
SPFのDNSルックアップ回数制限とは？ 確認方法や対策を解説｜ベアメールブログ

SPFフラット化が利用される理由

SPFフラット化は恒久的な対策には向きませんが、DNSルックアップ回数の上限超過によるSPF認証エラー（PermError）が発生した際の一時的な対処法として有効です。DNS設定やメール送信環境の見直しには時間がかかりますが、フラット化であれば、既存のSPFレコードの参照先をIPアドレスに置き換えることにより、比較的短期間でDNS参照回数を減らせます。

特に複数のSaaSやメール配信サービスを併用している環境では、構成変更の影響範囲が広くなりやすいため、恒久的な対策を検討・実施するまでの間、SPF認証への影響を抑えるための一時的な対応として利用されることがあります。

SPFフラット化の仕組み

SPFフラット化では、include や a、mx などによって参照される送信元のIPアドレスを確認し、SPFレコードに直接記述します。

フラット化前
v=spf1 include:_spf.example.com include:spf.example.com ~all

フラット化後（IPアドレスに展開）
v=spf1 ip4:203.0.113.5 ip4:198.51.100.20 ~all

これにより、SPF認証時のDNSルックアップ回数を減らし、上限超過によるPermErrorを回避できます。

フラット化の詳しい実施手順については、次章で解説します。

SPFフラット化の手順

SPFフラット化を行う際は、現在のSPFレコードとDNSルックアップ回数を確認したうえで、includeの参照先に含まれるIPアドレスを調べ、SPFレコードに直接記述します。

設定後は、DNSルックアップ回数が上限内に収まっているか、実際のメールでSPF認証が正常に行われているかを確認しましょう。

① SPFレコードのDNSルックアップ回数を確認する

まず、現在公開されているSPFレコードのDNSルックアップ回数を確認します。コマンドを実行してincludeの参照先を一つずつたどることもできますが、以下のようなチェックツールを利用すると、より簡単に確認できます。

Dmarcian「SPF Surveyor」（https://dmarcian.com/spf-survey/）

ドメインを入力すると、SPFレコードの構造やDNSルックアップ回数を確認できます。

上記の例では、「10/10」と表示されている箇所がルックアップ回数です。上限を超えている場合、警告が表示されます。

画面をスクロールすると、SPFレコードに含まれるincludeなどの参照関係も確認できます。どのincludeがDNSルックアップ回数の増加につながっているかを確認し、フラット化する箇所を検討します。

② includeの参照先に含まれるIPアドレスを確認する

次に、フラット化するincludeの参照先を確認し、送信元として指定されているIPアドレスを洗い出します。

例えば、SPFレコードに以下の記述があるとします。

include:_spf.example.com

この場合は、_spf.example.comのSPFレコードを確認します。digコマンドを使う場合は、以下のように実行します。

dig TXT _spf.example.com

参照先のSPFレコードにさらにincludeが含まれている場合は、その参照先も確認します。また、aやmxなどが指定されている場合も、参照先を確認してIPアドレスを特定します。これを繰り返し、最終的に送信元として指定されているIPアドレスを特定します。

なお、外部サービスが使用するIPアドレスは変更される場合があります。ベンダーが送信元IPアドレスやIPレンジを公式に公開している場合は、あわせて確認しておきましょう。

③ SPFレコードにIPアドレスを記述する

参照先のIPアドレスを確認できたら、元のSPFレコードに記述します。

例えば、参照先を確認した結果、以下のIPアドレスが指定されていたとします。

ip4:203.0.113.0/24
ip4:198.51.100.0/24

確認したIPアドレスを、元のSPFレコードに記述されているincludeと置き換えます。

変更前
v=spf1 include:_spf.example.com ~all

変更後
v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 ~all

これにより、SPF認証時のDNSルックアップ回数を減らすことができます。

ただし、参照先のSPFレコードによっては、IPアドレスをそのまま置き換えると、元のSPFレコードと認証結果が変わる場合があります。ip4やip6以外のメカニズムや、条件付きで評価される記述が含まれている場合は、SPFレコード全体の構成を確認したうえでフラット化する必要があります。

④ SPFレコードと認証結果を確認する

SPFレコードを変更したら、設定が正しく反映されているか確認します。

まず、「SPF Surveyor」などのチェックツールに再度ドメインを入力し、変更後のSPFレコードが意図した内容に更新されているか確認します。あわせて、DNSルックアップ回数が10回以内に収まっているか、SPFレコードに構文上の問題がないかも確認しましょう。

次に、実際の送信環境からテストメールを送信し、受信したメールのヘッダを確認します。Authentication-Resultsヘッダなどで、対象となるエンベロープFromドメインのSPF認証結果がpassとなっていれば、SPF認証に成功しています。複数のSaaSやメール配信サービスを利用している場合は、それぞれの送信環境からテストメールを送り、すべての送信元でSPF認証がpassとなっていることを確認しましょう。

SPFレコードの設定や認証結果の確認方法については、以下の記事で詳しく解説しています。
SPFの確認方法は？ 設定の確認手順や認証結果の見方、失敗する原因を解説｜ベアメールブログ

SPFフラット化のリスク・注意点

SPFフラット化は、DNSルックアップ回数を減らすための一時的な対応策としては有効ですが、長期的な運用にはリスクもあります。以下の注意点を確認しておきましょう。

IPアドレス変更に自動で追随できず、運用負荷が高まる

SPFフラット化では、外部サービスの送信IPアドレスをSPFレコードに直接記述するため、サービス側でIPアドレスが変更されても自動では反映されません。

メール配信サービスやSaaSでは、セキュリティ対策や冗長化の目的で送信IPアドレスが変更されることがあります。この変更に対応するには手動でSPFレコードを更新し続ける必要がありますが、IPアドレスの追加・削除が予告なく行われるケースもあり、継続的な確認が必要になります。

変更への対応が遅れると、新たに追加されたIPアドレスから送信されたメールがSPF認証に失敗し、受信拒否や迷惑メール判定につながるおそれがあります。また、利用するサービスが多いほど確認・更新の手間も増えるため、運用負荷が高くなりやすい点にも注意が必要です。

SPFレコードが長くなり、管理しにくくなる

フラット化を行い、多数のIPアドレスを直接記述すると、SPFレコードが長くなり、設定内容を把握しづらくなります。

どのIPアドレスがどのサービスに対応しているのかが分かりにくくなり、更新時に必要なIPアドレスを誤って削除したり、重複して記述したりするおそれがあります。複数のドメインで同様の設定を行っている場合は、それぞれのSPFレコードを個別に確認・更新する必要があるため、管理がさらに複雑になります。

結果として、設定ミスを防ぐための確認や検証にかかる手間が増え、運用効率が低下する可能性があります。

DNS応答サイズが大きくなり、SPF評価に影響する可能性がある

SPFフラット化によってSPFレコードが長くなると、DNS応答のサイズも大きくなります。

DNSのTXTレコードでは、1つの文字列に記述できる長さは最大255オクテットですが、複数の文字列に分けて1つのTXTレコードとして登録することが可能です。そのため、SPFレコード全体を255文字以内に収める必要はありません。

ただし、RFC 7208では、SPFレコードを取得するDNS応答は512オクテット以内に収まる程度に小さくすることが推奨されています。DNS応答が大きくなりすぎると、環境によってはSPF評価に必要な情報を正常に取得できない可能性があります。

フラット化によって多数のIPアドレスを記述する場合は、DNSルックアップ回数だけでなく、SPFレコードの長さやDNS応答サイズにも注意が必要です。

SPFフラット化の代替策

SPFフラット化はDNSルックアップ回数を減らす方法の一つですが、継続的な運用にはリスクがあるため、あくまで一時的な対応として捉えるのがよいでしょう。ここでは、DNSルックアップ回数の上限超過に対する恒久的な対策を紹介します。

不要な送信元・includeを整理する

SPFレコードに不要な送信元やincludeが含まれていないかを確認します。過去に利用していたメール配信サービスやSaaSの設定がそのまま残っていると、不要なDNSルックアップが発生し、上限超過の原因になることがあります。

まずは現在利用している送信元を洗い出し、使用していないサービスに対応するincludeがあれば削除を検討しましょう。あわせて、同じincludeが重複して記述されていないかも確認します。

SPFを自動管理できるサービスを利用する

SPFレコードの継続的な管理が難しい場合は、SPFの設定や更新を自動化するサービスを利用する方法もあります。こうしたサービスを利用することで、参照先のIPアドレス変更への追随や、SPFレコードの更新にかかる運用負荷を軽減できます。

ベアメールでは、SPFレコードを管理できる「SPFホスティング」を提供しています。既存のSPFレコードをインポートして設定でき、DNSルックアップ回数の上限超過への対応から、その後のSPFレコードの管理・更新までを効率化できます。

主な機能は以下の通りです。

• SPFチェック：現在のSPFレコードのDNSルックアップ回数やエラーの有無を確認
• SPFレコードのインポート・編集：既存の設定を取り込み、管理画面上で送信環境を追加・変更
• SPF定期更新：includeなどの参照先を定期的にモニタリング・更新
• IPアドレス一覧：SPFレコードに含まれるIPアドレスを一覧で確認
• アラート通知：SPFの参照先でエラーが発生した場合などに通知

SPFレコードを継続的に確認・更新する負担を抑えられるため、複数のメール配信サービスやSaaSを利用している環境でも、SPFを管理しやすくなります。

ベアメールのSPFホスティングについて、詳しくは以下のページをご確認ください。
SPFルックアップエラーを効率よく解消するならSPFホスティング｜ベアメール

SPFフラット化に関するよくある質問

最後に、SPFフラット化に関するよくある質問に回答します。

SPFフラット化でSPF PermErrorは解消されますか？

DNSルックアップ回数の上限超過が原因でPermErrorが発生している場合は、SPFフラット化によって解消できる可能性があります。

ただし、PermErrorはDNSルックアップ回数の超過以外に、SPFレコードの構文ミスや、同一ドメインに複数のSPFレコードが公開されている場合などにも発生します。そのため、まずはPermErrorの原因を確認したうえで、適切に対処することが重要です。

SPFレコードは255文字までにする必要がありますか？

SPFレコード全体を255文字以内にする必要はありません。DNSのTXTレコードでは、1つの文字列に記述できる長さに上限がありますが、複数の文字列に分けて1つのSPFレコードとして登録できます。

ただし、SPFレコードが長くなりすぎると、DNS応答サイズが大きくなるなど別の問題が生じる可能性があります。詳しくは「DNS応答サイズが大きくなり、SPF評価に影響する可能性がある」の章をご覧ください。

無料のSPFフラットニングツールを利用しても問題ありませんか？

無料のSPFフラットニングツールを利用すること自体に問題はありません。ただし、無料ツールのなかには、その時点のSPFレコードを展開してIPアドレスに置き換えるだけで、送信サービス側のIPアドレス変更には自動で追随しないものもあります。そのため、ツールの機能範囲を確認したうえで利用することが重要です。

継続的な運用を前提とする場合は、参照先を定期的に確認し、変更に合わせてSPFレコードを更新できるSPF管理サービスの利用も検討するとよいでしょう。

まとめ

SPFフラット化は、DNSルックアップ回数の上限超過を回避する方法の一つですが、IPアドレスの変更に追随しにくい、レコード管理が複雑になるといった注意点があります。一時的な対処法として活用しつつ、長期的には不要なincludeの整理や、SPFを継続的に管理できる仕組みの導入を検討するとよいでしょう。

ベアメールでは、SPFレコードの確認・更新を効率化できる「SPFホスティング」を提供しています。DNSルックアップ回数の上限超過やSPF管理にお悩みの方は、ぜひサービスページをご覧ください。
SPFルックアップエラーを効率よく解消するならSPFホスティング｜ベアメール