Why Is SPF Flattening Relevant?
SPFには10回のDNSルックアップという制限がある。ルックアップ制限後にルックアップを必要とするメカニズム（エントリ）は評価されず、認証に失敗する。場合によっては、SPFフラット化ツールを使って10DNSルックアップ制限を回避することもある。レコードに新しいメカニズムを追加すると、新しいDNSルックアップが必要になる。あなたの代わりに送信するサービスやサードパーティが増えれば増えるほど、レコードは複雑になり、肥大化します。SPFレコードのフラット化は簡単な解決策ですが、最も安全な方法ではありません。
SPFフラットニングはどのように機能するのか？
SPF Flatteningでは、ホスト名をIPアドレスに変換する。そして、ホスト名の代わりにIPアドレスを使用してSPFレコードを作成します。
dmarcianは、DNSルックアップ制限を回避するための実験としてSPFフラット化を開発した。IETFのRFC7208（SPFメール認証標準）では、”DNSへの不当な負荷を避けるため “にルックアップを制限している。この規格の詳細については、こちらをご覧いただきたい。
ほとんどの人は、SPFの文脈で実際には認証を行っていないインターネットの多くを認証するSPFレコードを開始している。その結果、悪質な行為者が誤って認証されたインターネットの一部にアクセスし、そのドメインからメールを送信できるリスク面が増大する。そうではなく、全体的な認証コンテキストを理解し、SPFレコードでどのようなメカニズムを表現すべきかを決定するための出発点として、DMARCデータを収集するのが最善である。
dmarcianのCTOであり、DMARC仕様の共著者であるティム・ドレイゲン。
「DNSルックアップが多すぎる」問題の解決方法
- 必要のないSPFレコード・エントリーは破棄する（追加しない）。以下にいくつかの例を挙げる。
- SPFドメインがMAIL FROM、別名return-pathと一致し、お客様のドメインを使用している、SPFアライメントを設定できないベンダーのレコードを削除します。dmarcianアカウントをお持ちの場合は、詳細ビューアに表示される「SPF不能」でSPF通過率が0%であるソースのSPFレコードを削除します。dmarcianアカウントをお持ちでない場合は、当社の無料リソースdmarc.ioを参照して、ベンダーのSPF能力を調べることができます。
- a」と「mx」のエントリーは避けましょう：これらの仕組みは役に立たないことが多く、おそらくSPFレコードに含めるべきではありません。
- SPFアライメントを設定できないベンダーのレコードは削除する。
- 重複するSPFメカニズムを削除する。
- トップレベルドメインは破棄する。多くのメールサービスプロバイダは、SPF認証で評価されるMAIL FROMにサブドメインを使用しています。
- 不要なトップレベルドメインを持つことは、そのドメインの代理として送信する何千ものIPアドレスを効果的に承認することになります。
- メールがSPFでDMARCを通過できない場合は、DKIMを設定します。
- ドメインメンテナンスの一環として定期的にSPFレコードを監査し、使用していないSPFエントリ（例えば、もはや使用されていない送信者や、オンボーディング以降にサブドメインのSPF管理方法を確立したもの）を削除します。
- SPF認証のために、ベンダーのトラフィックをサブドメインに移動させる（詳細は後述）。サブドメインのセグメンテーションにより、特定のメールストリーム専用の新しいドメインを作成し、独自の10個のDNSルックアップを行う。
SPFベストプラクティス
組織が成長するにつれ、メールソースは散発的かつ有機的に蓄積される可能性がある。このため、SPFレコードに仕組みが追加される一方で、使われていない仕組みが削除可能かどうか調査されないことがよくあります。
セキュリティ、運用、配信の観点から、dmarcianはSPF管理のためのセグメンテーション戦略を提唱しています。可能な限り、異なるメールストリーム（トラフィックの種類）を分離することをお勧めします。バルクマーケティング、トランザクション、課金、特定のサードパーティベンダー、運用エンティティなど、タイプごとにストリームを分けることです。
これを実現するには、メールトラフィックをストリーム専用のサブドメインに分けるのもベストプラクティスです。そうすることで、各ストリームの可視性が高まり、特定のシステムやベンダーの使用を切り分けることができます。SPF認証が必要な場合は、単一ドメインの負担を軽減し、SPFの肥大化を避けることで、セキュリティと運用の簡素化を実現します。各セグメントが独自のレピュテーションを成長させることが重要であり、それには一貫したトラフィック量が必要である。サブドメインの使用量にばらつきや経過があると、レピュテーションや配信性に影響を与える可能性があります。
アッシャー・モリン、dmarcian配備担当ディレクター
サブドメイン・セグメンテーション戦略によってDNSルックアップを減らすことに加えて、SPFのベスト・プラクティスを以下に挙げる。
- ptrの使用は避けること。ptrの仕組みは非推奨であり、クエリー時にDNSに大きな負担をかける可能性がある。
- 非送信ドメインは、制限的な “deny all “SPFレコードで保護する：「v=spf1 -all”。悪質な業者は、悪用するために使われていないドメインを積極的に探します。
- v=spf1-all”。”+all “または “all “は、SPFレコードで明示的に拒否していないすべてのIPを許可してしまうので避けること。また、”?all “は中立的なものであり、強制の優先順位を示すものではないので使わないこと。中立的な判定はメールのスパムスコアを上げ、受信者のスパム判定しきい値へ押し上げる可能性があります。
- all”(softfail)または”-all”(fail)を使ってください。ほとんどの受信者はこれらのディレクティブを同様に扱いますが、DMARCポリシーに関係なく、”-all “を使用するとメールを拒否する可能性が高くなる受信者もいます。DMARCポリシーが “none “と “quarantine “の場合は”~all “を使用し、”reject “のポリシーに移行したら”-all “を使用します。
- SPFの継続的な監視と管理のためのプロセスを組織内に構築する。この定期的なレビューでは、必要に応じてサードパーティベンダーのオンボード/オフボードも考慮する。
SPFレコードの管理方法についてご質問がある場合は、私たちにご連絡ください。また、こちらで他のSPF関連の記事やガイダンスを読むことができますし、私たちのSPFビデオもチェックしてみてください。
メールセキュリティの専門家チームと、ドメインセキュリティを通じてメールとインターネットをより信頼できるものにするという使命を持つdmarcianは、組織のドメインカタログを評価し、長期にわたってDMARCを実装・管理するお手伝いをします。
私たちがお手伝いします
Brandkeeperでは、メールセキュリティの専門家チームによるDMARCの導入から運用サポート及びコンサルテーション行っています。一旦はDMARCの導入をやってみたが運用を断念したお客様、または、導入時点でいくつものハードルであきらめた企業様のサポートも行っています。
お気軽にご連絡ください
