Changing email hosting providers: the complete checklist

Changing email hosts, for example from a web hosting control panel to Microsoft 365 or Google Workspace, is more than an MX change. Mailboxes, old mail, authentication records, phones and apps all have to move with it. This checklist covers the whole move and links to our detailed guides for the MX cutover itself and DNS TTL and propagation.

What does changing email hosting providers involve?

Changing email hosting providers means moving your domain's mailboxes, stored mail and mail-related DNS records from one service to another, then retiring the old one. The MX change that redirects new mail takes minutes. The surrounding work takes days, and it's where most problems start.

The move has eight workstreams. Treat each one as its own checklist item.

What should you inventory before you move?

Inventory everything that receives, stores or sends mail for your domain before you touch DNS. Anything missing from the list is what breaks on cutover day.

1. Mailboxes. Every user, with mailbox size. Large mailboxes take longest to copy.
2. Shared and role addresses. info@, accounts@, support@, and how each one is delivered today (shared mailbox, alias, forwarder or group).
3. Aliases and distribution lists. Note the members, and who outside the company can send to each list.
4. Forwarders and catch-alls. Many web hosts make these easy to set and easy to forget. Decide whether each still needs to exist. See catch-all addresses and spam.
5. Apps and devices that send as your domain. Copiers, website contact forms, accounting software and CRMs. Note how each one sends: via the old host's SMTP server, or via its own service.
6. Current DNS records. Copy the exact MX, SPF, DKIM selectors, DMARC, autodiscover and any _mta-sts records. This is your rollback plan.
7. Security settings to rebuild. Allow and block lists, forwarding restrictions, MFA, admin accounts. They don't migrate with the mail.
8. Retention needs. Find out how long you must keep old mail, and whether the old host must export it before you cancel.

How do you migrate mailbox data?

You migrate mailbox data with the new host's migration tool, a third-party tool, or user imports, after creating the accounts at the new host. Changing MX moves no old mail, so copy it in advance and repeat a final "delta" sync after cutover to catch anything that arrived at the old host during the overlap.

Know what your method leaves behind:

• Microsoft 365 from an IMAP host. Microsoft's migration overview says "only the items in the users' inbox or other mail folders are migrated. Contacts, calendar items, and tasks can't be migrated with IMAP." IMAP migration "also doesn't create mailboxes", so create users first.
• Microsoft 365 from Exchange Server. A cutover migration can move up to 2,000 mailboxes, but Microsoft says "it's more reasonable to migrate 150 users or less" that way. Larger moves use staged or hybrid migration.
• Google Workspace from an IMAP host. A super administrator runs the import from Menu > Data > Data import & export > Data import in the Admin console, and IMAP must be turned on for both accounts. Google's help page says to "run a delta import to import data that was added to the IMAP account after the import" (Google Workspace Admin Help, at the time of writing in October 2026).

Start the bulk copy several days before cutover. Then the post-cutover sync only has a few days of mail to move.

Which DNS records change, and in what order?

The safe order is: verify the domain, add sending authentication, update MTA-STS if you use it, switch MX, update autodiscover, then clean up. The table shows each record with an example value. Use the exact values your new host gives you.

SPF: one record, both hosts during the overlap

During the move, people may send from both the old and new host, so the SPF record must list both. Edit the existing record; don't publish a second one. RFC 7208 treats two SPF records as a permanent error, and Microsoft's DNS reference shows a merged record as correct and two separate records as incorrect. Watch the 10-lookup limit when you add an include; our SPF Checker counts lookups. Provider-specific values are on the SPF records by provider pages.

DKIM: new keys at the new host

DKIM keys belong to the sending service, so the new host generates its own selectors and keys. Publish them and turn on signing before users start sending from the new host, or mail will reach recipients unsigned and depend on SPF alone for DMARC. Setup steps for common hosts are on our DKIM by provider pages. Leave the old host's selector in place until it has stopped sending, then remove it.

Your DMARC record itself usually doesn't change. Do watch your DMARC reports in the first week: the new host should appear as a passing source, and anything still sending through the old host will show up too.

MTA-STS: update the policy before MX

MTA-STS lets your domain tell senders to require encrypted (TLS) delivery to a listed set of MX hosts. If you publish it, your policy file's mx: lines name the old host. A sender enforcing the policy checks that "at least one of the policy's 'mx' patterns matches the selected MX host" (RFC 8461, section 4), so a new MX that isn't listed can fail delivery for senders that enforce it.

