Changing web hosts is stressful enough without discovering on cutover day that nobody at the office can send mail. Website DNS and email DNS are related but not the same problem. You can move the site on Tuesday and leave email on the old provider until Friday, or you can do both at once and hope you remembered every MX record.
Here is a practical order of operations we use when Canadian clients migrate hosting but want to keep (or move) business email without a black hole.
Decide where email lives after the move
Before you touch the website, answer one question: is email staying put, moving with the site, or moving to a dedicated provider (Google Workspace, Microsoft 365, etc.)?
- Staying on old host temporarily — common when only the website moves first
- Moving to new host's mail server — cPanel mail, Plesk, or VPS mail stack
- Moving to external email — M365/Google while website goes to Swift Host
Each path has different DNS steps. Mixing them up is how you lose a week of inbound mail.
What to export before anything changes
- Mailbox contents (IMAP export or PST if you must)
- List of addresses and aliases
- Forwarders and catch-alls
- Autoresponders and filters if your team relies on them
- Current MX, SPF, DKIM, and DMARC records (screenshot or zone file)
If you skip the DNS snapshot, you will guess at SPF when the new host asks for it.
Lowering TTL before cutover
A few days before you change MX or A records, lower TTL on those records to 300–600 seconds (5–10 minutes). DNS caches the old answers. High TTL means some users hit old servers for a day or more after you think you switched.
Website A/CNAME records benefit from the same treatment if you are moving the public site.
If email stays on the old host while the website moves
This is the safest split migration:
- Point the website A/CNAME to the new host (or put the site live on staging URL first, then cut over)
- Leave MX records pointing at the old mail server
- Verify old host still accepts mail for your domain (some hosts tie mail to hosting account status)
- Move mailboxes later on a planned window
Your site loads from Canada (or wherever the new host is) while mail still flows to the old infrastructure. Clients notice the faster website, not an email outage.
If email moves with the website
- Create mailboxes on the new server and test send/receive with a test address
- Set SPF, DKIM, and DMARC on the new stack before you switch MX
- Sync or import old mail via IMAP migration tool
- Change MX to the new host during a low-traffic window
- Keep old mail server running read-only for a few days in case stragglers deliver late
Send a test from Gmail and Outlook to your domain after MX propagates. Inbound and outbound both.
If email moves to Google or Microsoft
Website on Swift Host, mail on M365/Google is a common setup. MX points to Google/Microsoft, not your web server. The website only needs correct SPF includes (and often no mail ports open on the web VPS at all).
Do not delete old MX until the new provider's verification is complete and you have tested webmail or Outlook/mobile sync.
SPF, DKIM, DMARC during migration
Changing MX without updating SPF is a deliverability trap. SPF says which servers may send as your domain. If the new mail path is not in SPF, outbound mail from the new stack may land in spam.
DKIM signing keys change when you change mail platforms. Update DNS TXT records the new provider gives you. DMARC can wait until SPF and DKIM validate, but plan it if you send bulk or transactional mail.
Our email deliverability guide covers shared vs dedicated sending if you outgrow basic cPanel mail.
What breaks if you rush
- MX still pointing at cancelled hosting → mail bounces
- Website on new host, mail autodiscover still on old → phones stop syncing
- Copied zone file without updating SPF → outbound spam folder
- Deleting old mailboxes before IMAP sync finishes → lost archives
None of this is exotic. It is what happens when DNS and mail are treated as an afterthought to "move the WordPress files."
Bottom line
Plan email as its own migration with its own checklist. Lower TTL early, snapshot DNS, test before MX cutover, and keep the old path alive until you are sure inbound and outbound work.
Moving hosts and want email handled cleanly? Talk with Swift Host. We coordinate website cutover and mail DNS so your team is not re-adding accounts on phones at midnight.
