Moving email worries a lot of people: it feels like messages will be lost and employees will be cut off for days. Done in the right order, a migration is barely noticeable. This article is for business owners and IT staff and covers what to prepare, how messages are copied, and when to switch your domain over.
What a migration involves
A mail migration is really three separate tasks, and it helps to keep them apart:
- Creating mailboxes on the new service with the same addresses.
- Copying existing messages from the old mailboxes to the new ones.
- Switching delivery of new mail by changing the domain's MX records, after which incoming mail starts arriving at the new server.
Copying can start early and be repeated, while the MX switch happens once, at a time you choose. Keeping these steps separate is what lets you move without losing mail.
Preparation
Before you start, gather this information and access:
- A list of mailboxes and aliases. Every address, including shared ones (
info@,sales@), forwards, and group addresses. You'll need to recreate aliases and forwarding on the new service. See our article on aliases and forwarding. - IMAP access to the old mailboxes. The sync needs the old provider's IMAP server address and the mailbox passwords (or app passwords, if 2FA is on at the old service). Make sure IMAP is enabled with your old provider.
- Access to your domain's DNS, either at your registrar or with whoever manages the DNS zone.
- Mail volume. Find out how many gigabytes each mailbox uses so you can set quotas on the new service. You can estimate the cost for that amount of storage with the calculator.
- Current DNS records. Save a copy of the zone: MX, SPF, DKIM, DMARC, and records that have nothing to do with email (your website, subdomains). They must not be affected by the move.
If the old mailboxes use POP3 and messages are stored only on employees' computers, they may no longer be on the server. IMAP sync can't move those messages; they'll need to be uploaded from the email app separately.
Copying mail with IMAP sync
Messages are moved over IMAP. A sync tool connects to the old and new mailbox at the same time and copies folders and messages, keeping the folder structure, dates, and read status. Running it again only copies new messages, so you can sync in several passes.
A typical sequence:
- First pass, a few days before the switch. This is the longest one, since it copies the whole archive.
- MX switch, after which new mail starts arriving at the new server.
- Final pass, one or two days after the switch, to pick up messages that still reached the old server in the meantime.
At MCMail, we handle migrations with IMAP sync. Your old mailbox isn't deleted or changed: messages are copied, not moved. If something goes wrong, the original data is still with your previous provider.
Don't cancel your old service right after the switch. Keep it for at least one to two weeks so you can run the final sync calmly and find any message you might have missed.
Switching MX and other records
MYCLOUD sends you the exact DNS records for your domain when you connect it. In general, the following change:
| Record | What to do |
|---|---|
| MX | Replace the old MX records with the new ones. Don't leave the old MX records next to the new ones, or some mail will keep going to the old server. |
| SPF | Update your single SPF TXT record for the new service. Two SPF records on one domain is an error. |
| DKIM | Add the new record with the public key. |
| DMARC | Usually stays the same. It's wise not to tighten the policy during the move. |
| autoconfig / autodiscover | Add them if support provides them, so email apps can configure themselves. |
A day before the switch, you can lower the TTL of your MX records, for example to 300 seconds, so the change spreads faster. After the switch, some servers will keep using cached old values for a while. That's normal, and it's exactly why you need the final sync pass.
Here's what MX records look like in a zone file (the values are placeholders):
example.uz. 300 IN MX 10 mx1.example.uz.
example.uz. 300 IN MX 20 mx2.example.uz.After the switch
- Send test messages from an outside mailbox to several addresses on your domain, and back.
- Check MX with
nslookup -type=mx example.uzordig mx example.uz. - Open the headers of a message you sent, on the recipient's side, and make sure SPF, DKIM, and DMARC all show
pass. - Reconfigure employees' email apps: incoming server
mail.mcmail.uz(port993), outgoing servermail.mcmail.uz(port465), and the full email address as the username. Webmail is available athttps://mail.mcmail.uz. - Recreate aliases, forwards, auto-replies, and filters.
- Check calendars and contacts. If needed, export them from the old service and import them into the new one.
Common mistakes
- Switching MX before creating the mailboxes. Incoming mail gets rejected as addressed to nonexistent recipients.
- Deleting the old account right away. The final sync is no longer possible.
- Leaving the old SPF record. Mail from the new server lands in recipients' spam folders.
- Forgetting shared addresses. Mail to
info@stops arriving. - Accidentally deleting website records while editing the DNS zone.
Migration checklist
- List of mailboxes, aliases, and forwards is ready.
- A copy of the current DNS zone is saved.
- Mailboxes are created on the new service and quotas are set.
- IMAP access to the old mailboxes is confirmed.
- The first sync pass is done.
- TTL is lowered, then MX, SPF, and DKIM are changed using the values from support.
- Incoming and outgoing delivery is tested.
- Email apps and phones are reconfigured.
- The final sync pass is done.
- The old service is canceled no sooner than one to two weeks later.
If you're planning a move to MCMail, start with the 14-day trial and message @mycloudsupport so we can agree on the order and timing of the switch.