License pressure
Cloud suites are powerful, but buying premium mailboxes for every worker can turn email into a recurring cost problem.
One domain. Two mail systems.
Keep Microsoft 365 or Google Workspace for the people who truly need it. Route the rest of the organisation to a lower-cost hosted mail platform on the same company domain.
- One domain, two platforms
- Per-user licence savings
- No change for the end user
Premium cloud mail where it counts. Practical mailboxes where it saves.
One company identity
Users should not be pushed to awkward subdomains just because different groups need different mailbox economics.
Harder than it looks
Two systems handling one domain can create loops, rejected mail, broken internal delivery, and authentication gaps if routing is casual.
Integrator-level work
This needs mail-flow design, platform knowledge, DNS control, and cutover discipline. It is not a simple checkbox setup.
Split delivery is routing architecture, not mailbox forwarding.
The inbound path is designed so each recipient lands on the correct system while the organization keeps one public email domain.
Premium users stay on M365 or Google
Executives and teams that need the full cloud suite keep their existing mailbox experience, calendar, collaboration, and admin controls.
Remaining users move to hosted mail
Operational staff, field teams, and high-count user groups can use a lower-cost hosted Linux-based mailbox on the same company domain.
Routing decides the destination
Recipient-based rules, connectors, accepted-domain behavior, and DNS/authentication records are aligned so messages do not loop or bounce.
The risk is in the edge cases.
The obvious mail path is only half the job. Internal delivery, aliases, external replies, authentication records, unknown recipients, and rollback behavior all need a clean answer.
Recipient-aware routing
Mail flow is designed around who owns each mailbox, not just where the MX record points.
SPF, DKIM, DMARC alignment
Sender trust is planned across both systems so outbound mail remains verifiable and deliverability does not degrade.
Bounce and loop testing
Unknown recipients, internal mail, external replies, aliases, and catch-all behavior are tested before rollout.
Hosted Linux-based mail
A Linux-based mail server gives the second mail platform a practical Postfix, Dovecot, and filtering foundation for owned mailbox delivery.
Built for organizations with mixed mailbox value.
Split delivery is strongest when mailbox cost, role requirements, and user count are moving in different directions.
01
Leadership needs Microsoft 365 or Google Workspace, but every worker does not need the same license.
02
The organization wants one professional email domain instead of separate subdomains for different staff groups.
03
Mailbox count is growing faster than cloud-license budgets.
04
Internal IT wants a controlled route, not forwarding chains that become hard to support.
Split delivery questions buyers ask first.
What teams want settled before they commit to running one domain across two mail platforms.
No. Forwarding is a user-level workaround. Split delivery is mail-flow architecture: recipient maps, routing rules, connectors, DNS, authentication, and tested delivery paths.
Yes, depending on which system is primary for inbound processing. The design changes by platform, but the principle stays the same: route each recipient to the correct mailbox system.
That is the point. Selected users can remain on premium cloud mail while other users receive mail on the hosted server using the same organization domain.
Give every employee the same domain without giving every employee the same mail cost.
Bring your current domain, mail platform, user groups, and licensing pressure. We will map whether split delivery is the right architecture before anything moves.