SPFのベストプラクティス：SPFレコードのフラット化を回避する

• 2023年2月24日

最終更新日： 2025年2月4日
ドメイン概要にSPFルックアップ回数を表示する機能を追加しました。これにより、他のツールから情報を取得する必要がなくなりました。この機能強化により、時間の節約、SPFルックアップ回数の可視性の向上、そしてSPFのベストプラクティスの推進が可能となり、これらはすべて、DMARCの導入加速と運用効率の向上に不可欠な要素です。

なぜSPFのフラット化が重要なのでしょうか？

SPFではDNSルックアップが10回までと制限されています。この制限を超えた後にルックアップを必要とするメカニズム（エントリ）は評価されず、認証に失敗します。場合によっては、この10回のDNSルックアップ制限を回避するために、SPFフラットニングツールを利用するケースもあります。

レコードに新しい仕組みを追加する場合、新たなDNSルックアップが必要になります。代行してメールを送信するサービスやサードパーティが増えるほど、レコードは複雑化し、肥大化する恐れがあります。SPFレコードのフラット化は手軽な解決策となり得ますが、最も安全な方法とは言えません。

SPFのフラットニング機能はどのように機能するのでしょうか？

SPFのフラット化では、ホスト名がIPアドレスに変換されます。これにより、DNSルックアップの集計対象から外れます。その後、ホスト名の代わりにIPアドレスを使用してSPFレコードを作成します。

dmarcianは、DNSルックアップの制限を回避するための実験として、SPFフラットニングを開発しました。SPFメール認証規格であるIETFのRFC 7208では、「DNSへの過度な負荷を避ける」ため、ルックアップに制限が設けられています。規格の詳細については、こちらをご覧ください。

SPFのフラット化は、最初から避けるべきです。多くの人が、SPFの文脈において実際には認証を行っていないインターネット上の多くの領域を許可してしまうようなSPFレコードを設定しています。その結果、攻撃者が誤って許可されたインターネット領域にアクセスし、そのドメインからメールを送信できるリスクが高まります。その代わりに、全体的な認証の状況を把握し、SPFレコードにどのようなメカニズムを反映させるべきかを判断するための出発点として、DMARCデータを収集することが最善です。
ティム・ドレーゲン氏（dmarcianのCTOであり、DMARC仕様の共著者）。

「DNS ルックアップが多すぎます」というエラーの解決方法

不要なSPFレコードのエントリは削除し（追加はしないでください）。以下にいくつかの例を挙げます：
- SPFアラインメントの設定ができないベンダーのレコードを削除してください。具体的には、SPFドメインがMAIL FROM（別名：リターンパス）と一致し、かつ貴社のドメインを使用している場合です。dmarcianアカウントをお持ちの場合は、Detail Viewerに表示される送信元の中で、「SPF非対応」と表示され、SPF合格率が0%となっているもののSPFレコードを削除してください。 dmarcianアカウントをお持ちでない場合は、無料のリソースであるdmarc.ioを参照して、ベンダーのSPF対応状況を確認できます。
- 「a」および「mx」のエントリは避けてください。これらのメカニズムは多くの場合役に立たず、SPFレコードに含めるべきではありません。
- SPFの整合設定ができないベンダーのレコードを削除します。
- 重複するSPFメカニズムを削除します。
- トップレベルドメインの「includes」を削除してください。多くのメールサービスプロバイダーは、SPF認証の評価対象となる「MAIL FROM」にサブドメインを使用しています。
- 不要なトップレベルドメインを保有することは、事実上、何千ものIPアドレスがそのドメインを名乗って送信することを許可することになる。
- SPFを使用してもDMARCの検証に合格できない場合は、DKIMを設定してください。

ドメインの継続的なメンテナンスの一環として、SPFレコードを定期的に確認し、使用されていないSPFエントリ（例：使用されなくなった送信元、または導入後にサブドメインごとのSPF管理体制が確立されたものなど）を削除してください。

SPF認証のためにベンダーからのトラフィックをサブドメインに移行します（詳細は後述）。サブドメインの分割により、特定のメールストリーム専用の新しいドメインが作成され、そのドメインには独自の10回のDNSルックアップが割り当てられます。