Updated February 4, 2026: We have updated the content. Thank you for your patience. 

Original: Please do not paste images here. Attach your high-resolution PNGs to the No Reply confirmation email. Thank you!

We are reiterating the guidance for connector settings to ensure customers are using healthy configurations. The key problematic configurations we are seeing are:

1. When a tenant has an Inbound connector of type OnPremises and the connector does certificate-based authentication using a certificate with a subject/SAN for a domain that is NOT an Accepted Domain of the tenant.
2. When a tenant has an Inbound connector of type OnPremises and the connector does IP-based authentication, but the IP is used by other tenants On-Premises servers to connect to Exchange Online.

These anti-patterns typically occur when you are using a 3rd party service to relay email through Exchange Online but could also occur if your organization has a single on-premises Exchange Server connecting to multiple Exchange Online tenants.

These configurations can cause incorrect mail flow because Exchange Online is a multi tenant service and relies on message attribution to determine which tenant an incoming message belongs to. When messages are received through an Inbound connector of type OnPremises, attribution is determined using the following priority order:

1. The domain on the TLS certificate presented by the sending server
2. The P1 MailFrom (envelope sender) domain
3. The P1 RcptTo (recipient) domain

[How this will affect your organization:]

We may perform internal changes, such as tenant moves, without notice, which can impact mail flow if a tenant has a bad connector configuration. This means a misconfigured connector that works today may unexpectedly stop working.

[What you need to do to prepare:]

If you have a single on-premises Exchange Server connecting to multiple Exchange Online tenants, your on-premises Exchange environment must use a unique client certificate to send to each unique Exchange Online tenant belonging to your organization. You must configure a unique Send Connector on-premises for each unique tenant in Exchange Online that you want to route on-premises traffic to: Send connectors in Exchange Server | Microsoft Learn. You should also prioritize configuring Inbound connectors of type OnPremises in Exchange Online to use certificate-based authentication, rather than IP based . For best performance, Exchange Online tenants Inbound connector’s should reference the unique client certificate dedicated for that connector path.

If you need to use a third-party add-on service to process email messages sent from your organization and then relay through Exchange Online, the third-party service must support a unique certificate for your organization, and the certificate domain (in Subject name or SAN) must be an accepted domain of your organization. In addition, you must update your Inbound connector of OnPremises type to use the unique certificate domain, via property TlsSenderCertificateName. An example of this scenario is your organization using a third-party CRM cloud service to send emails on behalf your organization to mailboxes of your company or other external users. To learn more, see Scenario: Integrate Exchange Online with an email add-on service.

2026年2月4日更新:内容を更新しました。ご辛抱いただきありがとうございます。 

元の投稿:ここに画像を貼り付けないでください。高解像度のPNGを「返信なし」の確認メールに添付してください。ありがとうございます！

お客様が健全な構成を使用していることを確認するため、コネクタ設定のガイダンスを繰り返します。私たちが見ている主な問題点構成は以下の通りです:

1. テナントにOnPremises型のInboundコネクタがあり、そのコネクタがテナントのAccepted Domainでないドメインの主体/SAN付き証明書を使って証明書ベース認証を行う場合、
2. テナントにOnPremisesタイプのインバウンドコネクタがあり、そのコネクタがIPベースの認証を行う場合、そのIPは他のテナントのオンプレミスサーバーがExchange Onlineに接続するために使用しています。

これらのアンチパターンは通常、Exchange Onlineを通じて第三者サービスを利用してメールを中継している場合に発生しますが、組織内の単一のオンプレミスExchangeサーバーが複数のExchange Onlineテナントに接続されている場合にも起こり得ます。

これらの構成は、Exchange Onlineがマルチテナントサービスであり、受信メッセージのテナントをどのテナントに属するかを判断するためにメッセージの帰属に依存しているため、誤ったメールフローを引き起こすことがあります。OnPremisesタイプのInboundコネクタを通じてメッセージが受信された場合、帰属は以下の優先順位で決定されます:

1. 送信サーバーが提示するTLS証明書のドメイン
2. P1 MailFrom(封筒送信者)ドメイン
3. P1 RcptTo(受信者)ドメイン

[これがあなたの組織にどのような影響を与えるか:]

テナントの移動など内部変更を予告なしに行うことがあり、コネクタ構成が悪い場合に郵便の流れに影響を及ぼすことがあります。つまり、今日動作している誤った接続が、予期せず機能しなくなる可能性があるということです。

[準備のためにやるべきこと:]

単一のオンプレミスExchange Serverが複数のExchange Onlineテナントに接続されている場合、オンプレミスのExchange環境は組織に属する各ユニークなExchange Onlineテナントに固有のクライアント証明書を送る必要があります。Exchange Onlineでオンプレミストラフィックをルーティングしたい各ユニークなテナントごとに、固有のSend Connector on-premanを設定する必要があります: Exchange ServerでSend connectors |Microsoft Learn。また、Exchange OnlineのOnPremisesタイプのインバウンドコネクタを、IPベースの認証ではなく証明書ベースの認証を優先的に設定すべきです。最高のパフォーマンスを得るために、Exchange Onlineのテナントのインバウンドコネクタは、そのコネクタパス専用の固有のクライアント証明書を参照すべきです。

組織から送信されたメールを処理し、Exchange Online経由で中継するためにサードパーティのアドオンサービスを利用する場合、そのサードパーティサービスは組織固有の証明書をサポートし、証明書ドメイン(件名またはSAN)は組織で承認されているドメインでなければなりません。さらに、OnPressタイプのInboundコネクタをTlsSenderCertificateNameプロパティを通じて固有の証明書ドメインを使用するよう更新する必要があります。このシナリオの一例として、組織がサードパーティのCRMクラウドサービスを利用し、会社のメールボックスや外部ユーザーにメールを送信する場合が挙げられます。詳しくは「シナリオ: Exchange Onlineをメールアドオンサービスと統合する」をご覧ください。