SPFの考え方が形作られた1997年当時、電子メールの世界は大きく異なっていました。2000年頃に初めて公に言及された時はほとんど注目されませんでしたが、それから早20年が経ち、今ではDKIMやDMARCと並んで、最も普及しているメール認証の1つとなっています。当時、記録の正確性を保証することは、現在とははるかに異なる課題でした。
SPFレコードの精度は、お客様のメールエコシステムの理解と可視性に依存します。多くの組織では、このエコシステムは直接管理されたインフラストラクチャで構成され、お客様のドメインに代わってメールを送信するホスティングサービスのジャングルの中に所有または存在しています。近年、このジャングルは拡大する一方であり、SPFの実装やDNS自体が課すSPFの限界を押し上げ、時には破っています。このような限界に対処することは、組織のドメイン管理プロセスに組み込まれなければならない現実です。
この記事では、当社のデプロイメント・チームが、電子メール認証の現代世界におけるSPFのデプロイメントに関する一般的な課題を中心にお話しします。
あなたが1つのドメインを所有し、オンプレム/エクスチェンジのハイブリッドオンライン環境と、そのドメインに代わってメールを送信するホスティングサービスを12個ほど所有しているとします。まず考えられるのは、ドメインのSPFレコードに関連するエントリをすべて追加して、その日は終わりにするということだ。結局のところ、彼らはあなたのドメインを使ってメールを送信しているのですから、プロセスは簡単なはずです。実際には、このプロセスには、これらのサービスがどのようにお客様の代わりにメールを送信しているかを評価し、どのSPFの問題が発生しているかを特定し、それぞれの解決策を理解して導入計画を立てることが含まれます。
遭遇する問題は、一般的に以下のいずれかに分類されます：10個のDNSルックアップ制限に違反しているか、レコードが大きすぎて1個のTXTレコードに収まらないかです。この場合、どうすればいいのでしょうか？解決策はほとんどなく、完璧なものはありません。しかし、解決策を見つけることは必要ですが、メールエコシステムの管理知識を通じて問題を理解することが最も重要です。そうすることで、組織のドメイン管理の実践のための運用上の意思決定をより柔軟に行うことができるようになります。
SPF 10のDNSルックアップ制限に対処するために最も頻繁に使用される一般的な解決策は、以下のとおりです。
- 不必要なDNSの仕組みを避ける
- 「a」と「mx」のエントリーを避ける
- 専用メールストリーム・サブドメイン
- ダイナミックSPFソリューション
それぞれの長所と短所を見てみよう。
不要なDNSの仕組みを避ける
これは当然のアドバイスのように思えるかもしれないが、インターネット上では、組織が特定のベンダーまたはサービスをいつSPFレコードに追加すべきか、または追加すべきかどうかについて、多くの悪いガイダンスが存在する。ベリファイアは、RFC 5321のMail Fromメールアドレス、またはMail FromがNULLの場合にSMTP会話中にクライアントが発行したHELO/EHLO IDから抽出したドメインに対してSPFレコードチェックを行うことを覚えておこう。このメールアドレス（return-path、envelope from、bouncebackアドレスとしても知られる）は、RFC 5322のFrom:メールアドレスヘッダとは異なる。Friendly Fromと呼ばれることもあります。これは、メールクライアントで一般的に表示されるFromメールアドレスです。この2つのアドレスは一致しないことがありますが、一致する必要はありません。
新しいサービスやベンダーのオンボーディングを行う場合、彼らがどのようにあなたのドメインの代わりにメールを送信するのかを理解することが重要です。より正確には、どのドメインをリターンパスとして使用するのか。もしその答えがあなたのドメインのどれでもないのであれば、認証の観点からSPFレコードに追加する理由はありません。既存のサービスがすでにどのようにメールを送信しているのかを理解したり確認したりするのは難しいかもしれません。DMARCのフィードバックレポートには、受信者のSPFチェックの一部としてどのようなドメインの身元が確認されたかというメタデータが含まれているため、このような場合に役立ちます。レコードをクリーンに保つ!
「a」と「mx」のエントリーを避ける
SPFレコードの最も一般的な間違いの一つは、「a」と「mx」が記載されていることです。これらは完全に有効であり、正しい意味で役に立つこともあるが、役に立たないことの方が多いので、記載すべきではない。a」の仕組みは、メッセージのFromヘッダでドメインのIPアドレスにそのドメインのメッセージ送信を許可することを示す。このIPアドレスはドメインのWebホストのIPアドレスであるため、通常は間違っている。可能であれば、そのエントリを調査して削除すべきである。
「mx」メカニズムは、ドメインのMXレコードのIPアドレスが、メッセージのFromヘッダーでドメインのメッセージ送信を許可する必要があることを示す。MXホストはイングレストラフィックに使用され、アウトバウンドは同じ環境を経由しないため、これは正しくない可能性がある。MXホストはイングレットトラフィックに使用され、アウトバウンドはその同じ環境を経由しないため、これは正しくない可能性がある。多くの場合、これは完全に正当であるが、M365、Googleなどのほとんどの大規模なホスト環境では正しくない。SPFレコードがすでにこれらのようなプロバイダーからのトラフィックを許可している場合、”mx “の追加は正しくありません。
専用メールストリーム・サブドメイン
ここで言っているのは、1つまたは少数のサービスプロバイダーが使用するサブドメインを作成することです。例えば、販売関連のサードパーティセンダーのためのsales.example.orgのようなものです。DMARCを導入する際、DMARCをサポートしていないベンダーがいる場合、このようなニーズは避けられないことがあります。
ベリファイアがSPFレコードのチェックを行う場合、RFC 5321のMail Fromから抽出されたドメインのみを参照する。つまり、info@sales.example.org を Mail From アドレスとしてメールを送信した場合、受信者はその親ではなく、sales.example.org の SPF レコードを DNS で厳密に検索します。このため、SPFレコードを作成するドメインはまっさらな状態になります。このようにメールのストリームを隔離することで、サブドメインのみに存在するメールアカウントの悪用による影響を軽減することもできます。ひいては、プライマリコーポレートドメインのアイデンティティを使用するすべてのサービスに影響を与えるのではなく、悪用によるドメインレピュテーションへの影響をサブドメインに隔離することもできます。
このサブドメインの範囲によっては、追加のライセンスや Web リソースなどが必要かどうかを確認するなど、配備に関連する追加コストが発生する場合があります。必要性をスコープすることで、展開に必要なリソースと関連コストが決定されます。さらに、ドメイン管理チームの現在の管理負荷が増加します。
ダイナミックSPFソリューション
動的SPFレコードのアイデアには、レコードを動的に平坦化し、その結果をデータソースに基づいて公開するといったものがある。また、マクロを使用することで、より複雑な管理を意味することもある。これらのソリューションの実装はさまざまだが、一般的にはすべて同じ利点がある。主に、一種の自動化を可能にし、より大きな柔軟性と拡張性を提供する。目標は、管理時間を節約する一方で、あなたのドメインに代わって送信している送信者の数を気にする必要がなくなることです。
これらは非常に強力なソリューションになりうるが、万能ではない。社内でカスタムソリューションを開発するには、かなりの時間を要する。より現実的には、組織はこの機能のためにサービス・プロバイダーを求めるだろう。また、単一ドメインではないにせよ、少数のドメインを使用するSPFファーストの展開へと考え方をシフトさせる。多くのサービス・プロバイダーは、カスタム・リターン・パス、つまりサービス・プロバイダーのドメインではなく自社のドメインを使用するリターン・パスをサポートしていないため、このようなソリューションは役に立たず、DMARCを展開する際には、認証のために特にDKIMに依存することになる。また、特定の実装では、すべてのメールストリームに対して単一障害点となるDNSへの依存が強くなる可能性があります。
結局のところ、どのソリューションが問題解決に最適かを見極めるには、しっかりとした調査に勝るものはない。いずれを採用するにせよ、強力なSPF管理プロセスは、長期的なメール認証導入の成功を確実にするためのベストプラクティスです。
私たちがお手伝いします
Brandkeeperでは、メールセキュリティの専門家チームによるDMARCの導入から運用サポート及びコンサルテーション行っています。一旦はDMARCの導入をやってみたが運用を断念したお客様、または、導入時点でいくつものハードルであきらめた企業様のサポートも行っています。
お気軽にご連絡ください
