Email Routing Architecture: How Mail Actually Moves Through an Organization

MX Is the Beginning of the Journey, Not the Whole Trip

It's easy to think of MX records as "how email routing works," full stop — publish the record, mail arrives, done. For a single small mailbox server, that's roughly true. For any organization past a certain size, MX only answers one narrow question: which host does the outside world hand a message to first. Everything that happens after that handoff — filtering the message through a security gateway, deciding which internal server actually owns the recipient's mailbox, applying transport rules, routing between on-premises and cloud infrastructure during a migration — is a completely separate layer of architecture, invisible to external senders and controlled entirely inside your own perimeter.

This guide covers that internal layer: the routing decisions that happen after MX has already done its job, why they matter operationally, and how the common patterns — security gateway relays, hybrid on-prem/cloud routing, split-domain delivery — actually work in practice.

External Routing vs Internal Routing

These two are governed by entirely different mechanisms, and conflating them causes real confusion during troubleshooting. External routing — how a sender outside your organization finds your domain's entry point — is governed by MX records, published in public DNS, visible to anyone. Internal routing — how a message moves from that entry point to the specific mailbox, distribution list, or downstream system it belongs to — is governed by connectors, transport rules, and often internal (private) DNS zones that external senders never query and can't see. A message can pass through several internal routing hops after MX has already delivered it to your perimeter, none of which are reflected in your public MX record set at all.

The Security Gateway Pattern

A large share of organizations don't point MX directly at their mailbox platform at all. Instead, MX points at a Secure Email Gateway (SEG) — a filtering relay that inspects, scans, and applies policy to every inbound message before forwarding what passes to the actual mailbox platform behind it. This adds a routing hop that's invisible externally: senders only ever see the gateway's hostname in your MX record; the mailbox platform's own inbound address is never published and, ideally, never reachable directly from the internet at all.

The architecture only holds if that second condition is actually enforced. A gateway is only as good as the lockdown behind it — if the mailbox platform still accepts direct inbound connections from arbitrary internet hosts, an attacker who discovers its address (through a leaked header, a misconfigured SPF record revealing infrastructure, or simple reconnaissance) can send mail directly to it, completely bypassing every policy the gateway was supposed to enforce.

Hybrid On-Premises and Cloud Routing

Organizations mid-migration between an on-premises platform (commonly Exchange) and a cloud suite (Microsoft 365 or Google Workspace) often run both simultaneously for weeks or months, with routing rules deciding, per recipient, which system currently owns that mailbox. Microsoft's own hybrid configuration wizard for Exchange-to-365 migrations sets up exactly this: a mail flow connector between the on-prem organization and the cloud tenant, so that mail addressed to a mailbox that's already been migrated gets internally routed to the cloud side even if it initially lands on the on-prem system, and vice versa for mailboxes still pending migration.

This internal handoff is what makes a phased, mailbox-by-mailbox migration workable instead of requiring an all-or-nothing cutover — but it depends entirely on the hybrid connector staying correctly configured and current throughout the migration window, since a stale routing table means mail for a migrated user still tries to land on the decommissioned on-prem mailbox.

Split-Domain Routing

A related but distinct pattern: routing mail for the same domain to genuinely different destinations depending on the recipient, not as a temporary migration state but as an ongoing architecture — common in organizations with acquired subsidiaries, separate business units on shared branding, or deliberately segmented mail environments for compliance reasons. This is typically implemented through recipient-based transport rules at whatever system first receives the mail (often the security gateway or a dedicated routing relay), rather than through DNS, since DNS-based MX routing has no concept of "route based on the specific recipient" — it only knows the domain as a whole.

Cloud Email vs Self-Hosted: The Routing Trade-off

Beyond the redundancy differences covered elsewhere, cloud and self-hosted platforms differ meaningfully in how much routing complexity you're responsible for. A cloud suite abstracts away nearly all of the internal hops — you configure a handful of connectors and transport rules through an admin console, and the underlying infrastructure routing is entirely the vendor's problem. Self-hosted infrastructure puts every hop under your own control, which is powerful for organizations with unusual routing requirements but means every gateway, relay, and internal DNS zone is something your own team designs, documents, and keeps operational.

Performance: Where Routing Hops Add Latency

Each additional internal hop — gateway, relay, hybrid connector — adds processing time, usually modest (milliseconds to low seconds under normal load) but worth accounting for in any latency-sensitive workflow, such as transactional mail where delivery speed matters. The more common performance concern isn't the hop count itself but a misconfigured or overloaded hop in the chain becoming a bottleneck; a security gateway performing deep content inspection under high load can add noticeably more delay than the routing decision itself ever would.

Troubleshooting Routing Issues Beyond MX

When mail is arriving at the organization's perimeter (confirmed via gateway or edge server logs) but not reaching the intended mailbox, the fault almost always lives in this internal layer rather than in DNS or MX configuration at all. A practical sequence:

1. Confirm the message actually reached the first internal hop — check the gateway or edge transport logs for the specific message, not just general delivery volume.
2. Trace the connector or transport rule that should have forwarded it onward — hybrid connectors and transport rules can silently misroute after a configuration change elsewhere in the environment.
3. Check whether the recipient's mailbox has actually migrated (in hybrid scenarios) — mail addressed to a migrated user via a stale routing table is a frequent cause of "delivered but missing" reports.
4. Verify the receiving mailbox platform hasn't rejected the internal hop due to an authentication or relay permission change on that specific connector.

Related Tools

Confirm your domain's public entry point with MX Lookup. Check how your DNS changes are propagating with DNS Propagation Checker. For the priority mechanics behind that entry point, read MX Priority Explained, and for what happens when the primary entry point fails, see MX Failover Guide. When something in this chain breaks, MX Troubleshooting Guide walks through isolating the exact layer at fault.