💡 Our Technical Review in summary
Summary
- Microsoft is reiterating critical guidance for “OnPremises” type Inbound connectors to ensure correct message attribution in Exchange Online.
- The update targets two specific “anti-patterns”: using certificates with domains not registered as Accepted Domains, and using IP-based authentication with IP addresses shared across multiple tenants.
- Correct configuration is essential because Exchange Online is a multi-tenant service that relies on specific priority logic (Certificate Domain > MailFrom Domain > RcptTo Domain) to route incoming mail to the correct tenant.
Impact
- Service Reliability: Misconfigured connectors that currently function may stop working without notice due to internal Microsoft tenant moves or infrastructure changes.
- Mail Flow Disruptions: Incorrect attribution can lead to emails being rejected or misrouted if the system cannot definitively identify the source tenant.
- High-Risk Environments: Organizations using third-party email relay services (e.g., CRMs, security gateways) or organizations with a single on-premises Exchange server connecting to multiple Microsoft 365 tenants are most likely to be affected.
Action Required
- Review On-Premises Setup: If one on-premises server connects to multiple tenants, you must use a unique client certificate for each tenant. Configure a unique Send Connector on-premises for every destination tenant.
- Verify Certificate Domains: Ensure that any certificate used for authentication on an “OnPremises” Inbound connector has a Subject Name or Subject Alternative Name (SAN) that matches a domain already added to your “Accepted Domains” list.
- Transition to Certificate Authentication: Prioritize certificate-based authentication over IP-based authentication. If using IP-based connectors, ensure the IP address is not shared with other Microsoft 365 customers.
- Coordinate with Third Parties: If using a third-party service to relay email through Exchange Online, verify they support unique certificates for your organization. Update your Inbound connector via the
TlsSenderCertificateNameproperty to match this unique certificate. - Audit Existing Connectors: Perform a technical audit of all Inbound connectors in the Exchange Admin Center to identify and remediate configurations using non-accepted domains or shared IPs.
Microsoft Official Update
Service: N/A
Category: preventOrFixIssue
Severity: normal
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.
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.
