SPFフラット化：SPFフラット化とは何か？

SPF（Sender Policy Framework）は、 電子メール認証プロトコル であり、なりすまし攻撃を防ぐ上で極めて重要な役割を果たします。SPFは、組織のドメインに代わって電子メールを送信する権限を持つ送信者（メールサーバー）を指定することで機能します。

ただし、SPFには特有の制限があります。それは、 RFC 7208の4.6.4節で言及されている通り、DNSルックアップの制限は10クエリ という制限があります。このルックアップ制限を超えるSPFレコードは正常に動作せず、 恒久的なエラー（PermError）を返します。を返します。この制限を解決するための効果的な解決策として、ここでSPFフラットニングが活用されます。

SPFによる平坦化が最も必要なのは誰か？

• 5つ以上のドメインを管理している企業
• 複数のクライアントテナントをサポートするMSP/MSSP
• 月間10万通以上のメールを送信する組織
• コンプライアンス重視の業界（金融、医療、政府機関）

SPFフラットニングとは？ 

SPFフラット化は、SPF DNSレコードを簡素化し、最適化します。これにより、生成されるDNSルックアップの数を減らし、ドメイン所有者が許可されたDNSクエリの制限内に留まることを保証します。ネストしたインクルードを統合し、間接参照を対応するIPに置き換えることで、レコードを単一の包括的なエンティティに変換し、エラーのないSPF認証を実現します。 

例

フラット化前： v=spf1 include:example1.com include:example2.com ~all

フラット化後 v=spf1 ip4:192.168.1.1 ip4:192.168.2.2 ~all

SPFレコードをフラットにすることで、"include "メカニズムを直接IPアドレスに置き換え、DNSルックアップを最小限に抑える。

SPFフラットニングはいつ使うべきか？

SPFフラット化は、従来のSPFレコードが問題となる特定の状況において、最も効果を発揮します。この手法をいつ適用すべきかを理解することで、メール認証戦略について適切な判断を下すことができます。

SPFのフラット化における理想的なシナリオ：

• DNS ルックアップの制限超過：SPF レコードの処理に 10 回を超える DNS ルックアップが必要な場合。
• 複雑な送信者設定：5つ以上のサードパーティ製メールサービス（マーケティング、トランザクション、サポート）を利用している組織。
• 大量メール配信業務：複数のプラットフォームを横断して、毎月10万通以上のメールを送信する企業。
• コンプライアンス要件：厳格な電子メール認証管理を必要とする規制対象業界 — 特に、Google、Yahoo、Microsoftが現在、コンプライアンスに準拠していない大量送信者のメールを積極的に拒否している状況下では。

SPFフラットニングを使用すべきでない場合：

• 簡単なメール設定：メールサービスを3つ未満しか利用していない組織。
• プロバイダーを頻繁に変更する場合：メールサービスプロバイダーを定期的に切り替えている場合 （プロバイダーのIPアドレスが頻繁にローテーションされるため、手動でのフラット化は負担となります。例えば、Googleは2025年だけで_netblocksを複数回ローテーションしました）。
• 技術リソースの不足：適切な監視および保守体制が整っていない。

なぜSPFフラット化が不可欠なのか？

Flatteningのような最適化テクニックを使ってSPFレコードを単純化すると、いくつかの利点がある： 

1.コンプライアンスの維持

SPFレコードは、DNS検索の制限を遵守することが必須です。フラット化を行うことでSPFレコードを簡素化し、制限値内に収めることができるため、IETFによって文書化された電子メール認証プロトコルに関するRFCで規定された規則への準拠を維持できます。 DMARCbisがRFC 9989、9990、および9991（2026年5月公開）として正式に策定されたことで、電子メール認証に関する標準はさらに厳格化されました。適切に管理されたSPFレコードは、SPFおよび 

DMARCのアラインメントチェック。この準拠により、メールを受信するメールサーバーから見て、お客様のドメインの信頼性が維持されます。

