The short answer
Mail is lost in an email move because MX changes propagate on DNS cache timers, so for a while some senders still deliver to the old server. Lower your TTL first, create the new mailboxes, copy mail over IMAP while both are live, switch MX, keep the old account for two weeks, then cancel.
A surprising number of small businesses stay for years with an email host they actively dislike. The billing is annoying, the webmail is ugly, support is a form that never answers. They stay anyway, because somewhere in the back of their mind is the belief that moving means losing mail, and losing mail means losing a customer they will never even know they lost.
That fear is not irrational. Mail does get lost in badly run migrations. But it gets lost through one specific mechanism, and once you understand the mechanism, the safe sequence follows from it almost automatically. There is nothing clever here. It is a checklist, done in the right order.
Why mail goes missing: the actual mechanism
When someone sends you a message, their mail server does not know where your mailbox lives. It asks DNS. The lookup first attempts to locate an MX record associated with the name, and if one or more MX records are found, the sending system must use only the servers those records point to [4]. Those records also carry a preference value, lower numbers being more preferred, which is how backup mail servers work [4].
So the MX record is the pointer. Change it, and new mail follows the new pointer. If that were the whole story, migrations would be instant and nothing would ever go wrong.
The complication is caching. Every DNS record carries a TTL - a time-to-live field specifying the time interval that the resource record may be cached before it should be discarded [5]. Resolvers all over the internet hold onto your answer for that long rather than asking again for every message. A later clarification to the DNS specification puts a fine point on it: the TTL specifies a maximum time to live, not a mandatory one, and implementations are free to impose their own upper bound on any TTL they receive [6].
Put those two facts together and you have the whole problem. For a window after you change your MX record, the internet holds two different answers about where your mail goes. Some sending servers have already expired their cached copy and deliver to your new provider. Others are still working from the old answer and deliver to your old server. Both groups are behaving correctly. There is no way to force every resolver on earth to refresh at the same instant.
That is why the old mailbox must stay alive and reachable through the cutover. Not out of caution - out of arithmetic. Mail will arrive there. If you cancelled the account the same morning you flipped the record, those messages have nowhere to land.
There is a second timer running as well. When a sending server hits a temporary failure it does not give up; it queues the message and retries. The SMTP standard says retries continue until the message is transmitted or the sender gives up, and that the give-up time generally needs to be at least four to five days [4]. So even a message that was already in flight when you started can land days later. Your overlap window has to cover that too.
Why the mail is copyable at all: IMAP
The other half of a clean move is bringing your history with you, and whether that is possible comes down to which protocol your old mailbox uses.
IMAP is designed around mail living on the server. The specification describes it as allowing a client to access and manipulate messages on a server, permitting manipulation of mailboxes - remote message folders - in a way that is functionally equivalent to local folders, and providing for an offline client to resynchronize with the server [1][2]. Your folder structure, your read and unread marks, the whole archive: it is server-side state, not something your laptop is holding.
That is precisely what makes a migration possible. Because both accounts expose the same operations, a migration tool can log into both at once and move messages across. IMAP's own COPY command copies specified messages to the end of a destination mailbox and says the flags and internal date of the messages should be preserved [1], and APPEND adds a message to a mailbox with its flags and internal date supplied [1]. Practical migration tools work in exactly that shape - read from one side, append to the other, folder by folder - which is why a properly copied inbox arrives looking like your old inbox rather than a pile of undated messages all marked unread.
Contrast the older model. POP3 was designed for a workstation to retrieve mail that the server is holding for it, and the specification states plainly that POP3 is not intended to provide extensive manipulation of mail on the server: normally, mail is downloaded and then deleted [3]. If your old setup works that way, the server copy may no longer exist. Your only complete archive is inside one mail program on one computer, and the migration job is a local export and import rather than a server-to-server copy. Find that out now, not on cutover day.
The order of operations
Everything above collapses into a sequence. Follow it and the failure modes have nowhere to occur.
1. Lower the MX TTL, well ahead of everything else. The catch is that a TTL reduction is itself subject to the old TTL. Resolvers that already cached your MX record are holding the old value with the old timer, and they will not see your reduction until that expires. So if your record was published with a one-day TTL, lower it at least a full day before you plan to touch anything - and if it was published with a week-long TTL, that is your lead time. Do this step and then leave it alone.
2. Create the mailboxes on the new provider first. Every address, every alias, every distribution list. Send test mail directly to the new server's hostname to confirm each one accepts and delivers before any live traffic depends on it. This step changes nothing for anybody: your MX record still points at the old host and all real mail still arrives there.
3. Copy the mail across while both sides are live. This is the step people expect to be scary and it is the safest one in the list. Both accounts are running, both are reachable, and a copy is non-destructive - IMAP's COPY and APPEND write to the destination and leave the source alone [1]. Do the bulk copy now, days before the switch. If it fails halfway, nothing is lost; you fix it and run it again.
4. Switch the MX record. The moment of truth is anticlimactic if the first three steps are done. New mail begins arriving at the new provider as caches expire. A good time to do it is the start of a quiet period rather than a Monday morning.
5. Keep the old account running, and sweep it. For roughly two weeks, log into the old mailbox daily and check for stragglers - mail from senders whose resolvers were slow to update, and queued messages finally delivered after days of retries. Re-run the IMAP copy at the end to pick up anything that arrived after the bulk pass.
6. Only then cancel. When the old mailbox has been genuinely empty for several consecutive days, and only then, close the account. Keeping it one extra month costs less than one lost thread.
When this is overkill
An honest caveat, because the procedure above is written for the case where a mistake is expensive.
If you have one mailbox, a few hundred messages, no staff and nobody else depending on the address, none of this is proportionate. Set up the new account, copy the folders across, switch the record, and you are done in an afternoon. The worst realistic outcome is that a couple of messages land in the old inbox over the next few days and you go and read them there. Do not spend a week project-managing a migration whose entire downside is checking two inboxes for a while.
The careful version earns its keep at a different scale: several people depending on the same domain, shared addresses like info@ or accounts@ that customers reply to, an inbox where a single missed thread is a lost sale or a missed deadline. At that point an extra week of overlap is trivially cheap insurance, and the sequence above is what buys it.
A note on what does not change
Worth saying clearly, because it is the second-most-common worry: your email address does not change. That is the entire point of owning your domain. Nobody needs to be told a new address, no letterhead needs reprinting, no listings need updating. You are changing which server sits behind the name, not the name. Your customers experience nothing.
What does change is your own mail app configuration. Each device - phone, laptop, tablet - needs the new server settings entered once. Budget ten minutes per device per person and do it after the MX switch, not before.
Do this this week
Before you plan any move at all, find out one thing: is your current mailbox IMAP or POP? Open your mail program's account settings and read the account type. If it says IMAP, your history is on the server and a migration can copy it. If it says POP, treat your local mail file as the only copy you have and back it up today, regardless of whether you ever switch providers. That single check takes two minutes and determines whether your move is a copy job or a rescue job.