SPFの「10回制限」を解決する、SPFフラット化とSPFホスティングの違いを解説
「最近、正しいメールが迷惑メールに振り分けられるようになった」「ある日突然、重要な相手にメールが届かなくなった」。
こうした現象はメール担当者の悩みの上位に挙がります。その背景には、送信ドメイン認証の設定、特にSPF(Sender Policy Framework)の問題が潜んでいます。
クラウド型のメールサービスや外部配信プラットフォームを複数併用すると、SPFレコードに記述する include: が増加しやすくなります。
SPF検証では、こうした外部参照(DNSルックアップ)を最大10回までしか行えない制約があるため、超過するとSPFが正しく評価されず、配信不達や迷惑メール判定につながります。
本記事では、この「10回制限」を巡る代表的な解決策であるSPFフラット化と、運用負荷を大幅に下げるSPFホスティングの違いを分かりやすく解説し、主要サービスの比較と選び方まで提示します。
SPFとは?
SPFの役割と仕組み
SPFは、送信ドメインのDNSに記述されたTXTレコードを参照して
「そのドメインが指定したサーバーから送信されているか」
を受信側が検証する仕組みです。
なりすましやフィッシング対策の第一歩として、古くから利用されています。
SPFの制約(特に重要な「10回制限」)
| 要素 | 概要 |
|---|---|
| 役割 | 送信ドメインの正当性を検証し、なりすましを防ぐ |
| 設定場所 | ドメインのDNS TXTレコードに記述(例:v=spf1 include:_spf.google.com -all) |
| 最大の制約 | SPF検証で辿るDNSルックアップは最大10回まで(include:やmx,a などを参照する際にカウント) |
なお、複数のメール配信サービスを利用すると、個別のSPF参照(include)が積み重なって容易に10回を超えてしまいます。
超過するとSPF評価が「PermError」などのエラーになり、受信側で拒否されることがあります。
SPFフラット化とは
SPFフラット化(SPF Flattening)とは、SPFレコード内の include: 等の外部参照をすべて解決して、最終的に
「許可されたIPアドレスやCIDR – Classless Inter-Domain Routing-(サイダー表記の例:ip4:203.0.113.0/24)」
を直接記述する手法です。このフラット化の目的はDNSルックアップ数を削減し、SPF制限を回避することです。
実例として:SPFレコードのフラット化のBefore / Afterを確認
| 状態 | レコード例 | ルックアップ回数 | 補足説明 |
|---|---|---|---|
| Before(複雑) | v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com -all |
複数(場合によっては10回超) | 複数サービスを併用した典型的な事例。各includeがさらに別の参照を持つと増幅する。 |
| After(フラット化) | v=spf1 ip4:209.85.201.1 ip4:167.89.0.0/16 ip4:198.2.134.0/24 -all |
0(IPを直接記述するためDNSルックアップ不要) | すべての参照を解決してIPに置き換えた状態。ルックアップ数が実質ゼロとなる。 |
SPFレコードフラット化のメリットとデメリット
| メリット | デメリット |
|---|---|
| DNSルックアップを大幅に削減でき、SPFエラーを回避しやすくなる | IPの変更が発生した場合、手動で更新する必要があり運用コストがかかる |
| 受信側でのSPF評価が安定し、到達率改善に寄与する | SPFレコードが長大化し、DNSの文字数/レコード制限に抵触する恐れがある |
| 小規模で変更が少ない環境ではコストを抑えられる | 手作業での運用は現実的でないため、自動化ツールや外部サービスが必要 |
フラット化は短期的・限定的な解決策として有効ですが、送信インフラ(クラウドサービス含む)が頻繁に変わる環境では維持が運用上困難になり、自動的にフラット化する技術が求められます。
SPFホスティングとは
SPFホスティングは、SPFレコードの
- 最適化
- フラット化
- 更新
を外部サービスに委託する運用モデルです。
自社DNSにはサービス側の1行(例:v=spf1 include:spf.example.com -all)だけを置き、実際のIP管理はサービス提供者が行います。
運用フロー
- 導入:ドメインのSPFをサービスの参照(include)に切り替える。
- 監視:サービスが各送信元のIP変更を自動検知する。
- 更新:検知した変更を即時または定期的に反映し、フラット化後のレコードを維持する。
SPFホスティングのメリットとデメリット
| メリット | デメリット |
|---|---|
| 管理負荷がほぼゼロになり、常に最新状態を維持できる | 月額費用や長期契約が発生する(外部依存) |
| 複数の配信サービスを利用する大規模環境で安定性が高い | 内部処理が見えにくく、ブラックボックス化する場合がある |
SPFホスティングを利用すると、自社でIPを逐一追う必要がなくなりますが、サービス停止時や価格改定のリスクも考慮する必要があります。
SPFのフラット化 とホスティングの整理
| 項目 | SPFフラット化 | SPFホスティング |
|---|---|---|
| 本質 | 技術的操作(参照をIPへ置換) | 運用モデル(管理を外部に委託) |
| 管理主体 | 自社(メール担当者・運用チーム) | サービス提供者 |
| 更新 | IP変更ごとに手動または自動ツールで対応 | サービス側が自動で追従・更新 |
| DNS記述 | 長大なIP列(TXTレコードが長くなる) | 自社側は1行のincludeのみ |
フラット化は「自分で修理する」、ホスティングは「専門業者に定期保守を任せる」という違いです。どちらを採用するかは運用方針・規模・予算次第です。
主要サービスの比較
参考として、代表的なサービスの特徴と、導入時の検討ポイントをまとめます。
| サービス名 | 特徴・強み | 補足説明 |
|---|---|---|
| AutoSPF | SPF専用の自動フラット化/更新に特化。フラット化の自動運用をシンプルに導入できる。 | SPF運用だけに注力したい場合にコストパフォーマンスが良い。 |
| PowerDMARC | DMARC/DKIM/SPFを含む総合認証プラットフォーム。統合的なメール認証運用が可能。 | DMARCレポートの集約や分析まで一元管理したい組織に向く。総合運用を検討する場合に有力。 |
| ベアーメール SPFホスティング(国内) | 日本語サポートが充実。SPFホスティングを含むメール健全性支援。 | 国内運用や日本語での手厚いサポートを重視する企業に適する。料金は機能やドメイン数で変動する。 |
記載の価格は当社調べの参考値です。実際のプランや料金、サポート内容はサービス提供事業者に確認してください。
最後に
SPFの「10回制限」は無視できない課題です。手軽に問題を回避したい場合はフラット化を短期施策として検討できますが、長期運用や複数サービスを使う場合はホスティングによる自動運用が現実的で効果的です。
選定にあたっては、次の点などをチェックしてください。
- 使用しているメールサービスの数と更新頻度
- 想定する月額コスト
- DMARC/DKIMとの統合要否
メールの到達率は企業のブランドに直結します。まずは自社ドメインのSPFレコードを確認し、ルックアップ回数や現状のリスクを把握するところから始めましょう。