2.メール配信性の向上

SPF照会制限を超えるメールは、しばしば不審なものとみなされ、受信者のメールサーバーによってフラグが立てられたり、場合によっては拒否されたりすることがあります。これにより、メールの配信に問題が生じます。SPFフラット化を行うことで、SPFが許容範囲内に収まるよう確保され、その結果、メールの信頼性が高まり、配信に関する問題が解決されます。 

これは、2025年から2026年にかけて特に重要であり、 Googleが認証に失敗したメールを 、また Microsoftも同様の大量送信者向けルールを適用しており SPF、DKIM、DMARCの適用を義務付けるなど、同様の大量送信者向けルールを施行している。

3.なりすましメールのリスク軽減

SPFと DMARCと組み合わせ、さらにフラット化を利用してSPFを最適化することで、フィッシングやスプーフィングといったメールを悪用したサイバー攻撃のリスクを低減できます。DMARCの実装が、許容限度を超えるSPFと組み合わされている場合、SPFの検証に失敗すると、正当なメッセージであってもDMARCの検証に失敗することになります。

最近の業界データによると、2026年初頭時点でDMARCの導入ドメイン数は93万7,000を超えたが、強制レベルのポリシー（隔離または拒否）の適用数は依然として約41万2,000にとどまっている。「フラット化」による適切なSPF管理は、DMARCが整合性を評価する前にSPFが確実に通過するよう保証することで、このギャップを埋めるのに役立つ。

SPFフラット化の仕組み

手作業でSPFを平坦化することもできるし、自動化されたオンラインツールを使って高速化することもできる。両方を試してみよう： 

手動SPF平坦化

手動でSPFレコードをフラットにするには 

ステップ1.SPFレコードを分析する:すべてのインクルードとネストされたルックアップを特定する。

ステップ2.ルックアップを統合する:includeを直接IPアドレスまたはCIDR範囲に置き換える。

ステップ3. フラット化されたレコードのテスト: DNSでレコードを手動で確認するか、オンラインSPFチェッカーツールを使用して、平坦化されたSPFレコードを検証してください。 オンラインSPFチェッカーツール を使用して、準拠性と機能性を確認してください。

自動SPFフラット化

PowerDMARCのSPFフラット化ツールを使用すると、SPFレコードを自動的にフラット化できます。その仕組みは以下の通りです： 

ステップ1： サインアップ PowerDMARCプラットフォームにサインアップする。

ステップ2：Hosted Services "の下にあるPowerSPFをクリックする。

ステップ3：ドメインを追加し、アクティブドメインを選択します。

ステップ4：自動セットアップ」をクリックし、PowerSPFを有効にする。

注: メールサービスプロバイダーは、ユーザーに通知することなくIPアドレスを追加または変更することがよくあるため、手動によるSPFフラット化は推奨されません。ユーザーは、常にこれらのサービスの変更情報を把握しておく必要があります。そうしない限り、不要なSPFエラーにつながり、正規のメールが配信されなくなる可能性があります。このため、自動フラット化は手間のかからない方法であり、信頼性と効果の両面で明らかに勝者である。

SPFフラットニングにPowerDMARCを選ぶ理由は？

• 統合ダッシュボード： SPF、DKIM、DMARC、MTA-STS、BIMIを単一のプラットフォームから管理できます。
• コンプライアンス対応： 完全な監査証跡を備え、規制対象業界向けに設計されています。
• SPFマクロのサポート： PowerDMARCは、 PowerSPFの一環としてホスト型SPFマクロ を提供している数少ないプラットフォームの一つです。これは、従来のフラット化よりも効果的で、成功率も高いソリューションです。
• 24時間365日対応のグローバルサポート： いつでも、どこからでも、迅速に対応する当社の専門家チームにご連絡いただけます。
• AWS および Azure Marketplace： 現代の企業に向けた柔軟な導入オプション。
• マルチドメイン、マルチテナント環境に対応した拡張性： エンタープライズおよび MSP/MSSPのニーズ。
• 透明性の高いレポート機能： 認証状況と配信状況をリアルタイムで可視化。

