A red postbox set into the gable of a golden stone cottage with a tiled roof and chimneys, along a wet lane of houses under grey mist.
Business Email

Email Migration Step by Step

Moving mailboxes between providers is a sequence, not a switch. This is email migration step by step: the order the stages go in, what to prove between them, and the one step that cannot be taken back.

Move My Email to My Domain Get help choosing

Three separate moves, not one

This page assumes the decision is made; the business email overview covers the choice. A migration is three jobs people describe as one, and keeping them apart is what makes it safe:

  • The mailboxes and their history. A sync copies messages and folders and stops there. Calendars, contacts, distribution lists and shared-mailbox permissions are left behind, so they get exported and rebuilt separately.
  • The addresses themselves. Every mailbox, alias, forwarder and shared address has to be created again. Nothing carries over on its own.
  • The MX records. The DNS entries that tell sending servers where to deliver. Until they change, mail keeps arriving at the old service whatever you have built at the new one.

That gap, where the new mailboxes are ready but nothing yet points at them, is where a safe migration lives. It needs somebody who can edit the domain's DNS records.

The inventory, which is where migrations are won

Migrations go wrong because something was not on the list. Build it from the old provider rather than from memory, and note who reads each address:

  • Export or screenshot the mailbox list from the current control panel.
  • Open the alias and forwarding screens separately. They are rarely on the mailbox page, which is why they get missed.
  • Check whether a catch-all is on, because it is delivering mail to addresses nobody created.
  • Look at what your own systems send to. Contact forms, booking software and the registrar all mail an address somebody chose years ago.
  • Work out which outside logins send password resets and two-factor codes to one of these addresses. The registrar, the bank, the card processor and the Google Business Profile usually do, and a mailbox that stops receiving locks the owner out of all of them. Mark those and prove them first.
What is on the domain now, and what has to exist afterwards
On the old service What it actually is What has to happen
Mailbox A login that holds messages Create it, then copy the history in
Alias An extra address into a mailbox Create it, no history to copy
Forwarder Mail passed straight through elsewhere Recreate it, confirm the destination works
Catch-all Anything not otherwise addressed Recreate it, or turn it off deliberately

Email migration step by step, and why the order matters

One rule prevents almost every disaster: create the new mailboxes and copy the mail before the MX records change, never after. Backwards, mail arrives at an empty mailbox while the history sits behind a login somebody is about to cancel.

  1. Lower the TTL on the mail records

    A day or two ahead, drop the TTL on the MX records to the lowest value the panel allows. TTL is how long other servers may keep the old answer.

  2. Create every address at the new provider

    Work down the inventory: mailboxes, then aliases, forwarders and the catch-all. Match the spelling exactly. Nothing is live yet, because nothing points here.

  3. Copy the mail while the old service still runs

    The sync reads the old mailboxes and writes into the new ones while the old service keeps receiving. Not downtime, whatever the volume.

  4. Update SPF and DKIM to match the new sender

    Before the MX change or alongside it, not a week later.

  5. Change the MX records

    Save the existing record set as text first, so it can be put back exactly. Then edit the MX entries only: not the A or CNAME record pointing the website at its server, and not the verification TXT records a card processor or a search console left there to prove you own the domain. Read the new values back.

  6. Sweep for stragglers

    Run the sync again a day or two later, for anything that landed in the old mailbox during the changeover.

  7. Reconnect the devices

    Phones and desktop mail apps, one person at a time. This takes longer than everything above it.

  8. Verify, then leave the old service alone

    Test properly, then let the old account sit paid up for a couple of weeks before anybody cancels anything.

Moving the website at the same time is rarely wise. Move the mail, prove it, then treat moving the site separately.

The cutover window, and the stragglers

A window follows the change in which mail is split between the two providers rather than lost, as the business email overview explains. What it leaves you is a decision about the stragglers:

  • Sync again once the window has closed. Most tools bring across only what is new, so a second pass is cheap.
  • Forward the old mailbox to the new address instead, in one direction only. Point each at the other and you have a loop that fills both accounts and gets the domain throttled.

Either way, read both mailboxes daily until nothing new turns up in the old one. That, not a date on a calendar, tells you the window has closed.

What a wrong MX value looks like from the outside

