How to Transfer Email to Another Provider Without Losing Messages

First, check the scope: this process is for an address on a domain you control, such as you@example.com. It cannot turn an address owned by a provider, such as you@gmail.com, into the same address at a competing service.

Before you start: know what actually moves

Your email address looks like one thing, but a provider transfer has four separate parts:

Part	What it controls	How it moves
Domain and address	The part after and before the @ sign	You keep the domain and recreate the same address at the destination
Incoming routing	Where other servers deliver new messages	Change the domain’s MX records
Stored mailbox	Existing messages and folders	Copy them with a provider migration tool, IMAP, or an export/import method
Mail apps	How Outlook, Apple Mail, Thunderbird, or a phone connects	Replace the old IMAP and SMTP settings with the new ones

This separation explains the safest order: prepare the destination, copy the old mailbox, change routing, run a final sync, and then retire the old account. During the transition, it is normal to have both the old and new mailbox available.

The screenshots below use cPanel and GoDaddy as examples. Your provider may label the same controls differently, so use the exact record values and connection settings shown in its current setup wizard.

1. Inventory the old setup and plan the transfer

Do not start with DNS. First, make a list of everything the old provider handles:

• Every mailbox and its storage use
• Aliases, distribution groups, shared addresses, catch-all rules, and forwarders
• Contacts, calendars, rules, signatures, and automatic replies
• Devices, websites, contact forms, scanners, and apps that send through the old SMTP server
• The current MX, SPF, DKIM, DMARC, and mail-related CNAME records

Export or back up anything the destination’s migration method will not copy. IMAP is designed around mail and folders, so plan separate exports for contacts, calendars, local archives, and provider-specific rules.

If you control the DNS TTL, lower the MX record’s TTL ahead of the cutover. Microsoft’s migration guidance recommends 3,600 seconds or less, which lets cached routing information expire sooner after the change.^[2] Changing it at the last minute will not clear records that are already cached under the previous TTL.

If you still need to choose a provider

Some links in this section are affiliate links. If you purchase through them, WPShout may earn a commission at no extra cost to you.

What you need	Useful starting point
A dedicated business email service	Zoho Mail or WPShout’s guide to a professional email address
Email bundled with web hosting	Compare Bluehost, Hosting.com, and other host-based options
A broader provider comparison	See WPShout’s best email hosting providers guide

Before buying, check destination storage, maximum message size, alias and group support, migration tools, retention, authentication options, and the support path for a failed cutover. Those details matter more during a move than a small introductory-price difference.

2. Create the destination mailboxes before cutover

Add and verify your domain at the new provider, then create every user and address from your inventory. Zoho’s delivery documentation explicitly tells administrators to create all accounts before changing MX records.^[4]

For a cPanel-based destination, the domain may already appear under Domains. If it does not, add it using the host’s instructions. Adding it to cPanel prepares the server, but it does not change public DNS by itself.

Next, open Email Accounts and create the same address. Reuse the exact text before the @ sign, but set a new strong password or use the provider’s single sign-on flow.

Repeat the process for every mailbox. Recreate aliases, forwarders, shared addresses, groups, and catch-all behavior separately because they may not come across in a mailbox migration.

Before moving on, sign in to each destination mailbox through webmail. This separates account-creation problems from DNS problems later.

3. Copy existing messages to the new provider

Now migrate the mailbox history while incoming mail still goes to the old provider. Start with the destination provider’s built-in migration tool if it has one. You will usually supply the old server’s IMAP hostname, port, encryption method, usernames, and passwords or administrator credentials.

For a multi-user move, test a small batch before migrating everyone. Zoho recommends a sample migration of approximately 2 to 10 users and describes IMAP as the preferred general method for copying email from other providers.^[5]

For one small mailbox, another option is to add both old and new accounts to an IMAP-capable desktop client and copy folders between them. Keep the computer connected until synchronization finishes, then compare folder counts and a sample of old and recent messages in the destination webmail.

4. Change the email DNS records

Find the service that hosts your authoritative DNS. It may be your registrar, web host, or a separate DNS provider. Save a copy or screenshot of the current zone before editing it.

If only email is moving, leave the website’s nameservers, A records, and CNAME records alone. Changing nameservers replaces control of the whole DNS zone. Do that only when you deliberately want a full DNS migration and have copied every existing record to the new zone first.

Enter the exact MX hostnames, priorities, and other values supplied by the new email provider. MX records control inbound delivery, while SPF, DKIM, and DMARC records help receiving systems authenticate mail sent from your domain.^[6]