SPFフラット化の代替手法

SPFのフラット化は効果的ですが、従来のフラット化に伴うメンテナンスの負担をかけずに、SPFレコードの制限に対処するのに役立つ代替手法がいくつかあります。

1. SPFマクロ

SPFマクロは、動的変数（%{i}、%{s}、%{h}）を使用してクエリ実行時にルックアップを解決するため、機能を維持しつつレコードの長さを抑えることができます。このアプローチにより、従来のフラット化手法に見られる静的IPの制限を回避できます。

2. サブドメインの委任

メインドメインのSPFレコードの複雑さを軽減するために、メール送信をサブドメイン（例：marketing.example.com、support.example.com）に分散させます。 このアプローチは、特に 複数のドメインにわたってDMARCを管理している組織。

3. 送信者の統合

類似した機能をより少ないプロバイダーに統合することで、サードパーティのメールサービスの数を減らし、その結果、DNS検索の要件を自然に削減します。

SPFの平坦化に関するベストプラクティス

平坦化されたSPFレコードが本来の性能を発揮していることを確認するには、以下のヒントを考慮するとよい：

1.フラット化されたSPFレコードを監視する

SPFレコードは、メールサービスプロバイダーやベンダーによる自社のIPアドレスや送信サーバーの変更に大きく左右されるため、頻繁に変更される傾向があります。フラット化されたSPFレコード（特に手動でフラット化されたもの）は、しばしば古くなってしまい、その結果、ルックアップ制限エラーが再発することがあります。そのため、定期的な見直しを行い、変更の有無を確認するとともに、SPFレコードをプロアクティブに監視・更新するPowerDMARCの自動化ツールを活用して、必要に応じてSPFレコードを更新することが重要です。

フラット化されたSPFレコードはどのくらいの頻度で更新すべきですか？

手動でフラット化されたレコードについては、毎月、あるいはメールサービスを追加・削除するたびに確認・更新を行ってください。PowerSPFのような自動化ソリューションでは、手動での操作を必要とせずに継続的に更新が行われます。 2026年の業界ベストプラクティスでは、信頼性の高い最新性を維持するために、自動化ツールは少なくとも15分ごとに上流ベンダーのIP範囲を再スキャンすべきであるとされています。 更新を怠った場合のリスクとしては、メール配信の失敗、認証エラー、および潜在的なセキュリティ上の脆弱性が挙げられます。

2.SPFレコードの簡素化

SPFレコードをフラット化する際には、シンプルさと管理しやすさにも留意する必要がある。広範で複雑なSPF設定は、認証時にエラーや複雑さをもたらすことが多い。フラット化は、IPアドレスや範囲を含むメカニズムに置き換わるため、文字列が長くなり、SPFの長さ制限である255文字を超えてしまうことがある。

3.SPFマクロの使用

SPFフラット化の欠点を解消し、はるかに効果的で信頼性の高い手法が、マクロの最適化です。この手法により、ルックアップ、 void 、および長さの制限がほぼすべてのケースで超過されないことを保証し、フラット化と比較して失敗率がはるかに低くなります。

SPFのフラット化における一般的な課題

ここでは、ドメイン所有者が従来の平坦化方法を使用する際に直面する可能性のあるいくつかの問題と、簡単な解決策を探ってみましょう：

1.アップデートの管理

承認済みサーバーに変更があった場合は、フラット化されたレコードの更新が必要となります。この問題を回避するには、定期的な監査をスケジュールし、SPFレコードをプロアクティブに監視・更新するPowerDMARCの自動化ツールを活用することが有効です。

2.長いSPFレコード

IP参照を実際のIPに置き換えると、文字数制限を超える非常に長いレコードになる可能性がある。これを回避する方法は、フラット化の代わりにマクロを使用することである。