It shows you no error, because the bounce goes to the sender. The first hard evidence is usually a customer forwarding the screenshot, and the useful part is the line quoted from the server that refused delivery:

  • Host or domain name not found, or a 550 saying the recipient domain could not be found, means the record points at a hostname that does not exist. One mistyped character reads like this.
  • Relay access denied means it points at a real mail server that has never been told about your domain, so either the MX went somewhere it should not or nothing was created there.
  • Connection timed out, arriving as a delayed notice rather than an outright failure, means nothing is answering. The sending server retries before giving up, so it reaches the customer long after the change.

Cut over in a quiet stretch, with somebody who understands the change around the next morning.

SPF, DKIM and DMARC have to describe the new sender

This is the forgotten step, and it is why mail lands in spam after an otherwise clean move. These three records tell receiving servers who may send as your domain, and yours still name the old provider.

  • SPF lists who may send as you. Swap the old provider's entry for the new one, and keep a single SPF record: a second is not additive, it breaks the first.
  • DKIM signs your outgoing mail, and does nothing until the records the new provider gives you are published.
  • DMARC tells receivers what to do when a message fails the other two. If a record exists, leave it until the new sender is verified.

Everything else that sends as your domain belongs in SPF too: the contact form, the newsletter tool, the invoicing software.

Reconnecting phones and desktop clients

Server settings are the easy half. Devices and people generate the calls, so have the new server names, ports and username format written down before you start:

  • Add the new account and confirm it works, then remove the old one. Deleting first turns a five minute job into an incident.
  • Warn people that removing an old account from a phone removes the mail it downloaded. Harmless once the history is copied, alarming if unexpected.
  • Check saved passwords: a phone retrying an old one can lock the account.

What to check in the first hour

  • Send from outside to every address on the inventory, aliases included. Testing one mailbox proves one mailbox.
  • Reply from each mailbox and confirm it arrives outside.
  • Check the spam folder at the far end. Arriving is not arriving in the inbox.
  • Send a test through the website's contact form.
  • Compare folder counts with the old mailbox, and open the oldest message.
  • Trigger a password reset on one account that sends its code to an address here, and confirm it turns up.

Three failures that account for most lost mail

  • The mail records were rebuilt from a support article rather than edited, dropping an entry or mistyping a hostname.
  • An alias nobody knew about was never on the inventory, so it was never recreated: a former owner's address still forwarding to the bookkeeper, or a sales@ pointing at somebody's personal account.
  • An address turned out to be a login. The registrar and the card processor sent reset codes to a mailbox that had stopped receiving, and it came to light while somebody was trying to get in.

None of the three announces itself. That is why you test every address.

How AldoMedia runs a move

We build the inventory out of your control panel with you on the call, so the forwarders nobody remembers are written down before a mailbox is created, and the MX change is made at a time you pick rather than whenever the copy finishes. AldoMedia, LLC has been building websites for Western New York businesses since 1999, and is an independent authorised reseller rather than the platform operator, so you get a Buffalo phone number.

Move My Email to My Domain Tell us what you use now

Call 716-771-2536, or read the support page for what to have ready.

Email migration questions

Do I have to move my domain to change email providers?

No. The registration stays where it is. What you need is the ability to edit the domain's DNS records, because those decide where mail is delivered. If nobody at the business can reach that panel, sort that out first.

How do I confirm the MX change actually took effect?

Look the domain's MX records up yourself and read the hostnames back against the ones the new provider gave you. Do not judge it by whether a test message arrived: that message may have travelled on a cached answer to the old provider.

Why did my email start going to spam after the move?

Almost always because SPF and DKIM still describe the old provider. Receiving servers check whether the system sending as your domain is authorised to. Update those records, and keep every other system that sends as you in the SPF list.

Can I still copy old mail after the MX records have changed?

Usually yes, as long as the old mailbox still exists and you have its password. Once the account is deleted the history goes with it, and no provider can get it back for you.

How long does an email migration take?

The copy runs while the old service still works, so its length is not downtime. What your staff feel is the reconnecting.

Related guides and services

Business Email

Mailbox hosting or Microsoft 365, and who should own the account.

Read the email guide

Hero photograph: Arriva436, CC BY 3.0, via Wikimedia Commons. Cropped.

Have somebody else run the cutover

Send us the list of addresses and where they are now. We will tell you what the move involves and what your staff do.

Move My Email to My Domain Plan a migration