Exchange hybrid mail flow: connectors, TLS certificates and centralized mail transport

Hybrid mail flow looks simple from the outside: on-premises and cloud mailboxes share a domain and mail just arrives. Underneath, it depends on four connectors, a certificate name that both sides agree on, and a header trust that makes cross-premises mail count as internal. In this post I'll take each piece apart, show you how to inspect it, and explain when centralized mail transport is worth what it costs.

How it works#

The connectors the HCW creates#

The Hybrid Configuration Wizard (HCW) creates or changes four connectors. Newer wizard versions add a GUID to their names.

Mail to a cloud user leaves on-premises because the remote mailbox's target address is in contoso.mail.onmicrosoft.com, which matches the send connector. Mail to an on-premises user leaves Exchange Online because the synced mail user points at your domain, which matches the outbound connector.

Certificate name matching#

Both directions use forced TLS with a certificate from a trusted public certification authority, and each side checks the other's certificate. Exchange Online accepts a connection from your servers only if the certificate's Subject or Subject Alternative Name contains the name in TlsSenderCertificateName; otherwise the connection is refused. In the other direction, Exchange Online checks that the certificate your server presents contains the TlsDomain name. That name doesn't have to match your email domains, and a wildcard certificate works.

On-premises, TlsCertificateName chooses which certificate to present. Its format is <I>issuer<S>subject: it identifies the certificate by issuer and subject, not by thumbprint. That detail matters at renewal time, which I cover in Renewing the Exchange hybrid certificate.

Header trust: why cross-premises mail stays internal#

Exchange records how a message was authenticated, and other internal verdicts, in X-MS-Exchange-Organization-* headers. Normally those headers are removed at an organization boundary. The CloudServicesMailEnabled setting on the hybrid connectors and the AcceptCloudServicesMail capability on the receive connector let them pass between your two organizations. That is why mail rules, journaling and anti-spam treat cross-premises mail as internal, and why it bypasses some threat filtering.

If any device or service between your servers and Microsoft 365 rewrites the message, the information hybrid transport relies on is lost and the mail is treated like internet mail. Microsoft supports firewalls that pass port 25 unchanged; it doesn't support SMTP relays or filtering hosts in that path.

Centralized mail transport#

Centralized mail transport (CMT) is an option in the HCW that sets RouteAllMessagesViaOnPremises to True on the Exchange Online outbound connector. With CMT, mail from cloud senders to the internet goes through your on-premises servers. If your MX record points to Microsoft 365, inbound internet mail also goes on-premises first, where it is split per recipient and the cloud copies come back. Microsoft recommends CMT only when on-premises systems must process all internet mail for compliance reasons, because of the extra bandwidth and load. It also makes your servers a dependency for cloud mail, so plan to turn it off before you decommission them.

MX and inbound internet mail#

The HCW doesn't configure inbound internet mail; your MX record decides where it lands. Pointing MX at Microsoft 365 is the common choice. If MX points to your on-premises servers or a third-party gateway, internet mail for cloud users arrives through the hybrid inbound connector, so configure Enhanced Filtering for Connectors on that connector in the Microsoft Defender portal so filtering can see the original sender's IP.

Step-by-step: inspect your hybrid mail flow#

1. On-premises (Exchange Management Shell)#

Get-SendConnector | Where-Object CloudServicesMailEnabled |
  Format-List Name, AddressSpaces, SmartHosts, RequireTLS, TlsAuthLevel, TlsDomain, TlsCertificateName
Get-ReceiveConnector | Where-Object TlsDomainCapabilities |
  Format-List Identity, Fqdn, TlsCertificateName, TlsDomainCapabilities
Get-ExchangeCertificate | Where-Object Services -match 'SMTP' |
  Format-List Subject, CertificateDomains, Issuer, Thumbprint, NotAfter

2. Exchange Online PowerShell#

Get-InboundConnector | Where-Object ConnectorType -eq 'OnPremises' |
  Format-List Name, Enabled, RequireTls, TlsSenderCertificateName, CloudServicesMailEnabled
Get-OutboundConnector | Where-Object ConnectorType -eq 'OnPremises' |
  Format-List Name, Enabled, RecipientDomains, SmartHosts, TlsSettings, TlsDomain,
  RouteAllMessagesViaOnPremises, CloudServicesMailEnabled

3. Compare the names#

• TlsSenderCertificateName in Exchange Online appears in CertificateDomains of the certificate named by the send connector's TlsCertificateName.
• The outbound connector's TlsDomain appears on the certificate named by each receive connector's TlsCertificateName, and SmartHosts resolves publicly to those servers (or your Edge Transport servers).
• The certificate is valid on every server listed, with an expiry date you are tracking.
• RouteAllMessagesViaOnPremises matches your decision about CMT.

Verify#

Send a test message in each direction between an on-premises and a cloud mailbox. In the recipient's message headers, X-MS-Exchange-Organization-AuthAs: Internal shows the message was trusted; Anonymous means it arrived as internet mail. Then follow the message on both sides:

# Exchange Management Shell: which connector sent it?
Get-TransportService | Get-MessageTrackingLog -Sender onprem.user@contoso.com -EventId SEND `
  -Start (Get-Date).AddHours(-1) | Format-List Timestamp, Recipients, ConnectorId, RecipientStatus
# Exchange Online PowerShell
Get-MessageTraceV2 -SenderAddress cloud.user@contoso.com -StartDate (Get-Date).AddHours(-1) `
  -EndDate (Get-Date) | Get-MessageTraceDetailV2 | Format-List Event, Detail

Good looks like: the on-premises ConnectorId is the Outbound to Office 365 connector, and the Exchange Online trace shows the message handed to your on-premises smart host over TLS, without deferrals. More on reading traces in my message trace guide.

Tips and gotchas#

• Change servers or certificates by running the HCW again rather than editing connectors by hand; the wizard keeps the HybridConfiguration object and both sides consistent.
• Cross-premises mail suddenly tagged as external, or landing in Junk, often means something now sits in the SMTP path or mail is taking a route that bypasses the hybrid connectors.
• Deferrals from Exchange Online to on-premises right after a certificate change typically point to a name mismatch or a receive connector still presenting the old certificate.
• If on-premises mailboxes send to the internet through Exchange Online, that's a separate send connector; keep it separate from the hybrid one.
• Don't confuse CMT with your MX choice: they are independent decisions, and the combination decides the path.

References#

• Transport options in Exchange hybrid deployments (Microsoft Learn)
• Transport routing in Exchange hybrid deployments (Microsoft Learn)
• Hybrid Configuration wizard (Microsoft Learn)