3.SPFレコードの設定ミス

レコードの設定ミスはメールの混乱を招きます。信頼できるSPFフラット化ツールやサービスを利用し、必要に応じて専門家によるサポートを受けてください。

関連記事： SPFエラー：その意味と解決方法

避けるべきSPF配合のフラットニングにおけるよくある間違い

こうしたよくあるミスを避けることで、多額の損失につながるメール配信の失敗やセキュリティ上の脆弱性を防ぐことができます：

1. レコード長違反

間違い： DNS TXTレコードの制限である255文字を超えるフラット化されたレコードを作成すること。

予防策： 複雑な設定の場合は、SPFマクロまたはサブドメインの委任を使用してください。

2. プロバイダー変更後の更新漏れ

間違い： メールサービスプロバイダーがIPアドレス範囲を変更した際に、その変更を監視していないこと。

予防策： 自動監視を導入するか、PowerDMARCのPowerSPFを利用して継続的な更新を行う。 GoogleやMicrosoftなどの主要プロバイダーは、送信IP範囲を定期的に変更しています。古くなったフラット化されたレコードがあると、正当な送信者が知らぬ間に送信権限を失う可能性があります。

3. フラット化されたレコードにおける構文エラー

間違い： インクルード文を手動でIPアドレスに変換する際に、構文エラーが発生してしまう。

予防策： デプロイを行う前には、必ずSPFチェッカーツールを使用して、フラット化されたレコードの有効性を確認してください。

4. 単純なレコードの過度な平坦化

誤り： 実際にはDNSルックアップの制限である10件を超えていないSPFレコードを平坦化してしまうこと。

予防策： まず現在のSPFレコードを分析し、フラット化が必要かどうかを判断してください。

SPFフラットニングとSPFマクロ：簡単な比較

2026年にDMARCbis（RFC 9989）がSPFのフラット化に与える影響

2026年5月にDMARCbisがIETFの公式標準（RFC 9989、9990、および9991）として公開されたことは、2015年の初版リリース以来、DMARCにとって最も重要な更新となります。 DMARCbisはSPFルックアップの制限自体を変更するものではありません（これは引き続きRFC 7208によって規定されます）が、SPFの結果がDMARCの整合性判定にどのように反映されるかに関する要件を厳格化しています。

SPFのフラット化に関する主な示唆：

• DMARCbisは、DMARCを情報提供目的のRFCから「提案標準」へと格上げするものであり、エコシステム全体においてより厳格な実装要件が求められることを意味します。
• SPFのPermErrorも、DMARCの失敗としてカウントされます。DMARCの整合性を確保するためにSPFに依存している組織は、10回のルックアップ制限を超えてはなりません。
• 更新されたレポート基準（RFC 9990 および 9991）により、SPF エラーの可視性が向上し、フラット化に関連する問題の診断と修正が容易になりました。

詳細はこちら： DMARCbisの解説 – 変更点と準備方法

SPFフラット化がメール戦略に重要な理由

SPFフラット化は、メールによるコミュニケーションに依存している企業にとって不可欠な対策です。SPFルックアップの制限に対処することで、中断のないメール配信を保証し、なりすましに対する防御を強化し、メール戦略を最適化することができます。

Google、Yahoo、Microsoft、Appleがいずれも大量送信者に対してSPF、DKIM、DMARCの適用を義務付けるなど、メール認証の徹底が進む中、DMARCbis規格も正式に公開された今、適切なSPF管理はもはや任意の措置ではありません。これは2026年以降におけるメール配信成功率を確保するための基本要件です。

今すぐ行動を起こしましょう： ドメインのセキュリティを確保し、メールの配信率を向上させるために、SPFフラットニングの導入を開始しましょう。サポートが必要ですか？ ぜひ 。プロセスを簡素化する自動化されたSPFフラット化ツールについてご案内いたします。

よくあるご質問

SPFフラット化には限界があるのか？

