Business Email
Mailbox hosting or Microsoft 365, and who should own the account.
Read the email guide
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.
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:
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.
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:
| 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 |
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.
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.
Work down the inventory: mailboxes, then aliases, forwarders and the catch-all. Match the spelling exactly. Nothing is live yet, because nothing points here.
The sync reads the old mailboxes and writes into the new ones while the old service keeps receiving. Not downtime, whatever the volume.
Before the MX change or alongside it, not a week later.
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.
Run the sync again a day or two later, for anything that landed in the old mailbox during the changeover.
Phones and desktop mail apps, one person at a time. This takes longer than everything above it.
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.
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:
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.
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:
Cut over in a quiet stretch, with somebody who understands the change around the next morning.
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.
Everything else that sends as your domain belongs in SPF too: the contact form, the newsletter tool, the invoicing software.
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:
None of the three announces itself. That is why you test every address.
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.
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.
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.
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.
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.
The copy runs while the old service still works, so its length is not downtime. What your staff feel is the reconnecting.
Mailbox hosting or Microsoft 365, and who should own the account.
Read the email guideWhat the MX and TXT records do, and how to change one safely.
Understand your recordsWhere the destination is the suite, not plain mailboxes.
See what it includesHero photograph: Arriva436, CC BY 3.0, via Wikimedia Commons. Cropped.
Send us the list of addresses and where they are now. We will tell you what the move involves and what your staff do.