This is a method of switching email provider for a domain designed to minimize downtime. It was originally meant for IT people but not necessarily those who spend all week moving web hosting accounts. I realized thought that it was going to have to be a bit more complex than that. So there will be a weird mix of _inside baseball_ and stuff that only a noob would need to be told.
Let’s make up some addresses to use as placeholders and use my domain as an example of a domain to be moved.
Source provider(referred to as old provider)
| IMAP server | imap.host-a.com |
| SMTP server | smtp.host-a.com |
| DNS servers: | dns1.host-a.com, dns2.host-a.com |
Destination provider(referred to as new provider)
| IMAP server | mail.xhost.com |
| SMTP server | mail.xhost.com |
| DNS servers: | ns1.xhost.com, dns2.xhost.com |
Switching email provider
First we create two subdomains for deref.se called imap.deref.se and smtp.deref.se.
| imap.deref.se | CNAME | imap.host-a.com |
| smtp.deref.se | CNAME | smtp.host-a.com |
The point of this is to move users with @deref.se-email addresses away from the old hosting providers names. We can’t keep using *.host-a.com for fetching emails once we’ve moved so sooner or later every device fetching and sending email using the deref.se domain name will have to be updated with a new IMAP server and a new SMTP server. By having these two records that lead back to the same place as the old records we can slowly move one user after another over to the new server names.
The standard approach is often to make a mad dash at some specific moment in time to switch all email-enabled devices from imap.host-a.com to mail.xhost.com so as to make the jump to the new hosting provider. But that’s error prone and stressful at best. Use server names decoupled from the source provider to make updating email clients workable.
Caveats so far
- If you use SSL or TLS encryption at the old hosting provider you are going to want to issue certificates for these new subdomains( imap.deref.se and smtp.deref.se in this example ) before modifying any email clients. Otherwise big warnings and connection errors will affect email clients that use the new subdomains for fetching and sending email.
- If you don’t know the password for all email accounts, set new ones when re-configuring the email clients. Sit down with Alice, set a new password for her email account and enter it into her phone and computer along with the new server names. Then go and do the same for Bob and so on.
Actual move
You should now have no email clients configured to connect to any host-a.com servers directly. They should all go via the new server names imap.deref.se and smtp.deref.se. You should also have a list of all the passwords used for the email accounts. If you use SSL/TLS you need to copy the SSL certificates used at the old hosting provider to the new one. You can test that they work correctly by changing your computer’s hosts file( https://www.howtogeek.com/howto/27350/beginner-geek-how-to-edit-your-hosts-file/ )
- Set the DNS-records imap.deref.se and smtp.deref.se to a TTL-value as close to 300 seconds as possible. Technically you could go lower but a five minute switch is typically fine. Do this at least X seconds before the actual move of the site where X is the old TTL-value.
- Create all the email accounts at the new hosting provider using the passwords from your list.
- Copy over the contents of each email account from the old provider to the new empty accounts over at the new provider. Consider using a tool like imapsync.
- Change the new records to the settings below:
| imap.deref.se | CNAME | mail.xhost.com |
| smtp.deref.se | CNAME | mail.xhost.com |
Congratulations, you have now moved email hosting to the new provider! I’d run imapsync once TTL seconds have passed. So five minutes after the DNS records were changed to point to the xhost.com-servers, running imapsync again will copy over any emails that happened to end up with host-a.com instead of xhost.com as the record-change propagated to DNS-servers across the internet.
Benefits so far
So here the big switch from one hosting provider to another is pretty much invisible to end users. They notice the preparations like re-configuring their email clients but that’s a brief visit from the local tech person, not a mad dash where dozens of people all try to change the settings on their email clients so that their email will work again.
Drawbacks so far
This approach requires more work for the person doing to move. Not creating provider-independent DNS records, leaving the TTL and just sending users a list of new settings and passwords takes less time. If you use the provider’s server names you can usually let them handle the SSL certificates.
On balance
How long is the CEO willing to have email work on his laptop but not his phone? Two weeks? One week? The closer you want to be to an imperceptible blip when switching email providers the more you should favor the benefits of this approach over the drawbacks.