実験の結論：SPFフラットニング

• 2023年3月2日

「SPFフラットニング（SPF Flattening）」は、dmarcianが「SPF Surveyor」の初期リリースに際して開発した技術です。長年にわたり、この機能には「実験的（experimental）」というフラグが立てられてきました。本日、私たちはこの実験を終了し、そこから得られた知見を皆様に共有いたします。

Sender Policy Framework (SPF) の概要

メール配信者は、インターネットを通じてメールを送信する際、自分自身とその配信基盤を識別するためにSPFを利用します。SPFは、「Joe Job攻撃（ジョー・ジョブ攻撃）」に対抗するため、2000年頃にメール配信者たちによって考案されました。当時、スパマー（迷惑メール送信者）は、正規の配信者を装ってスパムメールを送信し、罪のない配信者を陥れていました。当時は配信者やその配信基盤を簡単に特定する手段がなかったため、正規の配信者が「スパムを送信している」と濡れ衣を着せられていたのです。

そこで配信者は、自身の配信基盤を記述するためにSPFレコードを公開するようになりました。SPFレコードは、DNS（ドメイン名システム）内に登録される、特定の形式で構成されたテキスト文字列です。受信側のメールサーバーは、メールを受信すると、配信者のメールアドレスのドメイン（リバースパス、バウンスアドレス、エンベロープFrom、MAIL FROMなどとも呼ばれます）を確認し、そのドメインのSPFレコードを取得します。

SPFレコードに記述されている配信基盤と、実際にメールを届けようとしている配信基盤が一致した場合、受信者はメール配信者とそのインフラを正しく特定できたことになります。

現代のSPFが直面する課題

SPFレコードのメンテナンスには、主に3つの大きな課題が存在します。

SPFの歴史が非常に長いこと。
経験豊富なITエンジニアでさえ、SPFの仕組みを誤解していることが多いこと。
DMARCと連携させるためには、エンドユーザーが目にする「Fromヘッダー」のドメインと、メール配信者のドメインを関連付ける必要があること。

SPFが登場してから20年以上が経過しました。長年にわたり、人々は自分たちのメール送信インフラをなんとかリストアップしようと努めてきました。しかし、そのサーバーが現在も使われているかどうかを判断する簡単な方法がなかったため、サーバーはSPFレコードに追加される一方で、削除されることはほとんどありませんでした。

さらに悪いことに、SPFの仕組みは広く誤解されています。本来「メールを運用する人（オペレーター）」と「メールを書いて送る人」は別物ですが、SPFがチェックするのは「オペレーターのドメイン（リターンパス）」ではなく、メールの「Fromドメイン」であるという誤解が蔓延しています。

この誤解が広まっているために、実際にはメール送信に使われていないインフラまでSPFレコードに書き込まれ、肥大化を招いています。最悪のケースでは、メール配信ベンダーがクライアントのドメインを自らの識別子として利用することがあります。これにより、クライアントはメール運用のためにベンダーに費用を払っているにもかかわらず、自らが「メール運用者」としての役割を担わされる形になってしまうのです。

DMARCが登場する前は、メール運用者は自らの運用実態を示すリターンパスを使って自分自身を識別させていました。メールアプリ上でユーザーが目にする「Fromドメイン」と、メール運用者を関連付ける必要はなかったのです。

しかし、SPFはDMARCコンプライアンスを達成するための2つの技術（もう一つはDKIM）のうちの一つです。SPFを用いてDMARCに対応させるには、メール運用者のリターンパスが、メールの「Fromヘッダー」に表示されるドメイン（またはそのサブドメイン）と一致している必要があります。DMARCとの相互運用を実現するために、あまりにも多くのベンダーがクライアントのルートドメインを使用して識別を行う結果となり、前述のようなSPFレコードのさらなる肥大化を引き起こしています。

「DNSルックアップ超過」という症状

SPF（Sender Policy Framework）の課題が積み重なると、レコードが不正確になったり、SPF固有の処理制限に達するほど不必要に長くなったりすることがあります。その結果、広範囲かつ制御不能な認証設定となってしまい、組織をリスクにさらす要因となります。

dmarcianの「SPF Surveyor」は、SPF固有の処理制限（一般に「DNSルックアップ超過」問題と呼ばれるもの）を指摘した最初の公開ツールでした。簡単に言えば、SPFの仕様は、受信側サーバーがSPFレコードを処理してメールを配信しようとする際に、過剰なリソースを消費させられないよう、受信サーバーを保護するように設計されているのです。

SPFレコードが「DNSルックアップ超過」問題に陥る原因には、以下のようなものが挙げられます。

