Moving your email: the plan

Module 8: Moving and getting your domain in order · Reading time: 11 minutes

Learning objective: After this lesson, you'll be able to plan a move of your email to another provider: what to take stock of beforehand, in which order to work, and what doesn't come along automatically.

Key concepts: inventory (mailboxes, aliases, forwards, catch-all, autoresponders, filters), mailbox size and storage, passwords, lowering the TTL in advance, order (creating accounts, first copy, switching MX, second copy, devices), calendar and contacts (not IMAP), POP3 mail on the computer, Microsoft 365 and Gmail (signing in instead of a password), DNS records that need to move too, communication

What are you actually moving?

"Moving my email" sounds like one thing, but it's actually at least five:

1. The mailboxes themselves, with all the folders and messages stored on the server.
2. The addresses around them: aliases, forwards, a catch-all, mailing lists, autoresponders and filters on the server. These live in your old provider's control panel and never come along automatically.
3. Your email's DNS: MX, SPF, DKIM, DMARC, and possibly autodiscover, autoconfig or SRV records. After the move, these need to match the new provider.
4. Your devices: every computer, phone and tablet where the mailbox is set up, plus anything that sends mail via SMTP (your website, a printer or scanner, accounting software).
5. What isn't mail: calendars and contacts. With Microsoft 365, Google and many other providers, these live in the same account, but they don't travel via IMAP. You move these separately.

If you only think about point 1, you'll discover after the move that invoice@ no longer forwards to the accountant, that the scanner can no longer send mail, or that the whole company's calendar is empty.

Step 1: the inventory

Start by making a list. A spreadsheet with one address per row works well:

Also fill in:

• The size of each mailbox. Your new mailbox needs to be big enough, with room to grow (lesson 3.2). A copy that stops halfway because the new mailbox is full is the most common reason a move stalls.
• Who uses POP3. With POP3, mail is often stored only on that one computer, no longer on the server (lesson 1.3). A copy taken from the server won't include that mail. You need to transfer it from within the mail program itself.
• What else sends mail. Website, webshop, scanner, till system, monitoring. Each of these has SMTP details that will change after the move.
• Special DNS records that your old provider has set for your mail, and records from other services (newsletter DKIM, verifications) that need to stay in place.

Tidy up as you go: addresses nobody uses any more don't need to be moved. And a move is a great moment to get rid of a catch-all.

Step 2: arranging access

To copy mail, a program needs to sign in to the old mailbox. With most providers, this works with the email address and password via IMAP. Two important exceptions:

• Gmail and Google Workspace don't let external programs sign in with your regular password. You create an app password, for which two-step verification must be switched on. In Google Workspace, the administrator may have turned this off.
• Outlook.com, Hotmail, Live and Microsoft 365 no longer accept a password for IMAP, not even an app password. You sign in with Microsoft (OAuth) and give a program temporary access. In a business environment, the administrator may need to give permission.

Can't remember the passwords? Reset them before the move, and write them down securely (a password manager, lesson 3.4).

Step 3: lowering the TTL of your MX in advance

The MX switch (lesson 8.2) is the moment new mail starts arriving somewhere else. Resolvers remember the old MX answer for as long as the TTL says (DNS course lesson 6.1). If it's set to a day, some senders will keep delivering to your old provider for a day.

So lower the TTL of your MX records a few days beforehand, for example to 300 seconds. Do this at least one old TTL before the switch: if the TTL is currently 86400 (one day), lower it at least a day in advance. After the move, set it back to a normal value, such as 3600.

If you're also moving your whole domain to another provider (switching nameservers), the TTL of the nameservers at the registry determines how fast this goes. You can't lower that one yourself; expect a transition period of a day or longer (DNS course lesson 6.3).

Step 4: the order

The order with the least risk:

1. Create the new mailboxes, aliases and forwards at the new provider, using the same names. Don't change anything in the DNS yet. The old mailboxes keep working as normal.
2. First copy of all mailboxes (lesson 8.2). This can take hours. Nobody notices anything.
3. Get the DNS ready: set up the SPF, DKIM and DMARC records for the new provider in advance, alongside the old ones where possible. Note: SPF needs to briefly contain both providers (one record, lesson 4.2). DKIM can run side by side, because each provider has its own selector.
4. Switch the MX at a quiet moment, for example on a Friday afternoon or evening. From this point on, new mail arrives at the new provider.
5. Second copy after a day, once the old TTL has definitely expired. This picks up the mail that still arrived at the old provider in the meantime. Messages that have already been copied are skipped.
6. Switch over the devices: new accounts in the mail programs, update the website and scanner, remove the old accounts (lesson 8.2).
7. Tidy up: remove the old provider from SPF, delete old DKIM records, set the TTL back to normal.
8. Only cancel the old mailbox once everything has been working well for a few weeks. Until then, you still have a complete copy there.

A common mistake is doing things in the wrong order: switching the MX or the domain first, and only then creating the mailboxes. Mail arriving in the meantime will then be rejected with 550 5.1.1 (address doesn't exist), and senders will get a bounce.

Calendar, contacts and local mail

Calendar and contacts travel via other protocols (CalDAV, CardDAV, or Microsoft's and Google's own integration). Export these separately before the move: an .ics file per calendar and a .vcf file for contacts, and import them at the new provider or into your new calendar program. Shared calendars and meeting invitations also need to be shared again.

Mail that only exists on the computer (POP3, or folders stored in Outlook as a .pst file on the computer) is transferred from within the mail program: add the new mailbox as an IMAP account and drag the folders across. Or export a .pst file and import it.

Let people know

Tell your users in advance what's going to happen: when the switch happens, that they need to set up a new account on their phone and laptop, and who they can call if something doesn't work. A simple set of instructions with the new settings (lesson 2.1) prevents a lot of questions.

In practice: what this looks like with a provider

At WebOké, you create the mailboxes in DirectAdmin or My WebOké, and copy the mail using the email move tool in My WebOké (which can also sign in with Microsoft) or with IMAPSync Migrations in DirectAdmin. Other providers have similar migration tools, or you use a standalone program. The steps above are the same everywhere.

Summary

• A move covers mailboxes, the addresses around them, DNS, devices, and calendar and contacts.
• Make an inventory with size, POP3 users, forwards and anything that sends mail via SMTP.
• Arrange access: an app password for Gmail, signing in with Microsoft for Outlook and Microsoft 365.
• Lower the TTL of your MX well in advance. Order: create accounts, first copy, get the DNS ready, switch MX, second copy, devices, tidy up, only then cancel.
• Calendars, contacts and locally stored mail don't travel via IMAP.

Quiz

Exercise

Exercise O8.1: Making a move plan. For your own domain (or for the example company in this lesson), create an inventory with the columns from the table above, and a timeline with dates for: lowering the TTL, creating mailboxes, first copy, switching MX, second copy, devices, tidying up, and cancelling. Also answer: who uses POP3, what sends mail via SMTP, and how will you move the calendar and contacts? You'll then receive a checklist with the points a good plan should cover.

Further reading

The steps in these articles apply to WebOké's control panels; other providers work in a similar way.

• DirectAdmin guide 10.1: Moving your email: your options
• WebOké manual 7.2: Migrating email to WebOké (including from Microsoft 365)
• Moving your domain, website and email together without downtime: the step-by-step plan
• Receiving email while moving your domain name
• Free DNS course 6.3: DNS during a transfer
• Free DNS course 6.1: TTL and cache