Centralized Mail Flow in a Hybrid Exchange Configuration

Microsoft 365 · Hybrid Exchange

A complete guide to routing every inbound and outbound email through your on‑premises Exchange server — and to preventing your users from being reached on their .onmicrosoft.com address.

1. Why centralized mail flow?

In a default Hybrid Exchange deployment, Microsoft configures what it calls a standard hybrid mail flow. Inbound mail for cloud mailboxes is delivered directly to Exchange Online via the tenant's MX record (or via the connector pair set up by the Hybrid Configuration Wizard), and on‑premises mailboxes receive their mail through the on‑prem MX record. Outbound mail leaves the system from whichever side the sending mailbox lives on.

This is fine for most organisations — but it is a problem when you have:

• A regulated industry that requires journaling, DLP or archiving on a specific on‑prem appliance (e.g. a SEG, a hardware archiver, a regulator‑mandated email gateway).
• An existing smart host or mail relay that must continue to inspect every message.
• A need for a single egress IP and a single SPF / DKIM signing point.
• A migration phase where you do not yet trust direct cloud delivery.

The fix is Centralized Mail Transport (sometimes written CMT). When enabled, Exchange Online routes all internet‑bound mail from cloud mailboxes back through your on‑prem Exchange organisation via the outbound connector created by the Hybrid Configuration Wizard. Inbound mail is then directed to your on‑prem MX, and only forwarded to Exchange Online after your on‑prem hygiene stack has processed it.

   Internet                  On-prem Exchange              Exchange Online
   --------                  -----------------              ---------------
                                                                       
  +---------+  inbound   +------------------+  inbound   +-------------+
  ¦External ¦ ---------? ¦  Edge / HT role  ¦ ---------? ¦ Cloud mbx   ¦
  ¦ Sender  ¦            ¦  AV, DLP, Journal¦            ¦             ¦
  +---------+            +------------------+            +-------------+
                                  ?                              ¦      
                                  ¦  outbound (CMT)              ¦      
                                  ¦ ?----------------------------+      
                                  ¦                                     
                                  ? outbound to internet                
                              +---------+                               
                              ¦Internet ¦                               
                              +---------+                               

2. Prerequisites

Before you flip any switches, confirm that the following items are true. Skipping any of these is the most common reason a centralized mail flow change ends in a NDR storm.

3. Enable Centralized Mail Transport

There are two supported ways to turn the feature on: re‑running the Hybrid Configuration Wizard or setting the property directly on the outbound connector. The wizard is the cleanest option because it also realigns the inbound connector for you.

3.1 — Option A: Re‑run the Hybrid Configuration Wizard

1. Open https://aka.ms/HybridWizard on an on‑prem Exchange server.
2. Authenticate with on‑prem and cloud admin accounts.
3. On the Hybrid Features page, tick "Enable centralized mail transport".
4. Finish the wizard and let it update both connectors.

3.2 — Option B: Set the flag with PowerShell

If you prefer not to re‑run the wizard, connect to Exchange Online PowerShell and toggle the property on the outbound connector that the wizard previously created (its name typically starts with "Outbound to").

The flag RouteAllMessagesViaOnPremises is the technical lever behind centralized mail transport. Once it is $true, every message generated by an Exchange Online mailbox — including mail destined for the internet — is handed back to your on‑prem servers via the connector.

4. Make on‑prem the inbound front door

Centralized mail transport only governs outbound direction. To force inbound mail through on‑prem too, you control DNS and the EOP connector setup.

4.1 — DNS

• Set the public MX record for each accepted domain to your on‑prem perimeter (or your SEG that hands off to on‑prem).
• Make sure the tenant's accepted domains in Exchange Online are configured as Internal Relay, not Authoritative. This tells EOP "if the recipient does not exist in the cloud, hand the message to on‑prem instead of bouncing it".

4.2 — Inbound connector from on‑prem to EOP

The HCW already created an inbound connector with type OnPremises. Confirm it is enabled, that it requires TLS, and that it accepts mail from the certificate subject of your on‑prem servers.

5. Block external mail to tenant.onmicrosoft.com

Every Microsoft 365 tenant ships with a vanity domain in the form contoso.onmicrosoft.com. Every mailbox automatically gets a proxy address on that domain — and you cannot delete it. By default, anyone on the internet who knows or guesses the address can reach your users on it, which bypasses your custom routing entirely.

There is no checkbox in the admin centre to refuse those messages, but two clean methods exist.

5.1 — Method 1 (recommended): Mail Flow rule

Create a transport rule in Exchange Online that rejects external mail addressed to anything ending in your onmicrosoft.com domain.

Why this is the recommended path:

• Internal mail flow continues to work, including hybrid migration moves which still need the proxy address.
• Senders receive a clean 5.7.1 NDR rather than a silent drop.
• You can disable the rule instantly during a troubleshooting window.

5.2 — Method 2: Remote domain

An alternative is to rely on the on‑prem perimeter to refuse non‑routable recipients. Because MX now points on‑prem and your accepted domains list does not include onmicrosoft.com, external delivery attempts to that domain will fail at the MX lookup. This is implicit protection, but combine it with method 1 for belt‑and‑braces coverage.

5.3 — Hide the address from the GAL

Optionally, hide the proxy address from address books so users do not see it and share it externally:

6. Validation

Once the configuration is in place, walk through these tests before you call the change done.

Useful tools for the trace:

• Message Trace in the Exchange admin centre (Microsoft 365 Defender portal > Email & collaboration > Exchange message trace).
• Get‑MessageTrackingLog on‑prem.
• Message header analyser at mha.azurewebsites.net to walk every Received hop.

7. Things to keep in mind

• Latency. Cloud‑to‑cloud mail between two of your own users now travels cloud → on‑prem → cloud. Account for the extra round trip.
• Capacity. Your on‑prem servers now carry the full message volume of every cloud user too. Right‑size the transport role.
• Outage planning. If the on‑prem environment goes down, outbound cloud mail goes with it. Document a break‑glass procedure to flip RouteAllMessagesViaOnPremises back to $false.
• EOP licensing. Centralized mail transport does not exempt you from EOP — messages still pass through it; they simply travel a longer path.
• Defender for Office 365. If you use Safe Links or Safe Attachments, make sure the on‑prem leg does not strip headers that the cloud relies on. Skip header rewriting on the on‑prem connector to EOP.
• SPF / DKIM / DMARC. With on‑prem as the egress, your on‑prem IPs must be in SPF, and DKIM signing should happen at the last egress point (typically your SEG or Exchange Online before handover — verify with a test alignment).

8. Roll‑back plan

If anything misbehaves, the fastest way back to standard hybrid mail flow is:

Summary

Centralized mail transport plus an MX pointed at on‑prem turns a hybrid environment into a single‑funnel mail topology: every message in or out of the organisation is inspected by your on‑prem hygiene stack, regardless of whether the user lives on‑prem or in the cloud. Adding a transport rule that rejects external mail to the onmicrosoft.com domain closes the last bypass route and gives you a defensible, auditable mail flow.

The whole change is reversible from PowerShell in less than a minute, which is exactly the property you want from a mail‑flow change in production.

Tested against Exchange Server 2019 CU14 and Exchange Online. Adjust connector names, tenant IDs and accepted domains to match your environment before running the commands.