How to Move Email to a New Provider Without Losing Mail

You are moving your business email from one provider to another: from your web host’s mailboxes to Google Workspace or Microsoft 365, between those two, or away from either. The fear is simple: emails sent to you during the switch vanish, years of old messages are left behind, and on Monday morning half the team’s phones cannot connect.

A provider switch does not have to lose a single message. Mail is lost when the order of steps is wrong, when the old mailboxes are canceled too early, or when nobody checks the old server after the change. This guide gives you a plan, the cutover order, how to copy old mail, how to catch stragglers and how to confirm afterward that nothing is bouncing. It applies whatever the old and new providers are. Setting up the new provider’s records is covered in detail in the separate guides on setting up Google Workspace and Microsoft 365.

What is happening

Three separate things move during an email migration, and they move at different speeds.

What	Controlled by	How it changes
Where new mail is delivered	Your domain’s MX records	Gradually. Each sending server uses its cached copy of your MX record until the TTL expires, so for a while some mail goes to the old provider and some to the new one.
Old messages, folders, contacts and calendars	Stored on the old provider’s servers	Only when you copy them. Changing DNS moves nothing.
How people read and send mail	Settings in every phone, laptop, app and device	Only when each one is reconfigured.

The window when both providers receive mail is normal and harmless, as long as the old mailboxes still exist and someone collects what lands there. Mail is lost when the old mailboxes are deleted while senders still have the old MX cached, or when the old server bounces messages because the account was removed.

Authentication records move too. SPF, DKIM and DMARC must authorize the new provider before it starts sending, or your outgoing mail will land in spam during the very week you need it most.

Before you start

You need admin access to both the old and new email providers, login access to your DNS host (check with dig NS example.com +short), and a list of every mailbox with its current password or admin reset ability. Do not cancel the old service until the final step. Take an export of each mailbox if the old provider offers one, as a safety copy.

DNS checks run on your own computer: dig is built into macOS and Linux; on Windows use Resolve-DnsName in PowerShell or dig inside WSL. Migration tools run either in the new provider’s admin console or, for imapsync, on your computer or a server you control. If your website sends mail, WordPress checks run over SSH in the site folder that holds wp-config.php, using wp or wp-cli depending on the host.

Step 1: Inventory everything that uses email

Most migration surprises come from things nobody listed. Before setting a date, write down:

• Mailboxes: each address, who uses it and roughly how large it is.
• Aliases and forwarders: addresses that deliver into another mailbox, such as info@ or sales@. These must be recreated on the new provider, or mail to them will bounce.
• Groups, shared mailboxes and catch-all settings.
• Calendars and contacts: IMAP migration does not move these. Plan to export and import them separately.
• Devices and systems that send mail: the website, scanners and printers with scan to email, CRM, invoicing, booking systems, alarm panels, phones and laptops.
• Every sender in your SPF record, so you know what to keep when you edit it.

dig example.com MX +noall +answer
dig example.com TXT +short
dig _dmarc.example.com TXT +short

Run these on your computer and save the output. Replace example.com with your domain. +noall +answer shows only the answer lines, including the TTL in seconds after the name; +short shows only values. This is your record of the starting state and your rollback plan. Note the MX TTL: if it is 86400 (one day), you need to lower it at least a day before the switch.

Step 2: Prepare the new provider

Create the new account, verify the domain and create every mailbox, alias and group from your inventory. Use the same addresses. Do not change MX yet.

Set up authentication early

Edit your existing SPF record to include the new provider as well as the old one, for example v=spf1 include:OLD_PROVIDER_INCLUDE include:NEW_PROVIDER_INCLUDE ~all. Replace the placeholders with each provider’s documented include value. Both can send legitimately during the transition. Keep exactly one SPF record.

Publish the new provider’s DKIM record as soon as it lets you generate one, and keep the old provider’s DKIM record in place: DKIM records use different selectors, so they coexist. If your DMARC policy is p=quarantine or p=reject, make sure the new provider’s DKIM is signing with your domain before it sends real mail.

Lower the MX TTL

At least one old-TTL period before cutover, change the MX record’s TTL to 300 seconds without changing its value. Confirm with dig example.com MX +noall +answer: the number after your domain should show 300 or less on a fresh query.

Step 3: Copy existing mail before the switch

