You can move business email to a new provider without downtime if you build the new mailboxes first, copy the old mail across, and only then change the DNS records that tell the world where to deliver. The horror stories come from flipping MX first and sorting the rest afterwards. Done in that order, nobody has to miss a message.
“No downtime” is not magic and it is not a myth. Mail is public records, mailboxes and every phone already logged in. Change the records after the mailboxes exist, and the gap is minutes, not a lost Monday.
Why do email moves go wrong?
Email feels simple until you move it. Behind the scenes it depends on DNS (where mail should go), on mailboxes that may hold years of history, and on every device that already knows the old password.
Change those parts in the wrong order and mail can bounce, sit in two places, or vanish from a phone that still thinks it is on the old server. The usual cause is rushing the DNS change: people point MX at Microsoft 365 immediately, then discover info@ was forgotten and last year’s invoices are still on the old host.
The second cause is skipping authentication. New mailboxes without SPF, DKIM and DMARC often “work” for you and land in junk for the customer. The third is closing the old account the same afternoon. Keep it read-only for a week.
If you are also choosing a suite, whether you need Microsoft 365 is the plan conversation. This post is the move, not the brand.
What is the safe order so nobody misses a message?
Follow this sequence. The live mail keeps working until the last step.
1. List what you actually have. Every mailbox, every shared address (info@, accounts@), every phone, and any system that sends as you: a website form, a shop, a booking tool. Note where the domain is registered and where DNS is edited. Those are often different companies.
2. Create the new mailboxes first. Build every account on the new provider while the old email carries on. Log in, send a test, fix the names. If info@ does not exist yet, this is when you notice.
3. Copy the old mail across. Move messages, folders and contacts before you touch DNS. The moment you switch, history should already be there. Switching first and copying later is how people “lose” mail that is still on the old server.
4. Lower the TTL a day or two before. TTL is how long other systems remember your old mail records. Lower it so the switch propagates quickly. This is the step most DIY moves skip.
5. Change MX, SPF, DKIM and DMARC once, when the rest is ready. Only now point delivery at the new host and publish the new authentication. Because the boxes and the history exist, new mail arrives somewhere people can already open.
6. Reconnect devices and keep the old host for a short while. Update phones and Outlook. Send tests out, including to Gmail. Leave the old mailboxes read-only until you are bored of checking them.
If the website form still sends through the old host, update that in the same cutover or new enquiries will fail SPF.
What do MX, SPF, DKIM and DMARC actually do?
Plain English, because the acronyms make people skip the job.
MX tells the internet where to deliver mail for your domain. Think of it as the forwarding address on the door. Change it when the new office is furnished, not while the desks are still on the van.
SPF is a public list of servers allowed to send as @yourbusiness.co.uk. After a move, that list must name the new provider. If a website form still sends from the old server, list both or one will fail.
DKIM is a signature on each outbound message. The new provider gives you a record to publish. Until you do, some receivers treat you as unverified.
DMARC says what to do when SPF or DKIM fail, and it lets you see reports of spoofing. Start with a monitoring policy if you are unsure, then tighten it once mail is clean.
The email DNS checker looks up those records and explains the gaps. Run it before the move and again after. These records are why a quote you sent at 9am sits in junk, or why a fake invoice from your domain looks real.
Is “no downtime” a myth?
The myth is that email either stays up perfectly or goes down for a day. Reality is quieter.
If you change MX before mailboxes exist, senders get bounces. That is avoidable.
If you change MX after everything is ready, and you lowered TTL, a few late messages may still hit the old host because some systems cached the old MX. That is why you keep the old mailbox open and copy history first. People who have not updated their phone think email is down when the app is simply pointing at the wrong place.
If you skip SPF, DKIM and DMARC, mail is “up” and still fails. Customers do not get the message. That is not a server outage. It is a delivery failure you caused.
No downtime is a planning claim: no gap in collection, no bounced senders, no day of chaos. It does not mean every device updates itself. Budget an hour for phones. Prefer a Tuesday morning over a Friday afternoon.
Should you do the move yourself?
One mailbox, a domain you already control, and a quiet week: reasonable DIY if you can edit DNS and you follow the order above.
Several people, shared inboxes, a shop that sends receipts, and a domain login in a drawer: pay someone who has done it before. The bill for a clean project is smaller than a day of lost quotes.
Page Forge will plan and run that as a one-off. We are not a managed IT provider and we do not run a helpdesk after handover. Business email is listed on the pricing page from £10 a month plus setup. I will not invent other IT prices around that.
If mail is already messy (Gmail here, an old host there, a website form on a third), say so at the start. Pretending it is a simple MX change is how those jobs blow up.
Frequently asked questions
Will I lose old emails when I switch?
Not if you copy them first. Move messages, folders and contacts to the new mailboxes before you change MX. Losing history almost always means switching first and migrating later.
How long does a small-business email move take?
Preparation is usually a day or two. The DNS switch itself is short if you lowered TTL. Devices take another hour. The calendar time is mostly waiting and checking, not a full weekend of work.
What are MX, SPF and DKIM records?
MX says where to deliver mail. SPF lists who may send as you. DKIM signs the messages. DMARC says what to do when those checks fail. All of them need to match the new provider after you move.
Will people stop getting my mail for a day?
Not if the mailboxes exist, history is copied, and you change DNS last. A few late messages may still hit the old host. That is why you leave it open briefly. A full day of silence usually means the order was reversed.
Can I move just one person and leave the rest?
You can, but it is awkward, because MX is per domain, not per person. Split domains or dual delivery are possible and they are easier to get wrong. For a small firm, moving everyone in one planned cutover is cleaner.
Do I need to change my email address?
No. That is the benefit of a domain address. jane@yourbusiness.co.uk stays the same. Only the engine behind it changes. If you are still on Gmail, this move is also the moment to stop using the Gmail as the public address.
If you want the move run as a project, get in touch with a list of mailboxes and where the domain is registered. That list is more useful than a screenshot of the new login screen.