SPFフラット化には、マクロをより効果的な代替手段とするための制限がある。以下に、その制限を探ってみよう：

フラット化には手動での更新が必要： SPFのフラット化では、メールプロバイダーがIPアドレスを変更したり追加したりするたびに、常に手動での更新が必要となります。

平坦化により長さの制限が生じる可能性があります： 平坦化されたSPFレコードは極めて長くなり、SPFレコードの長さ制限を容易に超えてしまい、エラーの原因となる可能性があります。

SPFの失敗要因： 従来のフラット化処理では動的IPアドレスの更新が行われないため、SPFエラーが発生する可能性があります。

管理上の複雑性： SPFのフラット化には定期的な手動による介入や更新が必要であるため、複数のサードパーティ製メールベンダーを利用している組織にとっては、大きな複雑さをもたらす可能性があります。

SPFフラット化はどのように新しいメール送信者に適応するのか？

動的なSPFフラット化サービスや、PowerSPFのような自動フラット化ツールは、新しいメール送信者に適応することができます。しかし、従来のフラット化手法については、そうは言えません。従来のフラット化では、送信者のSPFレコードにメール送信者が自動的に更新されないため、意図しない認証エラーが発生する可能性があります。

SPFフラット化で認証済みメール送信者のコンプライアンスを確保する方法

SPFフラット化は、認証されたIPと認証されたメール送信者のみを含めることで、コンプライアンスを維持するのに役立ちます。これにより、不正なメールリレーのリスクを低減します。フラット化サービスは、SPFレコードを最適化し、DNSルックアップの10回制限を超えないようにすることで、RFCの制限に確実に準拠します。これは、自動または手動チェックを使用している組織に特に当てはまり、SPFレコードが常に最新であることを保証します。

SPF Flatteningは、重複送信者や重複IPレンジをどのように処理しますか？

重複するIPを効率的に管理するために、SPFフラット化は冗長なエントリを削除し、重複するIPを統合することで、ドメインのSPFレコードを簡素化します。重複するIP範囲を統合し、リストされたすべてのIPが検証済みの送信者に属していることを確認し、競合するエントリがないようにすることができます。

SPFフラットニングの使い方とは？

SPFのフラット化は、インクルード機構を直接的なIPアドレスに置き換えることで手動で実装することも、PowerDMARCのPowerSPFなどのツールを使用して自動的に実装することも可能です。信頼性と継続的な更新の観点から、自動化されたアプローチが推奨されます。

すべてのドメインでSPFフラット化を使用すべきでしょうか？

いいえ、SPFのフラット化が必要になるのは、SPFレコードがDNSルックアップの制限である10件を超えたり、管理が困難なほど複雑になったりした場合のみです。サードパーティのサービスがほとんど使われていないシンプルなメール環境では、通常、フラット化は必要ありません。

フラット化されたSPFレコードは、どのくらいの頻度で更新すべきですか？

手動で平坦化されたレコードは、毎月、あるいはメールサービスに変更があった都度、確認する必要があります。PowerSPFのような自動化ソリューションは継続的に更新されます。更新を怠ると、メールの配信失敗や認証エラーにつながる可能性があります。

SPFフラット化に代わる方法にはどのようなものがありますか？

主な代替案としては、SPFマクロ（動的解決）、サブドメインの委任（サブドメイン間でメールを分散させること）、および送信元の統合（メールサービスプロバイダーの数を減らすこと）などが挙げられます。

DMARCbisによって、SPFのフラット化の仕組みは変わるのでしょうか？

いいえ、DMARCbis（RFC 9989、2026年5月公開）は、RFC 7208で規定されているSPFルックアップの制限を変更するものではありません。ただし、DMARCbisではDMARCのアラインメント要件が厳格化され、レポート基準も改善されているため、アラインメントチェックを確実に通過できるよう、SPFレコードに誤りがない状態を維持することがこれまで以上に重要になっています。