Copy the bulk of old mail while the old mailboxes are still receiving. Then after cutover you only need a small top-up (a delta) of messages that arrived in between.

Provider import tools

• Google Workspace: the data migration service in the Admin console (under Data, then Data import and export) can copy mail from IMAP providers using a CSV list of source and destination accounts, and can run a delta migration afterward.
• Microsoft 365: the Exchange admin center offers IMAP migration as a migration batch, using a CSV file with the columns EmailAddress, UserName and Password for the source accounts. Batches keep synchronizing until you complete them.
• From Google or Microsoft: both providers also have dedicated tools for migrating from each other. Check the destination provider’s documentation for the current options.

Provider tools need IMAP enabled on the old accounts. If the old accounts use two-step verification, you may need app passwords for the migration.

imapsync for full control

imapsync is a widely used open-source command-line tool that copies messages between any two IMAP servers and can be re-run safely, skipping messages already copied. Run it on your own computer or a server. Do a dry run first.

imapsync --host1 OLD_IMAP_HOST --user1 OLD_USERNAME --passfile1 OLD_PASSFILE \
         --host2 NEW_IMAP_HOST --user2 NEW_USERNAME --passfile2 NEW_PASSFILE \
         --automap --dry

OLD_IMAP_HOST and NEW_IMAP_HOST are the IMAP server names from each provider’s mail client settings page. OLD_USERNAME and NEW_USERNAME are usually the full email address. OLD_PASSFILE and NEW_PASSFILE are paths to text files containing only the password, which keeps passwords out of your shell history. --automap maps special folders such as Sent and Trash to their equivalents on the new server. --dry shows what would happen without copying. Good output ends with a summary of folders and messages found and no login errors. A login failure on host2 for Gmail or Microsoft 365 usually means the provider refuses plain passwords: Microsoft 365 requires OAuth for IMAP, and Gmail needs an app password or OAuth. imapsync supports OAuth access tokens; see its documentation. Remove --dry to run the real copy, and run it again after cutover to pick up new messages.

Calendars and contacts

Export calendars as iCalendar (.ics) files and contacts as vCard or CSV from the old provider, then import them into the new one. Shared calendars and meeting invitations usually need to be recreated.

Step 4: Cut over in the right order

Choose a quiet time, such as a Friday evening, when little mail is expected. Then follow this order.

1. Confirm the initial copy finished and every mailbox and alias exists at the new provider.
2. Delete the old MX records and add the new provider’s MX records in one sitting. Do not leave both sets in place, because senders will spread mail randomly between them.
3. Complete any “activate” step the new provider requires to start accepting mail.
4. Send test messages from outside accounts at two or three different providers to several of your addresses, including aliases.
5. Leave the old mailboxes fully active. Do not delete them or let the old provider’s account lapse.

dig example.com MX +short @8.8.8.8
dig example.com MX +short @1.1.1.1

Run these on your computer. @8.8.8.8 and @1.1.1.1 ask Google’s and Cloudflare’s public resolvers instead of your own, so you see what the wider internet sees. Good: both return only the new provider’s MX. Bad: one still shows the old MX after the old TTL has passed, which usually means the change was saved in the wrong DNS zone or a second nameserver has not updated. Check that every nameserver from dig NS returns the new record by querying each one with @ followed by its name.

Step 5: Catch mail during the overlap

For a while after the switch, some senders will still deliver to the old provider. Plan for it.

Check the old mailboxes

For at least several days, and longer if the old MX TTL was long, log in to the old webmail or keep the old account connected in a mail client and look for new messages. Then run a delta copy: the provider’s delta migration, or imapsync again without --dry, which only copies messages not already present.

Forwarding from the old provider

If the old provider supports forwarding, you can forward each old mailbox to the new one. Be careful: forwarding to the same address (you@example.com) can loop or deliver straight back to the old server if it still considers itself responsible for your domain. Forward instead to an address that routes only to the new provider, such as the user’s address on the new provider’s own domain (for Microsoft 365, the user’s onmicrosoft.com address). Check your new provider’s documentation for the equivalent. Forwarded messages can fail SPF at the new provider; that is acceptable for a short transition, but do not rely on forwarding long term.

Stop the web host delivering locally

