What Is Split-Domain Email Routing and When Do You Need It?

Split-domain email routing means running a single email domain — say company.com — across two separate mail systems at the same time. Mail for some users lands on one system; mail for other users routes to a second system. The two systems divide the domain between them, each handling the mailboxes it owns.

The mechanism exists almost entirely for one reason: phased migration. Moving a company's entire mail infrastructure in a single cutover is risky, so organizations migrate in waves — a department this week, another the next. Split-domain routing keeps mail flowing to everyone, migrated or not, for the entire duration of that process.

What split-domain email routing actually is#

At the DNS level, your domain has one set of MX records pointing at a primary mail system. When a message arrives, that primary system checks whether it knows the recipient. If the recipient's mailbox lives there, it delivers locally. If it does not find the recipient — because that user has not been migrated yet — instead of bouncing the message, it forwards it to a second server: the routing host.

The routing host is the address of your old or secondary mail system. It receives the forwarded message and delivers it to the user's actual mailbox. From the sender's perspective, nothing changes. From the recipient's perspective, the message arrives normally. The complexity is entirely hidden at the server layer.

This configuration is temporary by design. Once the last mailbox migrates, every recipient address is known to the primary system and the routing host is removed.

A note on vendor terminology#

The mechanism is not standardized in naming across platforms. Different vendors document the same routing behavior under different terms, which creates genuine confusion when reading migration guides from more than one source.

How split-domain routing works, step by step#

The flow involves three actors: the sending server, the primary mail system (which owns the MX record and holds migrated mailboxes), and the routing host (the old or secondary system, holding unmigrated mailboxes). The routing decision happens entirely on the primary system — the secondary system is passive, receiving whatever the primary forwards.

1. 1

   Sender delivers to the primary MX host

   The sender's server looks up MX records for company.com. All MX records point at the primary system — the new platform the organization is migrating to. The sending server connects and delivers the message there. The sender has no awareness of the secondary system.

2. 2

   Primary system checks its directory

   The primary system looks up the recipient address in its own user directory. If the recipient's mailbox has already been migrated, it delivers locally and the message never touches the secondary system.

3. 3

   Unknown recipient triggers forwarding

   If the address is not found locally, the primary system forwards the message to the configured routing host — the address of the secondary system — rather than returning a 550 User Unknown error to the sender.

4. 4

   Secondary system delivers

   The routing host receives the forwarded message and delivers it to the unmigrated user's mailbox on the old system. The user reads it there, exactly as they did before the migration began.

What breaks if you skip split-domain routing#

Without split-domain routing, a phased migration forces a hard choice: move everyone at once — a high-risk big-bang cutover — or accept that mail to unmigrated users bounces for the duration of the migration.

That bounce is the failure mode split-domain routing exists to prevent. The primary system, now owning the MX record, receives a message for a user whose mailbox it does not have yet. With no routing host configured, it has no forwarding target and rejects the message. The sender receives a non-delivery report. The recipient never knows the message was sent.

The impact is not theoretical. In a migration touching hundreds of users over several weeks, every unmigrated user is effectively unreachable from outside the organization from the moment the MX record changes until their mailbox moves. For a company with external clients or partners, that is a serious operational gap.

Split-domain routing versus dual delivery#

These two terms are sometimes used interchangeably in migration guides, but they describe different behaviors. Getting them confused leads to misconfigured migrations and either duplicate messages or coverage gaps.

Common misconceptions#

Because split-domain routing is a migration tool rather than a permanent architecture, several misconceptions persist in documentation and migration planning.

It is not a load-balancing mechanism. Distributing inbound mail across multiple servers for capacity reasons uses a different approach — multiple MX records with different priorities, or a single MX pointing at a cluster. Split-domain routing routes based on whether a recipient's mailbox exists on a given system, not on server load. The two have nothing in common architecturally.

It does not let two users share the same email address across systems. Each address exists on exactly one system. The routing logic is a directory lookup: if the address is found locally, deliver; if not found, forward. Two mailboxes at the same address is a conflict the primary system cannot resolve by forwarding.

It is not a permanent configuration for running two separate mail platforms in parallel indefinitely. Organizations that have completed a migration and left the routing host in place are carrying unnecessary relay infrastructure. Once the last mailbox moves, the routing host configuration should be removed.

Finally, the different vendor terms are not errors or marketing spin. Shared address space and split delivery are the same SMTP behavior documented under different names by Microsoft and Google respectively. When you read one term in an Exchange guide and another in a Workspace guide, they are describing the same routing mechanism applied on different platforms.

How this relates to AI Emaily#

Split-domain routing operates at the mail-server layer — between the MX record and the mailbox. A mail client has no role in this routing decision and cannot configure or influence it. AI Emaily is not a mail-routing service, an MX host, or a migration management platform, and it does not interact with split-domain or routing host configuration in any way.

Where AI Emaily becomes relevant is after migration: once a mailbox has moved to its new system — Gmail, Outlook, or any IMAP provider — that is the mailbox AI Emaily connects to. It handles triage, drafting, and autonomous action on the mail that lands there on the migrated system, not in the coexistence layer above it. We build AI Emaily, and connecting an existing Gmail or Outlook account takes under two minutes. It comes with a 7-day free trial on the Pro and Autopilot plans.