SPF管理における課題

SPFの概念が形になり始めた1997年当時、電子メールの世界は今とは大きく異なっていました。2000年頃に初めて公に言及された際、ほとんど注目されることはありませんでしたが、それから20年が経った現在、SPFはDKIMやDMARCと並び、最も広く普及している電子メール認証方式の一つとなっています。当時、レコードの正確性を確保することは、現在とは比べものにならないほど困難な課題でした。

SPFレコードの正確性は、自社のメール環境に対する理解と可視性に左右されます。 多くの組織にとって、このエコシステムは、自社が所有またはオンプレミスで直接管理するインフラと、ドメインに代わってメールを送信する数多くのホスティングサービスから構成されています。近年、この複雑な環境はさらに拡大し、SPFの実装自体やDNSが課す制限を急速に押し広げ、時にはその限界を突破することさえあります。こうした制限との折り合いをつけることは、組織のドメイン管理プロセスにおいて対処し、組み込むべき現実的な課題です。

この記事では、当社のデプロイメントチームが、現代のメール認証環境におけるSPFの導入に関連する一般的な課題について主に解説します。

ひとまず、あなたが1つのドメインを所有しており、オンプレミスとExchange Onlineのハイブリッド環境に加え、そのドメインを代表してメールを送信するホスティングサービスが十数個あると仮定しましょう。最初に思いつくのは、関連するエントリをすべてドメインのSPFレコードに追加して、それで済ませることかもしれません。何しろ、それらはあなたのドメインを使ってメールを送信しているのですから、手順は簡単であるはずだからです。 しかし実際には、このプロセスには、各サービスがどのようにあなたの代わりにメールを送信しているかを評価し、どのようなSPFチャレンジが発生しているかを特定し、それぞれの解決策を理解した上で、導入計画を策定することが含まれるべきです。

発生する問題は、一般的に以下のいずれかに該当します。DNSルックアップの制限である10回を超えているか、レコードが大きすぎて1つのTXTレコードに収まらないかのいずれかです。このうち、前者が圧倒的に多く見られます。 では、どうすればよいのでしょうか？解決策はいくつかありますが、完璧なものはありません。しかし、解決策を見つけることは必要である一方で、自社のメール環境に関する管理知識を通じて問題を理解することの重要性は極めて高いものです。これにより、組織のドメイン管理実務における運用上の意思決定において、より柔軟に対応できるようになります。

SPF 10のDNSルックアップ制限に対処するために最もよく用いられる一般的な解決策は、以下の通りです：

• 不要なDNSメカニズムを避ける
• 「a」および「mx」レコードの回避
• 専用メール用サブドメイン
• 動的なSPFソリューション

それぞれのメリットとデメリットを見てみましょう。

不要なDNSメカニズムを避ける

これは当たり前のアドバイスに思えるかもしれませんが、組織が特定のベンダーやサービスをSPFレコードに追加すべきかどうか、またそのタイミングについて、インターネット上には誤った情報が数多く出回っています。検証ツールは、RFC 5321の「Mail From」メールアドレスから抽出されたドメイン、あるいは「Mail From」がnullの場合にSMTP通信中にクライアントから発行されたHELO/EHLO識別情報に対して、SPFレコードのチェックを行うことを覚えておきましょう。 このメールアドレス（リターンパス、エンベロープ・フロム、バウンスバック・アドレスとも呼ばれます）は、RFC 5322のFrom:メールアドレスヘッダーとは異なります。これは「フレンドリー・フロム」と呼ばれることもよくあります。これは、メールクライアントに一般的に表示される送信元メールアドレスです。これら2つのアドレスが一致しない場合もあり、必ずしも一致する必要はありません。

新しいサービスやベンダーを導入する際は、彼らが貴社のドメインを名乗ってどのようにメールを送信するのかを理解することが重要です。 具体的には、返信先アドレス（Return-Path）としてどのドメインを使用するのでしょうか？もしその答えが自社のドメインではない場合、認証の観点からは、SPFレコードにそれらを追加する理由はありません。既存のサービスがどのようにメールを送信しているかを把握するのは難しい場合がありますが、DMARCのフィードバックレポートには、受信側のSPFチェックの一環としてどのドメインIDが検証されたかというメタデータが含まれているため、ここでDMARCが役立ちます。レコードをクリーンに保ちましょう！

「a」および「mx」レコードの回避

SPFレコードに関する最もよくある間違いの一つは、「a」と「mx」を記載してしまうことです。これらは完全に有効であり、正しく使用すれば役立つこともありますが、多くの場合、無意味であり、記載すべきではありません。 「a」レコードは、そのドメインのIPアドレスが、メッセージのFromヘッダーにそのドメイン名を記載してメッセージを送信することを許可することを示しています。通常、この設定は誤りです。なぜなら、そのIPアドレスはドメインのウェブホストのIPアドレスであることが多いからです。これは正当な用途となり得ますが、一般的な設定ではありません。可能な限り、このエントリを調査し、削除すべきです。