• MX: add the destination’s records and remove conflicting old MX records when its wizard tells you to.
• SPF: update the existing SPF TXT record to authorize the new sender. Do not publish two SPF records for the same hostname.
• DKIM: publish the selector and public key generated by the new provider, then enable signing in its control panel.
• DMARC: confirm that the policy and report addresses still make sense once the new service sends mail.
• Other records: add any provider-required verification, autodiscover, or autoconfig records.

Google’s current sender guidance recommends SPF, DKIM, and DMARC rather than relying on MX alone.^[8] Use the destination provider’s validator after publishing the records.

Here is what adding an MX record looks like in GoDaddy. Treat the interface as an example, not a source for the values you should enter.

Check cPanel’s Email Routing setting

If your website remains on a cPanel server but email moves to an external provider, check Email Routing for the domain. The cPanel documentation warns that an incorrect local or remote routing choice can disrupt receiving.^[7] Use the option your host or email provider specifies, which is commonly Remote Mail Exchanger when that cPanel server no longer receives mail.

5. Test delivery and run a final synchronization

DNS changes are not simultaneous for every sender. Google notes that MX changes can take up to 72 hours to be recognized.^[3] Keep the old service active and check both old and new webmail during this period.

Test from an unrelated external account, not from another address on the same domain:

• Send a message to every destination mailbox and important alias.
• Reply from the new mailbox and confirm that it reaches the external account without a warning or spam placement.
• Test groups, forwarders, website forms, transactional emails, and any device that uses SMTP.
• Check the provider’s DNS dashboard for verified MX, SPF, DKIM, and DMARC status.
• Search the old mailbox for any message delivered after the cutover.

Update your email apps

Use the new provider’s current IMAP and SMTP settings, ports, encryption choices, username format, and app-password requirements. On cPanel, those details are available under Email Accounts and Connect Devices.

You can keep the old and new accounts side by side in the mail app during the transition. Give them clear labels so you can see where a message arrived.

After the routing change, run the destination’s migration or synchronization tool again to copy messages that reached the old mailbox after the first pass. Microsoft’s documented IMAP workflow verifies that mail is reaching the destination before synchronization is stopped and the migration batch is removed.^[1]

6. Retire the old provider only after the checks pass

Do not use a calendar alone as the signal to cancel. Retire the old service only when all of these statements are true:

• The new provider reports the domain and required DNS records as verified.
• External send-and-reply tests pass for every important address.
• No new messages have appeared only at the old provider during the monitoring window.
• The final migration pass completed without unresolved errors.
• Mail totals and a sample of old, recent, sent, and attachment-heavy messages look correct.
• Contacts, calendars, rules, signatures, forwarders, groups, forms, and devices work at the destination.
• You have a final export or backup that does not depend on the old account remaining open.

Once those checks pass, remove the old account from mail apps, revoke old migration credentials, and cancel the previous service. Keep your migration notes and final backup until the new setup has completed a normal business cycle.

Troubleshooting common transfer problems

Problem	What to check first
New mail still reaches the old provider	Confirm the authoritative DNS zone, MX hostnames and priorities, cached TTL, and whether old MX records still conflict.
Incoming mail bounces	Confirm that the exact destination mailbox or alias exists, has storage available, and is licensed if the provider requires a seat.
You can receive but cannot send	Check the SMTP server, port, encryption, authentication, app password, SPF authorization, and DKIM status.
Messages are missing from the new mailbox	Review migration logs, quota and size limits, skipped folders, and whether some mail was stored only on a local device.
A website form stopped sending	Update the site’s SMTP credentials and authorized sender, then test the form and its reply-to behavior.
Mail sent by the website lands in spam	Check SPF, DKIM, and DMARC alignment, the visible From address, and the new provider’s delivery logs.

Email provider transfer checklist

• Inventory and back up the old setup.
• Lower the MX TTL ahead of time when possible.
• Create and test every destination address.
• Run the first mailbox migration.
• Change MX and update authentication records.
• Test externally and update every mail client and sender.
• Run a final synchronization and monitor both providers.
• Cancel the old service only after every verification gate passes.

That sequence is the difference between merely redirecting an address and completing a controlled email migration.

References

1. [1] Microsoft Learn: What you need to know about migrating your IMAP mailboxes
2. [2] Microsoft Learn: Migrate other types of IMAP mailboxes
3. [3] Google Workspace Admin Help: Set up MX records
4. [4] Zoho Mail: Configure email delivery
5. [5] Zoho Mail: Email migration
6. [6] Cloudflare Docs: Set up email records
7. [7] cPanel Docs: Email Routing
8. [8] Gmail Help: Email sender guidelines