I am considering migrating my e-mail from one hosted provider to another; specifically to Proton Mail, but I don’t think that matters. My trepidation comes from my personal domain and the potential for either a temporary loss of service, loss of my e-mails, or both.
My current provider manages my domain, DNS and mail hosting (IMAP-based). I have three mailboxes, let’s call them {a,b,c}@example.com
; I also have a subdomain, where everything sent to, say, [email protected]
is forwarded to [email protected]
, but there is also a list of exceptions (say {x,y,z,…}@bar.example.com
) that get forwarded to [email protected]
.
Here are the steps that I think I need to do:
- Transfer my domain to a new registrar. (I believe this maintains the current DNS records, except perhaps for the NS records.)
- Sign up for the alternative mail host (Proton Mail).
- Configure the MX records for my domain for Proton Mail.
- Create the
{a,b,c}@example.com
mailboxes in Proton Mail. - Migrate the e-mails from the old provider’s mailboxes to the new. (I believe Proton Mail has a tool to do this.)
- AFAIK, Proton Mail doesn’t have forwarders but, regardless, a subdomain would [probably] be considered a separate custom domain, which is outside the scope of my intended price tier. As such, I need to set up mail forwarders outside of Proton Mail. I’ve found ForwardEMail.net, which offers a free, DNS-based solution to this. I can set this up in the DNS records for
bar.example.com
as documented.
Is that everything? Would you, for example, recommend taking a local backup of e-mails? Importantly, does the order matter: registrar/DNS changes take time to propagate and there’s a bit of a chicken-and-egg problem when it comes to migrating mailboxes? How do I overcome these?
(Meta-question: Is it worth it? Obviously that’s a personal decision, but this will ultimately be more expensive and decentralised than my current service. The current service works and is relatively easy to manage, but is a bit antiquated. Anecdotes from people who have gone through a similar process would be welcome.)
Yes, if you are set on changing all of mail hoster, domain registrar and dns hoster, your order is reasonable: begin with the DNS steps. Your old mail hoster may not allow you to configure all records in exactly the way the new mail hoster recommends. Yet any general-purpose DNS hoster should be able to mirror your status quo. I have had to work around this in a similar exercise where the old bundled offer was simply not geared towards general-purpose DNS hosting and only served the requirements of their own offerings.
No, if you are still wondering about "DNS propagation time", your plan is still incomplete. Do familiarize yourself with split between a) the entity that pays your ICANN fees and sends your nameserver/DNSSEC info to the top level domain operator and b) the entity that is operating your nameservers and letting you modify your zones. Even if it turns out to be something you again purchase with the same company, unbundling this will help you correctly follow established practices around the timing of lowering TTL and making changes, so you do not have to worry as much about excessively long caches.
There is no chicken-and-egg problem, there is merely quite a bit of understanding (of why the systems behaves like it does) necessary until you are able to execute the steps in an appropriate order.
If you do not have one, make one right away. Even if that is unlikely to end up as your preferred source for restoring your mailboxes at the destination. To be precise, I do not find it necessary to have local as in "your office" (which may be bandwidth-constricted) - but it does have to be off-site in the sense that it is in a data centre that shares little common risk with the location of your current and future providers.
Having more parties involved is not necessarily advantageous in mail hosting, as both the receiving server and everyone with the power to modify your DNS records can intercept, modify or simple reject mail that was meant for you. An obvious example of how this can go wrong would be a mail hoster based in Switzerland that stopped handling your mail because you have become unable to pay your fees with your (insert US-sanctioned place) based DNS hoster. You may find that reliability, customer support, price stability and a number of security topics is much better than flashy features (that may or may not also be otherwise acquired by using a different mail client).