Before the MX change, add the new host's MX pattern to the policy file, then change the id value in the _mta-sts TXT record so senders know the policy changed. RFC 8461 section 8.1 says to update the HTTPS policy before the TXT record. Remove the old pattern after cutover. The MTA-STS Checker shows what senders currently see, and our MTA-STS guide explains testing mode.

What if a spam filter sits in front of your mailboxes?

If your MX records point to a separate filtering service, you don't change MX at all when you change email hosts. Instead, you change where the filter delivers clean mail, and set up the new host to accept mail from the filter.

That makes the move simpler, because the internet keeps sending to the same MX:

1. Set up the new host's trust for the filter before cutover: an inbound connector with Enhanced Filtering in Microsoft 365, or an inbound gateway in Google Workspace. Our guides for Microsoft 365 and Google Workspace cover each screen.
2. At cutover, change the filter's delivery destination from the old host to the new one.
3. Mail queued at the filter while you switch is retried; a filter with outage spooling holds it until the new destination accepts it.
4. Afterward, block direct delivery to the new host so mail can't go around the filter. See block direct-to-tenant bypass.

If you're replacing the filter at the same time, do it as a separate step. Switching spam filter providers covers that overlap. Changing two things at once makes any problem harder to trace.

What does the cutover-day checklist look like?

On cutover day, change routing, confirm both directions work, and reconnect people's devices. Lower the MX TTL at least a day ahead, as described in our TTL guide.

1. Confirm the new host is ready. Every user exists, the bulk copy is complete, and a test message sent to the new host's internal address arrives.
2. Change MX (or the filter's delivery destination) in one edit. The MX cutover guide covers verification and rollback.
3. Update autodiscover if you're moving to Microsoft 365, so Outlook can find the new mailboxes. Microsoft lists autodiscover.outlook.com as the target.
4. Test inbound from two or three outside providers, and read the headers in the Email Header Analyzer.
5. Test outbound to an outside mailbox and check that SPF, DKIM and DMARC all pass. Our guide on checking authentication results shows where to look.
6. Reconnect clients. Remove the old account from Outlook and phones, then add the new one. Old IMAP profiles keep pointing at the old host and quietly show stale mail.
7. Repoint apps and devices that sent through the old host's SMTP server. See scan-to-email with Microsoft 365 for copiers.
8. Run the delta sync once the old host's inbound mail has slowed to a trickle.

What should you do after the move?

After cutover, keep the old host running, watch for stragglers, and remove old records only when they're no longer used. Senders that deferred mail before the change retry for days. RFC 5321 says the give-up time "generally needs to be at least 4-5 days", and some may still reach the old host if they cached the old MX.

1. Days 1 to 7: check the old host for new mail daily and run delta syncs. Ask users to report anything missing.
2. Week 1: rebuild security settings at the new host: MFA, forwarding restrictions, allow and block lists, admin accounts. Review DMARC reports for unexpected senders.
3. Weeks 2 to 4: once the old host receives nothing, remove its SPF include and DKIM selector, restore normal TTLs, and remove old MTA-STS patterns.
4. Before cancelling: export any mail you must retain, confirm the final sync, and remove forwarders on the old host so it doesn't keep relaying stray mail.
5. Cancel the old account last, and only then remove its records entirely.

What are the most common mistakes?

• Cancelling the old host too early. Late retries bounce and the last few days of mail are never synced.
• Two SPF records. Adding a new record instead of editing the existing one breaks SPF for both hosts. See multiple SPF records.
• Forgetting DKIM. The new host sends unsigned mail, and DMARC depends on SPF alone.
• Stale MTA-STS policy. Enforcing senders refuse the new MX.
• Forgotten senders. The copier and the website form still point at the old SMTP server.
• Old phone profiles. Users keep reading the old mailbox and miss new mail.

Next steps

• Copy your current MX, SPF, DKIM, DMARC and MTA-STS records today with the Email Health Check, and keep them as your rollback plan.
• Build the inventory above before you book a cutover date.
• Follow the MX cutover guide on the day itself.
• If you're adding filtering as part of the move, the guided migration plan shows the order of steps, and iBlockSpam's domain monitoring alerts you if MX, SPF or DMARC records change unexpectedly afterward.