※ この記事は、Office 365 Message Attribution の抄訳です。
Exchange におけるメッセージのトランスポートとルーティングは、理解するのが少し難しい場合があります。もちろん、メールボックスがすべて Office 365 でホストされている場合は、心配する必要はありません。しかし多くのお客様にとって、Exchange ハイブリッド構成や Office 365 以外のメール システムとの共存の場合、依然として懸念事項として挙げられます。もしお客様組織におけるメールのルーティングが Office 365 のみで完結しない場合、Office 365 がメッセージの帰属をどのように考えているのかを少し知っておく必要があります。
メッセージの帰属とその必要性
Office 365 がメッセージをどのように特定の組織 (テナント) に関連付けるのかは、頭を悩ませることの 1 つです。Office 365 は完全にマルチ テナントの環境です。つまり、事実上すべてのインフラストラクチャを他のテナントと共有します。IP アドレス、証明書、サーバーなどの様々なコンポーネントが共有されます。
メッセージが Office 365 に到着したとき、最初に行う必要があることの 1 つは、メッセージがどの組織に属しているかを把握することです。そのためには受信者を確認すればよくて、単純な話のように聞こえるかもしれません。しかし実際にはハイブリッドや複雑なルーティング シナリオがあるため、もっと複雑です。
このブログ記事では、Office 365 のお客様である contoso.com から、別の Office 365 のお客様である tailspintoys.com へ送信されるメッセージについて見ていきます。 両方のお客様がハイブリッド構成の可能性があり、そのため contoso.com の送信者のメールボックスはオンプレミスでホストされている可能性があります。
コネクタの設定を基に、Office 365 はメッセージがどの組織に属するかを素早く判断する必要があります。どちらの組織も、メッセージに対して適用したいルールがあるかもしれません。またどちらの組織も、テナントを通過するメッセージを監視したいと思うでしょう。したがって、Office 365 はメッセージが現在どのテナントを通過しているのかを区別できる必要があります。例に戻ると、メッセージが Office 365 に届くたびに、メッセージが tailspintoys.com が受信するものなのか、contoso.com から発信されるのかを判断する必要があります。それにより、実行するルール、適用するコネクタ、およびメッセージ追跡のデータをどのお客様に提供するのかを決定することができるようになります。
ちなみに、構成は次のようになる可能性もあります。
以下のような場合もあります。
他にも多くの可能性があり、もっと複雑なものもあります。重要なのは、Office 365 は非常に柔軟であるということです。そのため、ルールを知っていれば問題を回避できます。サポートされているすべてのシナリオのリストについては、ベスト プラクティスに関するドキュメント を参照してください。
重要: 複雑な方法でメールをルーティングできても、必要なヘッダーとアクセス許可が必ずしも保持されているとは限りません。スパムやなりすまし、フィッシングに対する経験が乏しいお客様が複雑なルーティングを構成し、誤検知が発生することがよくあります。このブログでは、メールの帰属に関する内容のみに焦点を当てています。正しく帰属が判定されても、セキュリティに関しては別の問題です。
仕組みを紹介する前に、よくある質問に回答したいと思います。
FAQ #1 - DNS を使用して帰属を判断できないのはなぜですか？
Office 365 の申し込みを行って onmicrosoft.com ドメインを入手すると、テナントのメインとなる地域も選択されます。次に、Office 365 は onmicrosoft.com (および確認されたその他のドメイン) に一意の DNS エントリを割り当てます。これは次のことを意味します。
- 現状、すべてのドメインが同じ IP アドレスのセットに解決されます (したがって、技術的には、すべての MX レコードに単一の A レコードを使用できます)。
- SMTP 以外の他の Exchange のプロトコルも同様ですが、IP アドレスは同じ地域の他のすべての Office 365 のお客様と同じものが使用されます。一意の IP アドレスを割り当てるオプションはありません。1 つのテナントに約 3 つの IP アドレスが必要になりますが、最近では IPv4 アドレスを取得することが難しく、テナントごとに一意な IP アドレスを用意するには膨大な数の IP アドレスが必要になります。
- これらの DNS レコードと IP アドレスは、テナントから送信されるメールまたはテナントへ送信されるメールのすべてのメール フローに使用されます。
- SMTP のアプリケーション層には、HTTP の host ヘッダーと同等の概念がないため、Office 365 の SMTP エンドポイントは送信元がどの DNS エントリを使用して Office 365 の SMTP エンドポイントへ接続したのかを認識できません。
つまり、DNS を帰属の決定方法として使用することはできません。
FAQ #2 - Office 365 はオープン リレーですか？
Office 365 には、オンプレミス環境からのメッセージを中継できる機能があります。この機能を有効にするには、オンプレミス タイプの受信コネクタを作成します。このコネクターは、IP アドレスまたは証明書のいずれかによってリレーを許可できます。所有していないドメインやテナントに追加していないドメインからのメールを送信する場合は特に、証明書の利用が適しています。IP アドレスを所有していることを明確に証明することは非常に難しく、また証明書はより安全に送信元を適切に識別できます。2 つの Office 365 テナントが同じ IP アドレスまたは重複する範囲を指定すると、問題が発生し始めます。例えば、共有サービス用にオンプレミス タイプの受信コネクタが作成されている場合が該当します。
リレー機能はコネクタに指定された接続元 IP アドレスに対してのみ有効にすることができます。そのため、別の IP アドレスから「オープン リレーかどうか」をテストしても失敗します。
FAQ #3 - Office 365 テナント間のメールは常に MX レコードを使用しますか？
はい、ただし一部のシナリオを除きます。今回の例の場合、メッセージが contoso.com から発信されており、次に tailspintoys.com へ送信されるというときに、MX レコードが使用されます。しかしながら、注意が必要な例外がいくつかあります。
- contoso.com は、tailspintoys.com 用の送信コネクタを作成することにより、ルーティングを変更できます。このケースはもっとも分かりやすいものであり、Exchange サーバー (もしくは他の SMTP サーバー) のルーティングの仕組みと同じです。
- contoso.com のオンプレミスから Office 365 へメールが送信された際、メールが contoso.com の Office 365 ではなくこの時点で既に tailspintoys.com に受信されているように見える場合は、メールを tailspintoys.com の MX レコードにルーティングして戻すことはしません。これは、contoso.com に適切に構成された受信コネクタがない場合に発生する可能性があります。適切なコネクタがないと、メッセージは tailspintoys.com が受信しているものとして扱われます。
- 各テナントに onmicrosoft.com のアドレスが付与されます。これらのアドレスは、MX レコードがどこを示しているかに関係なく、常に Office 365 へ直接ルーティングするために使用できます (これは、ハイブリッド構成のオンプレミスとクラウド間のクロス プレミスのメール フローで使用されている仕組みです)。
tailspintoys.com が MX レコードを Office 365 に向けていない場合、(onmicrosoft.com ドメイン宛てのメールも含め、) 特定のエンドポイントから送信されたメッセージ以外を拒否するように Office 365 を構成できます。この構成を行うには、次のような受信コネクタを作成します。
1 | New-InboundConnector –Name "Block delivery unless via MX record" -ConnectorType Partner -SenderDomains * -RequireTls:$true -RestrictDomainsToCertificate $true -TlsSenderCertificateName |
もしくは、証明書の代わりに IP アドレスを使用する場合は次のような受信コネクタを作成します。
1 | New-InboundConnector –Name "Reject mail not routed through MX" -ConnectorType Partner -SenderDomains * -RestrictDomainsToIPAddresses $true -SenderIpAddresses <オンプレミスの IP アドレスのリスト、または MX レコードが示す 3rd パーティのフィルタリング サービスの IP アドレスの範囲> |
このようなコネクタを作成すると、テナントに直接送信され、上記で指定した証明書や IP アドレスと一致しないメッセージに対して NDR が生成されることに注意してください。証明書を使用することが、常に推奨される方法です。証明書と IP アドレスのどちらを使用するかにかかわらず、証明書または IP アドレスが変更されると、適切なメッセージであっても拒否されるようになります。
FAQ #4 - リスクなしに本番ドメインをテストで使用できますか？
Office 365 / Azure でテナントを作成し、本番ドメインをテスト中のテナントに追加する場合は、注意が必要です。特にテスト中のテナント内に受信コネクタを構成している場合など、テスト中のテナントで本番ドメインを追加するとすぐに、メールがテスト中のテナントに関連付けられる可能性があります。もしくは、第三者の構成に問題がありメールが意図しないテナントに関連付けられる場合もあります。
言い換えると、追加されたドメインのメールは Office 365 で受信できるようになります。ただし実際の挙動は構成によります。
FAQ #5(a) - Office 365 でなりすましが許可されるのはなぜですか？
まず、SMTP はもともとあまり安全ではありません。誰かがメッセージの送信者をなりすますことは、それが正当 (バルク メール サービス、パートナー組織、3rd パーティ サービス、など) か正当でない (スパム、フィッシング、など) に関わらず、可能です。EOP は正当でないなりすましからユーザーを保護するために最善を尽くし、また正当なメッセージをブロックしないように細心の注意を払っています。 これは、マルチ テナントであるかにかかわらず、他の SMTP サーバーも同じです。 正当な用途が非常に多いため、なりすまされている MAIL FROM に基づいて SMTP レベルでメールを完全にブロックするメール サーバーはほとんどありません。
FAQ #5(b) - このため、Office 365 は危険ですか？
不正ななりすましを検出するには、主に 2 つの標準的な方法があります。SPF ベースのなりすまし検出 は、マルチ テナントのサービスに最適な方法ではありません。Office 365 では通常、疑わしいメールかどうかの判定に SPF だけを使用することはありません。この方法は信頼性が低すぎることが証明されています。Office 365 が使用するもう 1 つの方法である DKIM は、より安全です。既定の DKIM の機能 である程度のなりすまし防止を行うことができますが、DKIM と DMARC の両方を使用することで改善することができます。また スプーフィング インテリジェンス 機能では世界最大のメール プロバイダーとしてのメール フロー パターンの情報を使用しており、SPF、DKIM、DMARC も活用されています。
これらの方法を使用して Office 365 からあなたの組織のユーザーのメールを送信するということは、他の Office 365 のお客様によるあなたのドメインの不正ななりすましが発生しないように弊社を信頼していただいている、と言うことができます。上記のリンクを読んでいただくことで私たちが本気で取り組んでいることをご認識いただけると思います。
FAQ #6(a) - ハイブリッド構成ウィザードが TlsSenderCertificateName にワイルドカードを指定した受信コネクタを作成するのはいつですか？
ほとんどのお客様は exchange.contoso.com のような <ホスト>.<ルート ドメイン> 形式の証明書をオンプレミスで使用しています。しかしながら、ハイブリッド構成ウィザードの実行時に exchange.contoso.com ドメインは通常は Office 365 に登録されていません。メールが確実に機能するように、ウィザードは exchange.contoso.com の代わりに *.contoso.com を証明書として指定したコネクタを作成します。これにより、(a) オンプレミスの証明書が TlsSenderCertificateName に合致し、(b) 承認済みドメイン (contoso.com) にも合致します。ハイブリッド構成ウィザードはこの処理を行うことを事前に知らせてくれます。
FAQ #6(b) - オンプレミスのゲートウェイから送信されるメールが Office 365 テナントを経由しないようにしたいです。どう修正したら良いですか？
残念ながら、複数のテナントを持つお客様や、オンプレミスからの送信ルートが複雑な環境の場合、ワイルドカードによって大量のメールが合致して当該メールが Office 365 テナントに関連付けられる可能性があります。ハイブリッド構成ウィザードによってコネクタが作成されている場合、もっとも簡単な修正方法は次の通りです。
- オンプレミスの Exchange で使用されている証明書の名前 (例 : exchange.contoso.com) を確認します。
- 証明書の名前 (例 : exchange.contoso.com) を正しい Office 365 テナントの承認済みドメインとして追加します。
- オンプレミスのゲートウェイが別の証明書 (例 : mailgateway.contoso.com) を利用していることを確認します。
- ハイブリッド構成ウィザードを再実行します。ハイブリッド構成ウィザードを再実行したくない場合は、受信コネクタの TlsSenderCertificateName を更新して Exchange の証明書 (例 : exchange.contoso.com) のみに一致するようにします。
メッセージの帰属はどのように動作するのか？
本題に戻りましょう。メッセージが Office 365 に送信されると、メッセージを受信するフロントエンド トランスポート サーバーは「そのメッセージが Originating (お客様が送信したもの) なのか Incoming (お客様へ送信されたもの) なのかを判定する必要があります。言い換えると、現在のホップが contoso.com のルーティング構成の内部なのか、tailspintoys.com のルーティング構成の内部なのか、判定する必要があります。
定義
- Originating : テナントのオンプレミス サーバーから発信されたメッセージ (オンプレミス タイプのテナントの受信コネクタと一致するもの)、もしくは Exchange Online のメールボックスから発信されたメッセージ。Office 365 がメッセージを Originating であると識別できず、受信者のドメインが Office 365 組織の承認済みドメインである場合、当該メッセージは当該受信者の組織への Incoming のメッセージであると識別されます。
- Incoming : オンプレミス タイプの受信コネクタに合致しない、Office 365 の承認済みドメインへ送信されるメッセージ。
Office 365 が特定のメッセージについてどのテナントに属するかを決定する方法
基本的な仕組みは以下の通りです。一般的なシナリオをカバーし、理解しやすくするために、少し簡略化されています。
以下の情報を使用してメッセージが Originating か Incoming かチェックされます。
- 送信元サーバーが提示した証明書または接続元 IP アドレス
- MAIL FROM ドメイン
- RCPT TO ドメイン
はじめにメッセージが Originating かどうかチェックします。
Originating
- 証明書の名前もしくは代替サブジェクト名 (SAN) を使用して、合致する受信コネクタを、EOP フォレスト内のすべてのテナントから探します。
- 合致したすべての受信コネクタについて、TlsSenderCertificateName のドメイン名がテナントの承認済みドメインとして構成されているかチェックします。もっとも正確に合致したテナントが選択されます。
- もし 1 つのテナントを見つけられた場合は、メッセージは当該テナントからの Originating であると判定されます。
- もし合致するテナントが見つからない場合、接続元 IP アドレスを調べて合致するオンプレミス タイプのコネクタをすべてのテナントから探します。
- 合致したすべてのコネクタについて、MAIL FROM ドメインが承認済みドメインとして構成されているテナントを探します。もし 1 つのテナントを見つけられた場合は、メッセージは当該テナントからの Originating であると判定されます。
Incoming
メッセージが Originating であると判定されていない場合、メッセージは MX レコードもしくはスマート ホストからのリレーによって送信されてきたメッセージであるとみなします (どちらであったか確認する方法はありません)。
- RCPT TO ドメインがどのテナントの承認済みドメインと合致するのかを探し、メッセージを当該テナントへの Incomming であると判定します。
- 次にメッセージがそのテナント内のパートナー タイプの受信コネクタと合致するかどうかを確認します。合致する場合、メッセージは当該コネクタに関連付けられます。一致するコネクタがない場合、メッセージは既定の受信コネクタを介して当該テナントに到着します。
受信者のドメインを承認済みドメインとして構成しているテナントが見つからない場合、メッセージは Office 365 によって拒否されます。
これで Office 365 におけるメッセージの帰属がどのように機能するかご理解いただけたと思います。