Google Workspace split delivery: plan the recipient routes
Understand how Gmail and another mail system can serve different people at the same domain, and what to check before changing delivery.
Google Workspace split delivery lets some recipients at a domain use Gmail while others use another email system. For example, [email protected] can use Gmail while [email protected] stays on a different server. A routing rule makes that decision; adding two unrelated providers’ MX records does not create a recipient directory.
This arrangement can support a staged migration or a deliberate long-term mixed environment. It also introduces another system to maintain. For a small team, the saving from fewer Workspace licenses needs to justify the routing and support work.
Split delivery and dual delivery answer different questions
Google’s routing overview distinguishes split delivery, which chooses a mail system by recipient, from dual delivery, which delivers messages to multiple inboxes. If one person needs a copy in both systems, do not assume split delivery supplies that behavior.
| Requirement | Model to investigate |
|---|---|
| Alex uses Gmail; Sam uses the other server | Split delivery |
| Alex needs the same incoming message in two inboxes | Dual delivery |
| One old address should reach a replacement address | Forwarding or an address map |
| Every misspelled address should reach an administrator | A catch-all policy, evaluated separately |
Understand the Google-first route
In Google’s documented setup, the domain’s MX records point to Google. Gmail initially processes incoming messages, then routes the selected recipients to the non-Gmail server. Recipients belong in one destination system for this model.
- Mail reaches Google The domain’s MX records identify the initial receiving system.
- Recipient is evaluated The routing policy determines which system owns the address.
- Deliver once Keep the message in Gmail or route it to the other server.
The official procedure adds the other mail server as a route, then configures a Gmail routing rule. Its account-type and envelope filters determine which addresses take that route. Follow the current documentation for your account; this guide explains the decisions to resolve before applying it.
Create a recipient map before changing delivery
List every mailbox, alias, group, and automated address. For each, name one destination and an owner. Decide what should happen to an address absent from both systems. Forwarding every unknown address to the other server can be intentional, but it should not accidentally turn that server into an unmonitored catch-all.
Also document the path for messages sent by colleagues. External mail reaching Google does not prove a message sent from the second system to a Gmail colleague will leave that system correctly. Local-domain routing assumptions on the second server can strand those messages.
Do not point the onward route back to a hostname that resolves through the same incoming MX path. The destination needs to reach the other system as intended. Ask the other provider whether it supports this configuration, what hostname to use, and what TLS and recipient-validation requirements apply.
Check the routes that commonly get missed
- External sender → Gmail user.
- External sender → non-Gmail user.
- Gmail user → non-Gmail colleague, and the reverse.
- Mail to aliases and groups with members on both systems.
- Mail to an address that does not exist anywhere.
- Replies from each system to an external recipient.
For each check, record the message identifier, timestamp, expected destination, and observed result. A loop, duplicate, or missing message should be traced through both systems’ logs. Repeatedly changing MX records without identifying the failing route adds uncertainty.
Separate routing from migration and sending authentication
Split delivery does not copy old messages, calendars, or contacts. It also does not by itself authorize both systems to send as your domain. Plan historical data transfer and outbound authentication as separate work, then verify each sending path.
If split delivery is temporary, assign an end date and a removal checklist. After the last user moves, remove obsolete routes only after checking aliases, groups, and application mail. If it is permanent, keep a recipient-change process so a new employee is added to the correct system instead of depending on an undocumented exception.