「mx」メカニズムは、ドメインのMXレコードに対応するIPアドレスが、メッセージのFromヘッダーにそのドメイン名を記載してメッセージを送信することを許可すべきであることを示しています。しかし、MXホストは着信トラフィックに使用されるものであり、送信トラフィックは同じ環境を経由しないため、これは誤りとなる可能性があります。 多くの場合、これは完全に正当な設定ですが、M365やGoogleなどの大規模なホスティング環境では不適切です。SPFレコードに、こうしたプロバイダーからのトラフィックを許可する設定がすでに含まれている場合、「mx」を追加することは不適切です。

専用メールストリームサブドメイン

ここで言及しているのは、1社または数社のサービスプロバイダーが使用するサブドメインを作成することです。例えば、販売関連のすべてのサードパーティ送信元に対して「sales.example.org」のようなドメインを設定することを想定してください。DMARCを導入する際、DMARCに対応していないベンダーが存在する場合があり、そのようなベンダーを独自のサブドメインに隔離し、独自のDMARCポリシーを適用する必要があるため、この措置は避けられない場合があります。

検証者がSPFレコードのチェックを行う際、RFC 5321の「Mail From」から抽出されたドメインのみを確認します。つまり、[email protected]を「Mail From」アドレスとしてメールが送信された場合、受信側はDNS内でsales.example.orgのSPFレコードのみを厳密に確認し、その親ドメインのレコードは一切確認しません。 これにより、SPFレコードを作成するための全く新しいドメイン、つまり白紙の状態が得られます。このようにメールの送信元を分離することで、サブドメイン上にのみ存在するメールアカウントが悪用された場合の悪影響を軽減することも可能です。ひいては、メインの企業ドメインIDを使用するすべてのサービスに影響が及ぶのではなく、サブドメインでの悪用によるドメインの評判への影響を隔離するのにも役立ちます。

このサブドメインの範囲によっては、追加のライセンスやWebリソースが必要かどうかを特定するなど、導入に伴う追加費用が発生する可能性があります。要件の範囲を明確にすることで、導入に必要なリソースとそれに伴う費用が確定します。さらに、これにより、ドメイン管理チームの現在の管理負担が増加することになります。

ダイナミックSPFソリューションズ

動的なSPFレコードという概念には、レコードを動的にフラット化してから、データソースに基づいてその結果を公開するといった方法など、いくつかの形態が考えられます。また、マクロを活用してより複雑な管理を行うことを指す場合もあります。これらのソリューションの実装方法は様々ですが、一般的にいずれも同様のメリットをもたらします。主な利点として、ある種の自動化が可能になり、柔軟性と拡張性が向上することが挙げられます。 その目的は、ドメインを代表して送信している送信者の数を気にすることなく、管理にかかる時間を削減することです。

これらは非常に強力な解決策となり得ますが、万能薬というわけではありません。社内で独自のソリューションを構築する場合、多大な開発時間を要することになります。現実的には、組織はこの機能を提供するサービスプロバイダーを探すことになるでしょうが、その費用は高額になる可能性があります。また、これにより、ドメインを1つしか使用しないか、あるいはごく少数しか使用しない「SPFファースト」の展開という考え方へとシフトすることになります。 多くのサービスプロバイダーは、自社ドメインではなく顧客のドメインを使用するカスタムリターンパスをサポートしていないため、こうしたソリューションは役に立たず、DMARCを導入する際には認証をDKIMに依存することになります。特定の実装では、すべてのメールストリームにおいて単一障害点となる、DNSへの依存度が高まる可能性もあります。

結局のところ、問題を解決するのに最適なソリューションを見極めるには、綿密な調査に勝るものはありません。どの方法を採用するにせよ、長期的な電子メール認証の導入を成功させるためには、堅固なSPF管理プロセスを確立することがベストプラクティスです。

ご質問がございましたら、当社のウェブサイトにアクセスしてチャットでお問い合わせください。まだお済みでない方は、こちらから無料トライアルにお申し込みいただき、メールドメインのセキュリティ強化をお手伝いさせてください。

私たちがお手伝いします
dmarcianは、メールセキュリティの専門家チームを擁し、「ドメインセキュリティを通じてメールとインターネットの信頼性を高める」ことを使命としています。私たちは、組織が保有するドメイン群の現状評価から、DMARCの導入、そして長期的な運用管理に至るまで、手厚くサポートいたします。

---

この会話を続けたいですか？dmarcianフォーラムへどうぞ。