SPFフラット化
10件の検索制限を自動的に修正する
複雑なSPFレコードを1つのインクルードにまとめます。メールプロバイダーがIPアドレスを変更するたびに自動的に更新されます。手間いらずのアプローチです。DNSの設定変更も、メンテナンスも不要です。
SPFフラットニングとは？
SPFフラット化とは、複雑なSPFレコード（複数の「include:」、「a」、「mx」、または「redirect=」メカニズムを含むもの）を、解決済みのIPアドレスを直接記載した簡略化された形式に変換するプロセスです。受信メールサーバーに対して、各メールプロバイダーがどのIPアドレスを使用しているかを個別に照会するよう指示する代わりに、フラット化されたレコードでは、それらすべてを事前に解決し、その結果をDNSに直接記述します。
DNS検索の10回制限の仕組み
受信メールサーバーがSPFレコードを評価するたびに、各「include:」、「a」、または「mx」メカニズムに従って、承認されたIPアドレスを特定します。RFC 7208（正式なSPF仕様）では、この解決の連鎖におけるDNS検索回数は10回までに制限されています。この上限を超えると、SPFはPermError（恒久的なエラー）を返します。これにより、通常、正当なメールでも認証に失敗し、スパムフォルダに振り分けられたり、完全に拒否されたりすることになります。
上限を超えた場合（PermError）
レコードの完全な解決に10回以上のルックアップが必要な場合、メールサーバーは10回目のルックアップで評価を停止するため、それ以降にリストされている送信者は一切チェックされません。SPFはPermErrorを返し、DMARCポリシーによっては、チェックされなかった送信者からのメールが隔離されたり、拒否されたりすることがあります。この失敗は通常、何の通知もなく発生します。バウンス通知が届くことはなく、単にメールが届かなくなるだけです。
サービス
SPFの作用機序
検索
Microsoft 365
include:spf.protection.outlook.com1（内包3つ）
Googleワークスペース
include:_spf.google.com1（内包3つ）
Mailchimp / Mandrill
include:spf.mandrillapp.com1（ネスト1つ）
セールスフォース
include:_spf.salesforce.com1（ネスト1つ）
SendGrid
include:sendgrid.net1（ネスト1つ）
Zendesk
include:mail.zendesk.com1
合計
—
~11 — 制限超過×
静的SPFフラットニングの根本的な問題
フラット化処理により、これらの「include:」メカニズムはすべて、その基盤となるIPアドレスに解決され、レコードに直接書き込まれます。理論上、これによりネストされたルックアップが完全に排除されます。実際には、静的にフラット化されたレコードの有効期間は予測可能です。つまり、利用しているメールプロバイダーのいずれかがIP範囲を変更した瞬間、 フラット化されたレコードは誤ったものになってしまいます。
Google、Microsoft、Mailchimp、SendGridはいずれも、そのインフラに依存しているドメイン所有者に通知することなく、送信インフラを更新している。
レコードの長さの制限
DNSのTXTレコードには、実質的なサイズ制限（1文字列あたり255バイト）があります。多数のIP範囲を含む完全に展開されたレコードは、この制限を超える可能性があり、その結果、そのレコード自体の検証に失敗することがあります。
継続的な保守の負担
新しいメールサービスを追加するたびに、再フラット化を行います。サービスを削除するたびに、再フラット化を行います。インフラが拡大するにつれて、この方法は維持できなくなってしまいます。
IPアドレスの変更を通知しない
SPF規格には通知機能は存在しません。ベンダーがIPアドレスを移動させた場合、配信率がすでに低下してからでないとその事実を知ることはできません。
当社の自動SPF平滑化機能の仕組み
PowerDMARCのSPFフラット化ツールは、PowerSPFのホスト型SPFサービスの一部であり、全プロセスを自動的に処理し、メールインフラストラクチャの変更に合わせてレコードを常に最新の状態に保ちます。
1
ドメインを追加する
サインアップしてドメインを追加してください。PowerDMARCは、手動での入力は一切不要で、現在のSPFレコードを即座に自動検出します。
2
ルックアップを分析する
レコードが使用するDNSルックアップの正確な数、どのサービスが最も多くを占めているか、そしてPermErrorのリスクがあるかどうかを確認できます。
3
ワンクリックで平らにする
すべてのインクルード文は、現在のIPアドレスに解決され、1つの最適化されたインクルード文に圧縮されます。カウントは1に減少します。
4
導入して、最新の状態を維持する
新しいレコードを公開します。PowerDMARCはベンダーを監視し、IPアドレスが変更された際に自動的に再構築を行うため、情報が古くなることはありません。
手動によるフラット化と自動SPFフラット化の比較
手動での平坦化
手作業による追跡に起因する業務上のボトルネックや、目に見えない摩擦。
検索制限が頻繁に超過しています
サードパーティのサービスを手動で追加すると、DNSのルックアップ数がすぐに10件の制限を超えてしまい、予告なしにメールの配信が中断されてしまいます。
目立たないSPFの不具合
ベンダーが基盤となるIPアドレスを更新すると、配信の不具合に気づくまで、手動で設定した静的レコードは気づかれないまま古くなってしまいます。
無限のキャラクター成長
サブレコードを手動で展開すると、文字列が急速に膨れ上がり、個々のDNS文字列に対する255文字という厳格な制限を容易に超えてしまう。
ヒューマンエラーを起こしやすい
入力ミスをしたり、構文を誤って記述したり、長いIP範囲のブロックを誤ってコピーしたりすると、重大なセキュリティ上の問題や配信障害を引き起こす原因となります。
維持や監視が困難
標準的な業務アプリケーションの追跡を維持するだけでも、継続的な手動監査、スプレッドシートによる監視、そして開発者の作業時間が必要となります。
VS
PowerDMARCの動的SPFフラットニング
お客様のネイティブ環境内に構築された、自動化され、効率的なセキュリティインフラストラクチャ。
自動的に制限範囲内に収まる
高度な動的マッピング機能により、多数のルックアップが自動的に、10ルックアップというプロトコルの最大閾値以下に安全に集約されます。
IPアドレスが変更されると自動的に再フラット化されます
バックグラウンドで動作する自動チェックスクリプトが、システムベンダーの変更を即座に検知し、数分以内にネットワークの更新情報をシームレスに自動更新します。
最小サイズまで圧縮
インテリジェントなアルゴリズムによるテキストブロックの折り返し処理により、不要な構文スペースが削除され、レコードが圧縮されて文字の移動経路が最小限に抑えられます。
完全自動化されており、手動での編集は不要です
リスクを伴う手作業による構造的な操作を排除し、ソフトウェアのルールに基づいてプラットフォームの設定を体系的に管理することで、エラーのない状態を維持します。
一度設定すれば、いつまでも有効
1つの恒久的な静的エンジン構成ハンドルを展開し、長期的なデジタルドメイン認証パラメータを継続的に保護する。
SPFによる平坦化のリスクとベストプラクティス
SPFフラット化は正当な手法ですが、特に手動でレコードを管理する予定がある場合は、これに依存する前に理解しておくべきリスクが伴います。
始める前に知っておくべきリスク
IPアドレスの変更— 大手プロバイダーは、送信用IPアドレスの範囲を定期的に変更しています。変更が行われると、新しいIPアドレスからのメールは直ちにSPF検証に失敗しますが、配信率が低下して初めてそのことに気づくことになります。
レコードの肥大化とDNSの制限— 多数のサービスを持つ組織のレコードは、平坦化されると数百ものIPエントリに膨れ上がり、実用的なサイズ制限を超えてしまい、Permerrorを引き起こす可能性があります。
メンテナンスの負担— 手動での記録は、一度行えば済むものではありません。サービスを追加したり、削除したり、あるいはベンダーにインフラの更新を依頼したりするたびに、データを再整理して再公開する必要があります。
ベストプラクティス
アクティブで正当な送信者のみを承認する— フラット化を行う前に、レコードを監査し、使用しなくなったサービスのインクルードを削除してください。不要なエントリが1つ増えるごとに、検索回数が増え、攻撃対象領域も拡大します。
DMARCレポートでSPFの合格率・不合格率を監視する— 集計レポートには、どの送信元が合格し、どの送信元が不合格になったかが正確に示されます。フラット化後に原因不明の不合格が発生した場合は、通常、IP範囲が古くなっていることが原因です。
SPFはDKIMやDMARCと併用してください。SPFだけではなりすましを防ぐことはできません。適切な認証には、これら3つすべてが必要です。SPFとDKIMは整合性を確保するため、DMARCはそれらが失敗した際の対応を定義するために必要です。
インフラの変更後は必ず再検証を行う— メールサービスを追加または削除した際は、その設定が依然として有効であると決めつける前に、SPFチェッカーでレコードを確認してください。
世界中で数千人の信頼
ジェニファー・ハイゼル
システム管理者
「PowerDMARCのホスト型SPFを利用することで、当社のドメインにおけるSPF照会制限が解消されました。DNSに公開する必要があるのは、たった1つのSPFレコードだけです。」
デビッド・スピゲルマン
社長
「PowerDMARCは、特にSPFエラーに大いに役立っている。"SPFフォールディング "を簡単に行えるようにすることで、技術的に許容される以上のSPFインクルードが必要な顧客のために、しばしば必要とされるのだ。
ディラン・バウタース
テクノロジー・セキュリティ・コンサルタント
"SPFフラット化によって、我々はSPFを簡単に拡大し、レコードの詳細を検査することができるようになった"
よくあるご質問
SPFレコードのルックアップ数が10を超えるとどうなりますか？
メールボックスプロバイダーは、10回目の照会以降はSPFの確認が困難になるため、SPFレコードがこの制限を超えると、通常はPermErrorとなり、正当なメールが拒否されたり、スパムフォルダに振り分けられたりすることがあります。
SPFの平坦化はセキュリティを向上させるか？
フラット化はSPFのセキュリティを向上させるものではありません。単に10ルックアップ制限内に収まるよう支援し、SPF設定の精度を高めるだけです。真の保護は、SPF + DKIM + DMARCが連携して機能することで実現します。
Google/Microsoftから提供されたレコードを平坦化すべきですか？
GoogleやMicrosoftなどの主要メールプロバイダーはIPアドレスを頻繁に更新するため、手動でフラット化したレコードは更新を続けなければすぐに古くなります。PowerDMARCのような動的ソリューションがこの問題を解決します。
いつ再平坦化すべきか、どうすればわかりますか？
手動でのフラット化では、メールサービスを追加または削除する時、あるいはプロバイダーがIP範囲を更新した時が、レコードを再フラット化する適切なタイミングです。レポートで突然のSPF失敗が発生した場合も、再フラット化の必要性を示すサインです。当社のSPFフラット化ツールでは、この作業が自動化され手間がかかりません。
2026年でも平坦化は依然として推奨されるのか？
従来のフラット化は特定のケースでは依然有用ですが、長期的な解決策ではありません。ベンダーがIPを頻繁に変更し、自動化が標準化する中、PowerSPFのような動的SPFソリューションが急速に信頼性の高いアプローチとなりつつあります。
SPFフラットニングとSPFマクロの違いは何ですか？
SPFのフラット化処理では、すべての「include:」メカニズムを直接的なIPアドレスに解決し、レコードに書き込みます。これによりルックアップ回数は削減されますが、ベンダーのIPアドレスが変更されるたびに更新が必要な静的なスナップショットが生成されます。一方、SPFマクロは評価時に解決される動的な変数を使用するため、ベンダーのインフラが変更されてもレコードを更新する必要はありません。マクロは技術的に優れていますが、正しく実装するにはホスト型SPFサービスが必要です。 ほとんどの組織にとっては、自動化されたフラット化で十分ですが、複雑なマルチドメイン構成を持つエンタープライズ環境においては、マクロの方が長期的に見てより堅牢な解決策となります。
同じドメインに2つのSPFレコードを設定することはできますか？
いいえ。RFC 7208 では、同一ドメインに複数の SPF レコードを設定することが明示的に禁止されています。受信サーバーが 2 つ以上の SPF TXT レコードを検出した場合、PermError を返し、両方のレコードは無視されます。SPF レコードは、正しく設定されたものを 1 つだけ用意し、10 回のルックアップ制限内に収める必要があります。
SPFレコードの設定を修正する準備はできましたか？
SPFの平坦化は、繰り返し発生する問題である必要はありません。当社のツールを使えば、手間いらずです！
