Coexistence Mail Flow During a Staged Hybrid Migration
Contoso runs Exchange 2016 CU20 in one AD forest with 4,200 mailboxes split between Amsterdam and Singapore. A nine-month staged migration to Exchange Online begins with a 600-mailbox pilot. A compliance contract requires every internet-bound message from cloud mailboxes to be journaled by the on-premises third-party archive until the contract expires next year, so cloud outbound mail must transit the Amsterdam hub. A billing application in Singapore relays unauthenticated SMTP to a local Exchange receive connector; the vendor cannot add authentication or TLS. The partner domain publishes a strict SPF record and requires TLS on port 25. Five days after the Hybrid Configuration Wizard finished, pilot users report non-delivery to the partner, on-premises users cannot email migrated pilot mailboxes, and the archive shows gaps for cloud-originated mail. Autodiscover still resolves all users to the on-premises namespace.
1. Trace the expected path for a message from a migrated pilot mailbox to the external partner and identify the most likely cause of the archive gaps. What would you check first, and in what order?
Read the worked answer
With centralized transport enabled, the path should be: cloud mailbox -> Exchange Online transport -> outbound connector to on-premises (smart host = hybrid FQDN) -> 'Inbound from Office 365' receive connector on an on-premises Mailbox server -> transport service -> journal agent -> on-premises Send connector to the partner. Archive gaps for cloud-originated mail point to the first leg bypassing the hub, not to a broken journal rule.
Check in this order:
- Get-TransportConfig | fl CentralizedTransportEnabled. If false, Exchange Online sends directly to the internet.
- The HCW-created 'Inbound from Office 365' receive connector exists on every Mailbox server and its TLS certificate contains the hybrid FQDN.
- The tenant outbound connector to on-premises is enabled and uses the correct smart host.
- Each pilot mailbox has a remote routing address and the on-premises object has the correct targetAddress.
On-premises-to-cloud failures often share the same root cause: the send connector's source servers or the receive connector's certificate. Fix routing first, then re-test journaling with one pilot message and trace it through message tracking on both sides. Autodiscover pointing to on-premises is a separate client-access issue and would not itself cause the archive gaps.
2. The partner reports TLS negotiation failures and SPF failures for messages from migrated users. Explain each symptom and the configuration change that addresses it without moving mail flow back to the internet.
Read the worked answer
The two failures have different causes.
TLS: the partner requires TLS and validates the certificate presented on the SMTP session. If the on-premises Send connector presents a self-signed certificate, or a public certificate whose SMTP FQDN does not match the name the connector advertises, the partner aborts. Assign a public CA certificate to the Send connector and set TlsCertificateName / the connector FQDN to the name in the certificate; confirm the partner accepts TLS 1.2.
SPF: centralized transport makes cloud-originated mail exit through the on-premises public IP, so the partner evaluates SPF against that IP. An SPF record that only includes spf.protection.outlook.com will fail. Add the on-premises egress IP to the contoso.com SPF record, or move cloud users to a subdomain with its own SPF record, before the change and lower the TTL.
Do not disable centralized transport to 'fix' SPF, because that violates the journaling contract. Verify with an external SMTP test that the HELO name, certificate name, and source IP all align.
3. The Singapore billing host will be decommissioned. Design the least-privilege receive connector configuration on the surviving Exchange servers and explain why an anonymous relay connector in Exchange Online is not a valid substitute.
Read the worked answer
Create a dedicated Receive connector on a single Mailbox server, not on all servers, bound to the local IP address that the billing host can reach, with RemoteIPRanges limited to the billing host's address. Allow anonymous authentication on that connector, but do not grant relay on the default connector. Grant the relay permission only on that connector by adding the ms-Exch-SMTP-Accept-Any-Recipient extended right to the connector's Anonymous logon security principal. Keep the connector off the internet-facing firewall rule and monitor it. This gives the app the minimum it needs: unauthenticated relay from one IP to any recipient, on one server, with no TLS requirement.
Exchange Online cannot be substituted because it has no anonymous relay receive connector. Direct send to the MX record only accepts mail for your own accepted domains, and SMTP AUTH client submission requires authenticated TLS. If the app must send to external recipients, the options are a licensed mailbox with SMTP AUTH and hardening, or a dedicated relay service. An open anonymous relay in the cloud would be a spam gateway.