Hybrid Mail Flow Troubleshooting

Diagnosing connector failures, certificate problems, public folder coexistence issues, and routing breakdowns in Exchange hybrid environments.

Last reviewed June 2026. Companion to the Exchange builder and the mail flow triage guide.

Hybrid environments sit in a permanent state of managed complexity. Two transport systems, two sets of connectors, a shared namespace, and a dependency on a certificate that expires silently are all held together by configuration that the Hybrid Configuration Wizard set up and no one has touched since. When something breaks, the symptoms are often identical to pure cloud problems but the causes are not. This guide covers the differences.

The first question: is this a hybrid routing problem?

Connector health

The Hybrid Configuration Wizard creates two send connectors on-premises and corresponding inbound connectors in Exchange Online. Mail between the two organisations travels over these, authenticated by a TLS certificate. The certificate is the most common single point of failure.

Check the Exchange Online inbound connectors

Get-InboundConnector | Select-Object Name, Enabled, ConnectorType, TlsSenderCertificateName, SenderIPAddresses

The hybrid inbound connector should show ConnectorType: OnPremises, be Enabled, and have a TlsSenderCertificateName matching the certificate your on-premises Exchange server presents. If this value does not match the certificate subject or SAN, every message from on-premises will be rejected with a certificate mismatch error.

Check the Exchange Online outbound connectors

Get-OutboundConnector | Select-Object Name, Enabled, ConnectorType, TlsSettings, SmartHosts, UseMxRecord

The hybrid outbound connector should show ConnectorType: OnPremises, TlsSettings: DomainValidation or EncryptionOnly, and the SmartHosts pointing at your on-premises hybrid server or edge transport. If SmartHosts is wrong or the on-premises server is unreachable on port 25 from Microsoft's datacentre IPs, outbound-to-on-premises mail will fail with a 4.4.1 or 5.4.1.

Test the connector

Test-MigrationServerAvailability -ExchangeRemoteMove -RemoteServer mail.contoso.com -Credentials (Get-Credential)

This does not test mail flow directly but confirms the hybrid server is reachable for remote move operations, which shares the same endpoint. A failure here points at network or certificate issues on the on-premises side.

Certificate troubleshooting

The hybrid certificate must be a public CA-issued certificate (not self-signed), with the hybrid server's FQDN in the subject or SAN, assigned to the SMTP service on-premises, and not expired. Check from the on-premises Exchange Management Shell:

Get-ExchangeCertificate | Where-Object {$_.Services -like "*SMTP*"} |
  Select-Object Subject, Thumbprint, NotAfter, Services, IsSelfSigned

Confirm the FQDN in the Subject or SAN matches what the cloud connector expects. If the certificate has been renewed, update the inbound connector in Exchange Online:

Set-InboundConnector -Identity "Inbound from Contoso" -TlsSenderCertificateName "mail.contoso.com"

Mail routing: cloud to on-premises

For Exchange Online to route mail to on-premises mailboxes, those mailboxes must be represented as mail users or remote mailboxes in Exchange Online's directory. If a migrated user's cloud object is missing or has an incorrect ExternalEmailAddress, mail addressed to them from the cloud goes nowhere.

Get-MailUser -Identity user@contoso.com | Select-Object DisplayName, ExternalEmailAddress, RecipientType

The ExternalEmailAddress should point at the on-premises mailbox's address (typically the .mail.onmicrosoft.com or on-premises SMTP address). If it is blank or wrong, update it:

Set-MailUser -Identity user@contoso.com -ExternalEmailAddress user@contoso.com

For on-premises to cloud routing, Exchange on-premises routes mail for cloud mailboxes via the hybrid send connector to Exchange Online. If the on-premises send connector is missing or disabled, mail to cloud users gets a 5.4.1 loop or unresolved recipient error.

Public folder coexistence

When public folders remain on-premises and cloud users need access, Exchange Online must be pointed at the on-premises public folder hierarchy. This is configured by a RemotePublicFolderMailbox object in Exchange Online and a migration endpoint or the PublicFolderClientAccess setting.

Check the remote public folder configuration

Get-OrganizationConfig | Select-Object PublicFoldersEnabled, RemotePublicFolderMailboxes

PublicFoldersEnabled should be Remote and RemotePublicFolderMailboxes should list the GUID of a valid on-premises public folder mailbox. If this GUID is stale (pointing at a mailbox that no longer exists or has been renamed), OWA will return errors accessing public folders and Outlook may silently fail.

The stale GUID problem

This is the most common public folder coexistence fault: the GUID in RemotePublicFolderMailboxes no longer matches any on-premises mailbox. It typically happens after a public folder mailbox is recreated, renamed, or the on-premises environment is rebuilt. OWA is the most obvious symptom because it throws an explicit error; Outlook may partially work via cached data.

To fix it, find the current on-premises primary public folder mailbox GUID and update the cloud config to match. From on-premises Exchange Management Shell:

Get-Mailbox -PublicFolder | Where-Object {$_.IsRootPublicFolderMailbox -eq $true} |
  Select-Object DisplayName, ExchangeGuid

Then from Exchange Online PowerShell, update the organisation config with the correct GUID:

Set-OrganizationConfig -RemotePublicFolderMailboxes (Get-EXOMailbox "Mailbox1").ExchangeGuid

Verify the on-premises autodiscover and EWS endpoints

Cloud clients accessing on-premises public folders rely on Autodiscover to find the on-premises EWS endpoint. If Autodiscover is broken or returns the wrong endpoint, public folder access fails even when the GUID is correct.

Test-OutlookWebServices -Identity user@contoso.com -MailboxCredential (Get-Credential)

Common hybrid errors