Migrating business email means changing MX, SPF, DKIM and DMARC records in DNS — never the nameservers. Lower the TTL 24-48 hours ahead, create and test mailboxes on the new provider first, switch the MX record last, then keep the old provider live for 7-14 days to catch mail still arriving at the stale record.
Key takeaways
- Only email-specific DNS records change. MX, SPF, DKIM and DMARC live in your existing DNS zone — changing nameservers is a separate, bigger, unnecessary move that risks your website's own records.
- TTL is the step people skip and regret. Lowering it 24-48 hours before cutover is what turns a day-long propagation wait into a few minutes.
- The new mailboxes exist before the switch, not after. Creating and test-sending from the new provider first means the cutover is a single MX change, not a scramble to set up accounts while mail is already failing.
- The old provider stays live during overlap. DNS propagation isn't instant or uniform — some senders keep hitting the old MX record for days after the switch.
- Spam-folder landings after a migration are almost always an SPF or DKIM gap, not a reputation problem with the new provider.
Before touching any DNS record
The work that actually prevents lost mail happens before the cutover, not during it. Skipping straight to changing the MX record is the single most common way this goes wrong.
| Step | Why it matters |
|---|---|
| Inventory every mailbox and alias | Forwarding rules, shared mailboxes and catch-all aliases are easy to forget and don't migrate themselves |
| Snapshot current MX, SPF, DKIM, DMARC records | You need a rollback reference if anything breaks mid-cutover |
| Lower DNS TTL to ~300 seconds | Done 24-48 hours ahead, this is what makes the actual MX change propagate in minutes, not up to a day |
| Create and test mailboxes on the new provider | Confirms the new side actually works before you depend on it exclusively |
The cutover itself
With the new mailboxes created and tested, and the TTL already lowered, the cutover is a small number of DNS changes, made in a specific order — not a provider-side "migrate" button in most cases.
- Point the MX record to the new provider. This is the one change that actually redirects where new incoming mail goes.
- Add the new provider's SPF include to your existing SPF record — don't replace it outright if you're still sending from the old provider during overlap; merge both.
- Add and verify the new provider's DKIM key. Outgoing mail from the new provider will fail authentication at the receiving end without this, and that failure often looks like spam-folder placement rather than an obvious error.
- Leave DMARC alone until both SPF and DKIM pass for the new provider — tightening DMARC policy before authentication is confirmed working can cause legitimate mail to be rejected outright.
A migration that goes wrong almost never fails at the MX record itself — it fails at SPF or DKIM, because those are the two records a receiving mail server checks to decide whether a message claiming your domain is actually authorized.
The overlap window and what to verify
DNS propagation is not a single moment — different resolvers around the internet pick up a changed record at different times, bounded by the TTL you set. Some mail sent to you in the hours or days after the switch may still arrive at the old provider.
Bar length = recommended duration, scaled to the 14-day overlap window.
When checking that nothing was lost, compare per-folder item counts between the old and new mailbox — not total storage size, which can match even when individual messages or whole folders failed to transfer, since attachments and message sizes vary.
Documented vs. inferred vs. unsupported
| Claim | Status | Basis |
|---|---|---|
| Email migration only requires changing MX/SPF/DKIM/DMARC, not nameservers | Documented | Consistent across every major provider's own migration documentation |
| Lowering TTL 24-48 hours ahead meaningfully speeds propagation | Documented | Follows directly from how DNS caching and TTL values work |
| A 7-14 day overlap window is sufficient to catch stale-record mail | Inferred | A commonly recommended range in provider migration guides — actual propagation tail depends on which resolvers cached the old record and for how long |
| Spam-folder placement after migration is always an SPF/DKIM problem | Unsupported | It's the most common cause but not the only one — sender reputation on a fresh IP range and recipient-side filtering rules can also contribute |
Who this sequence is for
- Moving to or from Hostinger, Zoho or Google Workspace: the sequence is identical — see the cost comparison for what each actually charges per mailbox.
- Already comfortable with DNS: the whole cutover is a 20-30 minute task spread across a 1-2 week overlap window, not continuous work.
- Managing this for a client or employer: do the pre-migration inventory and TTL step with extra lead time — this is where a rushed migration actually loses mail.