古いエントリーを削除せずに、次々と新しい設定を追加している。
SPFの制限に達するまで、利用するインフラをトップレベルのSPFレコードに「include:」し続けるよう指示されている。
DMARCとの相互運用性を維持しようとするあまり、SPFレコードが極端に肥大化してしまう。

dmarcianでは、この「DNSルックアップ超過」エラーとして頻出する「巨大で扱いにくいSPFレコード」を、より大きな問題の一つの症状であると捉えています。その根本には、SPFの仕組みに対する誤解、メール送信委託先ベンダーに対する管理体制の不備、そして組織内におけるメールセグメンテーション（用途に応じた配信の切り分け）のベストプラクティスが欠如しているという実態があります。

SPFフラットニングの危険性

SPFフラットニングは、「DNSルックアップ回数の超過」というエラーの根本的な原因に対処することなく、その場しのぎの回避策を講じようとするものです。根本的な問題に目を向けずにエラーだけを消し去ることは、危険な状況を招く恐れがあります。組織のIT担当者は知らず知らずのうちに、組織のトップレベルドメインを使用してメールを送信するすべてのベンダーやメールオペレーターの挙動、およびインフラに対して責任を負うことになってしまいます。

レピュテーション（信頼性）の観点
受信側にとって、異なる種類のメールを判別することが困難になります。例えば、請求書とニュースレターで同じドメインを共有している場合、受信側からは同じドメインから送られてくるメールに見えるため、スパムのようなニュースレターのせいで、重要な請求書までスパムフォルダに振り分けられてしまう可能性があります。
運用の観点
ベンダーは、組織に代わって送信しているメールを効果的に管理するために必要なシグナル（通知）を受け取ることができなくなります。例えば、ベンダーが無効な宛先にメールを送りバウンス（配送エラー）が発生した場合、その通知はベンダーではなく、組織のIT担当者に届いてしまいます。原則として、IT担当者がこれらのシグナルをベンダーに転送することはないため、ベンダーは状況を把握できないまま「盲目的な運用」を続けることになり、結果として組織のレピュテーションに徐々に悪影響を及ぼします。
セキュリティの観点
肥大化したSPFレコードによる「過剰な権限付与」は、言い換えれば「SPFレコード内の不要なエントリが攻撃対象領域（アタックサーフェス）を生み出している」ということです。もし攻撃者がSPFレコードに記載されているインフラの一部に侵入、あるいは単に借用することができれば、その攻撃者はDMARCに適合したメールを送信できてしまいます。これにより、既存の制御策を事実上回避し、組織のレピュテーションを悪用して詐欺メールを配信することが可能になります。

サイバー攻撃においてメールが主導的な役割を果たしていることを考えると、根本的な問題に対処せず、SPFのエラーメッセージという表面的な症状だけを回避することは、情報セキュリティおよびリスク管理の専門家としての使命に反します。

dmarcianは、SPFフラットニングを製品やサービスとして提供したいという衝動を抑えてきました。その主な理由は、組織がベストプラクティスを採用し、ベンダーやメールストリームを適切に分離（セグメント化）すれば、SPFフラットニングの必要性はなくなるからです。
この方向に進む組織は、より強力な統制、攻撃対象領域の縮小、運用効率の向上を手にすることができます。そして、ベンダーを区分けし、潜在的なサイバーインシデントの波及効果を限定的に抑えることで、レピュテーションの回復力（レジリエンス）を高めることができるのです。

SPFフラット化実験の終了

dmarcianの調査によると、一部のITチームは、チケット対応や既存グループへのサポート以外の分野において、変革を推進する能力に制約を受けていることが判明しました。これらのチームには、ビジネスプロセスの改善や、セキュリティ・リスク管理上の課題への対応といった業務が正式な権限として認められていないため、dmarcian流のベストプラクティス（複数のグループにまたがる場合もある）の導入は、実現が困難な状況にあります。

これらのチームにとって、dmarcianは「SPF Flattening」を、組織がITチームが現在抱えている負荷や課題を軽減できるベストプラクティスを導入できるよう体制を整えるまでの、一時的な対策と見なしています。この「一時的な対策」という点は、こうした状況にあるITチームが、他のグループと連携してより実質的かつ持続可能な変更を展開するためには、SPFエラーが発生しない期間が必要であることを認識した上でのものです。

dmarcianがこうした状況において懸念しているのは、ITチームが一時的な対処法に留まり、根本的な問題（おそらく彼らの業務範囲外である）の解決に手を付けないままにしてしまう危険性だ。