SPFフラット化とは？DNS参照回数の上限超過を回避する方法とリスク・代替策を解説

Last Updated on 2025.11.28

送信ログを確認した際に、「SPF Permerror」と表示されていたことはありませんか？これは、SPF認証が失敗した状態を示しています。

原因のひとつとして、DNS参照回数の上限（最大10回）超過が挙げられます。複数のSaaSやメール配信サービスを利用している場合に起こりやすく、結果として正規のドメインからのメールでも認証エラーになることがあります。

このような場合の応急処置として行われるのが「SPFフラット化」です。

具体的には、DNSルックアップを減らすために参照先を展開し、IPアドレスを直接記述します。ただし、ベンダーのIP変更に追随できない・更新作業が煩雑になるなど、運用上のリスクも少なくありません。

本記事では、SPFフラット化の仕組みと注意点、そして安定したメール運用を実現するための代替策について解説します。

SPFフラット化とは？

SPFフラット化は、SPF認証でDNS参照回数の上限（10回）を超えたことによるエラーを解消するための手法です。SPFレコード内の include（主に外部サービス参照）を事前に解決し、取得したIPアドレスを直接記述することで、DNS参照回数を減らします。

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

SPFとDNS参照

SPFは、受信サーバーが送信元のIPアドレスをドメインのSPFレコードと照合し、そのサーバーが正規の送信元かどうかを確認する仕組みです。この検証の過程で、ドメイン情報をDNSで参照します。

特に include メカニズムは、他ドメインのSPFレコードを読み込みます。そのレコードの中に include が含まれている場合、参照が連鎖的に増えていく構造になります。

例えば、下図の通りinclude:example.com を指定した場合、まず example.com のSPFを1回参照し、その中にある include:spf1.example.com や include:spf2.example.com をさらに参照します。

こうした入れ子構造によって、include の数が多いほどDNS参照回数が増えていきます。このように、SPF認証は仕組み上、参照回数が膨らみやすく、構成によっては上限を超えることもあります。

次に、この参照回数に設けられた制限と、それを超えた場合に起こるエラーについて説明します。

DNS参照の制限とエラー

SPFには、DNS参照は最大10回までという仕様上の制限があります（RFC 7208準拠）。これは無限ループやDNS負荷を防ぐために定められたもので、include だけでなく a、mxなどのメカニズムによる参照も対象となります。

複数のSaaSやメール配信ベンダーを併用していると、各サービスが自社SPFを include で追加するため、参照回数が連鎖的に増え、気づかないうちに上限を超えてしまうことがあります。上限を超えると、認証結果は「Permerror」となり、正規の送信元からのメールでもSPF fail扱いとなってしまいます。

その結果、受信拒否や迷惑メール判定を受けるケースもあり、配信安定性に大きな影響を与えることがあります。

SPFフラット化の仕組み

SPFフラット化は、このDNS参照回数の上限超過を一時的に回避するための対処法です。include や a、mx などの参照を一度すべて解決し、最終的にIPアドレスを直接SPFレコードに記述します。

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

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

これによりDNS参照回数を減らし、認証エラーを防ぐことができます。ただし、サービス側のIPアドレス変更に追随できないなど、運用上のリスクもあるため、SPFフラット化は恒久的な解決策ではなく、あくまで一時的な応急処置として扱うのが現実的です。

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

SPFフラット化は恒久的な対策には向きませんが、SPFエラー（Permerror）が発生した際の一時的な対応策として有効です。DNS設定やドメイン構成の見直しには時間がかかりますが、フラット化であれば、既存のSPFレコードを展開してIPアドレスに置き換えるだけで済みます。

システム構成を大きく変更せずに、DNS参照回数の上限超過をすぐに回避できるため、重要な通知メールやシステム連携メールの不達を防ぎながら、恒久対策が整うまでの間の安定運用を維持できます。

特に複数のSaaSやメール配信サービスを併用している環境では、設定変更の影響範囲が大きいため、このようなリスクを抑えた一時対応として選ばれるケースが多く見られます。

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

