Services
Summary
Updated guidance warns against using OnPremises inbound connectors with certificates for domains not accepted by the tenant or IPs shared by multiple tenants. Misconfigurations can disrupt mail flow. Use unique client certificates and send connectors per tenant, and ensure third-party services use certificates matching accepted domains.
Details
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:
- 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.
- 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:
- The domain on the TLS certificate presented by the sending server
- The P1 MailFrom (envelope sender) domain
- 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.