Split Domain Routing: Getting Email for Your Domain at Two Providers

Published: February 20th, 2013

Split Domain Routing (SDR) is a term used when you wish for some users in your domain to be able to get email at company X while others can get their email at company Y … and all these users have email addresses in the same domain.

For example, lets say your company domain is “my-doctors-on-call.com” and you are in the process of moving your email from some company X to LuxSci.com. You have doctors Joe and Emily whose email addresses are joe@my-doctors-0n-call.com and emily@my-doctors-on-call.com.  The migration is not complete or you need to migrate over time for some reason … so Joe needs to still get his email at Company X, but Emily is all moved and needs to get her email at LuxSci.com.  This is “Split Domain Routing” … some email going one place, some going elsewhere.

Why Split Domain Routing is Not Simple

To understand how SDR can be implemented, we need to take a step back and understand how email routing and delivery works in the first place.

Each domain has “DNS Records” which are published on the Internet and are used to tell the world things such as what Internet address your web site is located at and what email servers receive inbound email for your domain.  See Understanding Domain Name Service (DNS) to learn more about this.

Part of these DNS records are Mail Exchange (MX) records.  These specify the email servers where your inbound email should be delivered.  You can have more than one MX record … but generally they are all at the same provider and multiple definitions are used only for redundancy.

As all email for all users in your domain is delivered to the servers defined in your MX records without respect for WHO the email is destined for, you cannot enable Split Domain Routing via any kind of special DNS settings.  Instead, you have to pick one of the companies and have ALL of your email delivered there.  So, any kind of re-routing of email to some folks needs to happen via special rules at one of your email service providers.

A Recipe for Split Domain Routing

Lets take the scenario where my-doctors-on-call.com is migrating from provider X to LuxSci.com and needs SDR to get email for some users at LuxSci.com before the transition is complete.  Clearly, once the migration is complete, the DNS MX records for my-doctors-on-call.com will be updated to point to LuxSci’s MX records and SDR will be no longer needed.  However, before that, they need a protracted migration period for business reasons and require SDR.

Here is how it is set up:

  1. The DNS MX records for my-doctors-on-call.com will remain pointing to the inbound email servers of Company X
  2. LuxSci.com will setup a “subdomain” called “sdr.my-doctors-on-call.com” on its email system and configure it as a “domain alias” whereby any email that arrives for “emily@sdr.my-doctors-on-call.com” is merely delivered on LuxSci to emily@my-doctors-on-call.com”.
  3. DNS MX records for sdr.my-doctors-on-call.com will be created and these will point to LuxSci’s inbound email servers.
  4. The customer will create email forwarding rules in company X so that any inbound email messages that arrive at Company X for any users that want to get their email at LuxSci.com now are forwarded to those user’s addresses @sdr.my-doctors-on-call.com.  For example,  the customer would create a rule so that email to emily@my-doctors-on-call.com is forwarded to emily@sdr.my-doctors-on-call.com
  5. As more users are migrated to LuxSci.com and ready to use email there, similar forwarding rules are created.
  6. Once everyone is migrated to LuxSci.com, the DNS MX records for my-doctors-on-call.com itself can be updated so that email is delivered directly to LuxSci.com, the subdomain can be deleted, and the account with provider X can be closed.

Here is how this works:

  1. All email for @my-doctors-on-call.com arrives at Company X
  2. Email for selected users is forwarded to addresses @sdr.my-doctors-on-call.com
  3. The DNS MX records direct that email to LuxSci.com.
  4. LuxSci.com recognizes these and delivers them locally to the respective LuxSci users @smy-doctors-on-call.com

This results in effective Split Domain Routing, where you can control exactly what addresses receive email at which providers.

What are the requirements for Split Domain Routing to Work?

  1. You must be able to make MX records for subdomains in your DNS.  Most DNS providers allow you to do this … but some are so dumbed down that this is not possible. If you have that kind of provider, maybe it’s time to change.
  2. Your current provider must allow you to forward email messages … most providers allow this.
  3. Your target provider must support subdomains which can work as “aliases” so that email to addresses in the subdomain can be delivered locally to the actual users in the main domain.  LuxSci.com supports this, as do some other providers.

Are there any down sides to Split Domain Routing?

Clearly, adding SDR to your system adds complexity and should generally only be used as a temporary measure or in special situations.  Here are some issues that could crop up that you should be aware of when deciding whether to use SDR:

  1. Email to users at the target provider have a longer way to go.  They must be delivered to the first provider and then forwarded and delivered to the second provider.  They may pass through multiple spam filters and other things.  Generally, this is fine, but it could cause delays or delivery issues for some users that are not present for other, non-forwarded  users.
  2. Email sent from users at the target company to users still at the old company may be delivered to the wrong place, depending on how the target company routes email (e.g. do they automatically deliver the email to themselves … or do they obey your DNS MX records)?  At LuxSci, this is not a problem as LuxSci delivers to your MX records and not locally … but it may be an issue with other companies.

What are other uses for Split Domain Routing?

There are many more applications for SDR than just migration to a new provider.  These include:

Split Environment.

If some users require “Exchange” and some require a different kind of service (like HIPAA complaint email), you could use SDR to separate the Exchange users from the HIPAA users at a different provider.  In this case, you would want the email delivered to the HIPAA provider first and the non-HIPAA split addresses forwarded (over SMTP TLS) to the exchange provider.

Backup Environment.

A slight twist to Split Domain Routing is when you forward ALL email for all users to the second provider … but also allow these emails to be delivered to your primary provider.  This causes a “fork” in your email flow where all of your email goes to two places.  This can be useful as if the primary provider goes down, you can just login to the secondary provider and get all of your email and send email (and receive email if you update your MX records).

We have several customers who use this approach where they

  1. Have a dedicated server in our premium environment for regular day-to-day email usage, and
  2. Have a shared email account in our basic environment that receives copies of their emails in this way so that if the premium environment were ever offline, they could still access all their email though our geographically separate basic environment.

Of course, one can achieve a similar level of redundancy with

  • Email Archival — to keep immutable copies of all inbound/outbound email.
  • Email Continuity — a premium email filtering solution which spools your email in the case your inbound email servers are unavailable.  It also allows you to send and receive email in this case.

Which solution is better? A complete backup environment, or continuity+archival, or both, depends on your business and your disaster recovery needs.

 

Leave a Comment


You must be connected or logged in to post a comment. This is to reduce spam comments.

If you have not previously commented, you can connect using existing social media account, or register with a new username and password.