コラム
SPFフラット化とは？
～SPFフラット化の仕組みとその問題点～
SPFの仕組みとSPFフラット化の問題点を解説します
※本ページは、Valimail公式サイトのBlog に掲載された記事を翻訳・編集し、日本向けに作成されています。
-https://www.valimail.com/blog/what-is-spf-flattening/
１．はじめに：SPFとDMARCにおける課題
メール認証の仕組みを強化し、DMARCをエンフォースメント（p=quarantine や p=reject）に移行するうえで、
多くの組織が直面する大きな課題の一つがSPF（Sender Policy Framework）です。
もし、自社ドメインを使って送信を許可すべきすべての送信元を正しくSPFに登録できなければ、DMARCをエンフォースメントすることはできません。
承認漏れがある状態でエンフォースメントを設定すると、正規のメールまでもが拒否や隔離の対象になってしまいます。
SPFは非常に有効な仕組みですが、その仕様には「DNSルックアップ制限（10回まで）」という大きな壁があります。
これを回避するために一部の組織が使うのがSPFフラット化ですが、実はこれは根本的な解決にはなりません。
２. DNSルックアップ制限（10回まで）とは？
SPFでは、レコードの中で別のドメインを参照するときにDNSルックアップが発生します。
この場合、受信サーバーは example.com のSPFレコードを確認します。これが1回のルックアップです。
さらに example.com の中に別の include: があれば、そこで追加のルックアップが発生します。
このようにSPFレコードが入れ子（ネスト）構造になると、ルックアップ回数はどんどん増えていきます。
SPF規格では、DNSルックアップが10回を超えると認証は即座に失敗します。
つまり、正しいサービスから送信されたメールであっても「確認できなかった」という理由で認証エラーとなり、迷惑メール扱いや拒否につながるリスクがあります。
３．SPFフラット化とは？
SPFフラット化とは、この「10回ルックアップ制限」を避けるために、SPFレコードに含まれる参照ドメインをIPアドレスに展開して直接記載する方法です。
通常は include: ステートメントを使って他のドメインを参照しますが、フラット化ではそれを削除し、代わりにIPアドレスを直接列挙します。
こうすることでDNSルックアップ数を減らし、10回の制限を超えないように見せかけるのです。
各ドメインを展開して、すべての IP を直接一覧表示します。
このように include: を削除し、代わりにその参照先のIPアドレスを直接列挙します。
理論的にはDNSルックアップを消費しないため「10回制限」を回避できるように見えます。
４．SPFフラット化の問題点
SPFフラット化は短期的な回避策に見えますが、実際には根本的な解決どころか、新たな問題を生む手法です。
多くの組織は「10回制限に到達して困ったとき」に安易にSPFフラット化を試みます。
最初は単純で効果的に思えるかもしれませんが、時間の経過とともに深刻な問題が現れます。
＜主な問題点＞
- サービスプロバイダー側の変更とそのメンテナンスの負担
クラウドサービスやメール配信サービスは、送信に使うIPアドレスを頻繁に追加・削除します。
多くの場合、こうした変更は顧客に通知されません。SPFレコードを常時確認し、手作業で更新し続ける必要があります。
そのため、フラット化したリストを維持するには、管理者が自力で変更を追跡し続ける必要があります。 - 人的エラーのリスク
長大なIPアドレスのリストを手で管理するのは非常に困難です。
・IPv4とIPv6が混在すると表記が複雑になりやすい
・数値、記号の入力ミスやピリオドの記載漏れ
・構文の間違い
といったエラーが発生しやすく、それが原因でSPF認証が失敗するリスクが高まります。 - 複数レコード化のリスク
IPアドレスのリストが大きくなりすぎると、1つのSPFレコードに収まらなくなることがあります。
その場合、複数のレコードに分割し相互参照させますが、結局は再び「10回ルックアップ制限」にぶつかる可能性があります。 - 管理性の欠如
膨大なIPアドレスの羅列を見ても「どのIPアドレスがどのサービスに対応しているのか」が分かりません。
メモを残していなければ、別の管理者に引き継ぐことも困難です。
結論として、SPFフラット化は「10回制限」という1つの問題を解決する代わりに、
メンテナンス負担・信頼性低下・認証失敗リスクという大きな問題を新たに作り出し、長期的には機能しない解決策といえるのです。
５．Valimail Instant SPFという解決策
こうした課題を根本的に解決するのが、Valimailの特許技術Instant SPFです。
Instant SPFは、受信サーバーからの問い合わせに応じて、その時点で最新かつ正確なSPFレコードを自動生成して返す仕組みを採用しています。
これにより、サービスやクラウドプロバイダーがIPアドレスを追加・削除しても、自動的に反映され、常に正確なSPF認証を提供します。
＜特長＞
- SPFに完全準拠
SPF規格に完全準拠しており、SPFに準拠したすべてのメール受信サーバーで処理可能です。 - リアルタイム生成
受信サーバーからSPFの問い合わせがあるたびに、完全に調整されたSPFレコードをミリ秒単位で自動生成して返答します。 - 常に最新状態
送信サービスのネットワークやIPが変更されても即座に反映。
24時間365日、すべてのメールについて100%の精度を保証します。 - SPFフラット化不要
IPアドレスを静的に書き出す必要がなく、「10回ルックアップ制限」を動的に回避します。 - Valimail Heliosとの連携
世界中の何千もの送信サービスの設定情報を連携済み。管理者は利用サービスをリストから選択するだけで、常に正しいSPF設定を維持できます。
６．よくある質問（FAQ）
Q. SPFフラット化とは？
A. SPFレコード内の include: を展開し、参照先のIPアドレスをSPFレコードに直接列記する方法です。DNSルックアップ回数を減らす狙いがありますが、静的リストはすぐに古くなり、メンテナンス負担が増えます。
Q. なぜ一部の組織はSPFフラット化を選ぶのか？
A. SPFのDNSルックアップ制限（10回まで）を避けるためです。ただし、これは一時的な回避にすぎず、古いIPアドレスの残存やSPFレコードの誤記など新しい問題を引き起こします。
Q. DNSルックアップ制限を超えるとどうなる？
A. SPF認証が失敗し、正規のメールが拒否や隔離の対象になります。受信サーバーは「なぜ制限を超えたか」を考慮せず、単純に「失敗」と処理します。
７．まとめ
SPFフラット化は、表面的にはDNSルックアップ制限（10回まで）の回避策のように見えますが、
実際には更新負担・人的ミス・認証失敗を招くリスクが高い方法です。
ValimailのInstant SPFは、リアルタイム生成と自動更新により、この問題を根本から解決します。
DMARCを確実にエンフォースメントまで進めたい企業にとって、最も信頼できる選択肢といえるでしょう。