If your old email was at your web host, its server may still deliver mail generated on that server (website form notifications, for example) to the old local mailboxes instead of following MX. In the hosting control panel, look for the email routing or mail exchanger setting and set it to remote, or turn off email for the domain. Then submit your website’s contact form and confirm it arrives at the new provider.

Step 6: Update SPF, DKIM and DMARC

Once the overlap is over and nothing sends from the old provider, tidy up the records.

• SPF: remove the old provider’s include. Keep the new provider and every other genuine sender. Stay under SPF’s ten DNS lookup limit.
• DKIM: confirm the new provider is signing with your domain, then delete the old provider’s DKIM record.
• DMARC: keep it. Watch the aggregate reports for a couple of weeks: they will show any system still sending through the old provider or failing authentication.

dig example.com TXT +short | grep spf1

Good: one SPF record with the new provider’s include and no old provider include. Bad: two SPF records, or an old include that remains after the old account is gone. Old includes can authorize servers you no longer control.

Step 7: Reconfigure devices and apps

This is the slowest part, so start it immediately after cutover.

• Phones and laptops: remove the old account and add the new one. Editing server names in an existing account often leaves cached settings behind. Tell users to expect it.
• Outlook: for Microsoft 365, autodiscover does most of the work if its record points at Microsoft (see the Microsoft 365 setup guide). A stale autodiscover record pointing at your old host is a classic cause of repeated password prompts.
• The website: update the SMTP plugin’s server, port, username and password or OAuth connection. Send a test from the plugin’s test screen or over SSH:

wp eval 'var_dump( wp_mail( "YOUR_TEST_ADDRESS", "Post-migration test", "Website mail after the provider switch." ) );'

Run this over SSH in the site folder. Replace YOUR_TEST_ADDRESS with an outside mailbox you can check. bool(true) means WordPress handed the message to the mailer; confirm it arrives and passes authentication. bool(false) means it failed locally, and your SMTP plugin’s log will show why. The separate guide on WordPress not sending email covers SMTP fixes.

• Everything else: scanners, CRMs, invoicing and booking tools, and any service that sends as your domain or logs in to a mailbox. Work through your Step 1 inventory and check each one off.

Step 8: Check for bounces and close the old account

For two weeks after cutover, actively look for failures.

• Ask staff to forward any bounce message they receive and any customer complaint about undelivered mail.
• Check the new provider’s admin logs or message trace for rejected inbound mail.
• Check the old mailboxes one last time and run a final delta copy.
• Send tests to every alias and group address from an outside account.
• Read the DMARC aggregate reports for unknown sources or failures.

Bounce messages contain a status code that tells you exactly what went wrong, such as 550 5.1.1 for an address that does not exist on the new provider (usually a missing alias). The separate guide on bounce codes explains how to read them. Only when the old mailboxes have received nothing for a sustained period, and you have a final export of each, cancel the old service. Keep the exported copies for as long as your record-keeping rules require.

Advanced: staged migrations and testing before DNS changes

For larger moves or anxious clients, you can test the new provider fully before touching MX.

• Test delivery without DNS: send mail directly to the new provider’s routing address for a mailbox (such as its onmicrosoft.com address) to confirm mailboxes, aliases and rules work before cutover.
• Test sending authentication: send from the new provider to an outside Gmail account before cutover and check Show original for SPF, DKIM and DMARC PASS. Fix this before MX moves, not after.
• Staged mailbox moves: some providers support coexistence, where some users stay on the old system while others move, with mail routed between them. This needs careful routing rules and is usually only worth it for large organizations.
• Measure the copy: compare message counts per folder between old and new. imapsync’s final summary lists messages found on each host and any errors; a folder with far fewer messages on the destination deserves another pass.
• Rollback plan: because you lowered the TTL and kept the old mailboxes, rolling back is as simple as restoring the saved MX records. Keep that option until the overlap period ends.

When to contact your host

Contact the relevant provider’s support for admin console or migration tool errors. Open a ticket with your web or DNS host when:

• DNS changes are not showing on all nameservers after the TTL has passed;
• the web server keeps delivering website mail to old local mailboxes;
• you need an export of old mailboxes or confirmation of when they will be removed.

Send your domain, the saved before and after dig output, the exact time of the MX change in UTC, the full headers or bounce text of any failed message, and the list of addresses affected. The diagnostic tools page links DNS and header checkers, and if mail has stopped completely, go to the Emergency Room.