SPFフラット化は一時的な対応策としては有効ですが、長期的な運用にはいくつかの注意点があります。便利に見える反面、仕組み上どうしても避けられないリスクもあるため、適用前に把握しておきましょう。

1. IPアドレス変更に追随できず、運用負荷が高い

SPFフラット化済みレコードは静的なため、利用しているサービス側で送信IPが変更されても自動で反映されません。

多くのメール配信ベンダーやSaaSでは、セキュリティ対策や冗長化の目的で送信IPを定期的に変更しています。この変更に対応するには手動でSPFレコードを更新し続ける必要がありますが、IPの追加・削除が予告なく行われるケースも多く、現実的には追随が難しくなります。

その結果、SPF認証エラーや配信不達を招くおそれがあるほか、更新作業の手間や担当者への依存が運用負荷を高める要因にもなります。

2. レコード文字数の制限に注意が必要

SPFレコードはDNSのTXTレコードとして登録されます。

TXTレコードには「1つの文字列（string）は255文字まで」という制限がありますが、複数行に分けて登録することで回避可能です。とはいえ、フラット化によってIPアドレスが増えるほどレコード全体が肥大化し、編集や確認のたびに構文ミスが起こりやすくなります。

レコード肥大化の主な影響は次の通りです。

• DNS登録時に入力ミスや構文エラーが発生しやすい
• 編集やレビューの際に内容を把握しにくくなる
• DNS応答サイズが512バイトを超え、分割送信や応答不安定を引き起こす可能性がある

上記を踏まえ、文字数制限は単なる仕様上の制約ではなく、設定ミスやDNS応答エラーを防ぐための運用上の注意点として捉える必要があります。

3. 可読性・メンテナンス性が低下する

フラット化によってSPFレコードが長大化すると、設定内容を把握しづらくなり、保守性が低下します。

どのIPがどのサービスに対応しているのか一目で分からず、誤って削除したり、重複して設定したりするリスクがあります。特に複数のドメインを運用している場合、各レコードを個別に更新する必要があり、どの設定が最新なのか把握しにくくなります。

結果として、設定ミスを防ぐための二重チェックや検証工数が増え、運用効率を下げる要因になります。

 SPFフラット化の代替策｜SPFホスティングサービス

SPFフラット化は一時的な応急処置としては有効ですが、長期運用には向いていません。恒久的な対策として有効なのが、SPFホスティングサービスの利用です。

SPFホスティングサービスは、SPFレコードの参照先を外部に委任し、ベンダー側が最新の送信IP情報を自動的に反映してくれる仕組みです。これにより、IP変更への追随の難しさやレコード更新作業の煩雑さといったフラット化の課題を根本的に解消できます。

ベアメールの SPFホスティング は、既存のSPFレコードをインポートするだけで設定でき、DNS参照回数超過や文字数制限を自動的に解消します。主な特長は次のとおりです。

• 自動更新機能：送信元のIPやホスト名の変更を自動検知し、最新状態を維持
• Web管理画面：SPF設定を一元管理し、DNS編集を不要化
• 通知機能：設定エラーや異常を自動検知し、管理者にアラート送信

これにより、レコードの短縮化・更新漏れ防止・認証結果の安定化を同時に実現。複数のメール配信サービスを利用する環境でも、DNS更新作業をほぼゼロにできます。

詳細については、資料をご確認ください。

ベアメール SPFホスティング機能 紹介資料

まとめ｜フラット化よりも運用負荷の少ない選択を

SPFフラット化は、DNS参照回数の上限を回避し、一時的にSPF Permerrorを防ぐための有効な手段です。しかし、IPアドレス変更への追随や更新作業の煩雑さ、レコードの肥大化といった問題があり、長期運用には向きません。

恒久的な方法としては、SPFホスティングサービスの利用が最も効果的です。最新のIP情報を自動で反映できるため、DNSの更新漏れや構成エラーを防ぎながら、常に安定した認証結果を維持できます。

SPFフラット化はあくまで一時的な対処法として捉えつつ、運用負荷を減らし、継続して安全なメール送信を実現できる仕組みを長期的な視点で整えることが大切です。