Alternatives to GoDaddy Email Hosting: Move Without Losing Mail

Replacing GoDaddy email hosting without losing mail means copying every mailbox to the new provider first, then switching the domain’s mail routing records only after the copy is verified. The safe order is create the new mailboxes, migrate the old messages over IMAP, test sending and receiving, then change the MX records and keep the old account alive for a while as a fallback.

Why the order of operations matters more than the provider

Most failed migrations are not caused by a bad email host. They are caused by cutting the DNS records before the mail is copied. Once the MX records point at the new provider, new messages start arriving there, but the old mailbox still holds everything from before. If you close the GoDaddy account at that moment, those older messages are gone.

So treat the move as two separate jobs. First, copy the history. Second, redirect the flow. Do them in that order and almost nothing can go wrong.

The copy job runs over IMAP, the protocol that lets a mail client read and store messages on a server. IMAP was designed by Mark Crispin in 1986 as a remote access mailbox protocol, and it is still the standard way migration tools pull mail out of one server and push it into another. An IMAP server typically listens on port 143, while IMAP over SSL/TLS (IMAPS) uses port 993. Use the encrypted port whenever the provider offers it.

That matters because you will be handling credentials for every mailbox on the domain. Plain port 143 can send those credentials unencrypted, which is the same weakness that makes plain FTP a poor choice for file transfers. If you want the longer explanation of why encrypted variants exist, this comparison of Is FTP Secure? Plain FTP vs FTPS vs SFTP covers the same logic that applies to mail.

What you actually need before you start

Gather these first. Hunting for them mid-migration is how people lock themselves out of accounts.

• A list of every mailbox on the domain, including aliases, shared inboxes, and any address that forwards somewhere.
• Passwords for each mailbox, or the ability to reset them from the GoDaddy control panel. You will need working credentials to copy mail over IMAP.
• Access to the domain’s DNS records, either at GoDaddy or wherever the nameservers point. Confirm which one before you promise yourself a cutover date.
• The new provider’s IMAP and SMTP server names and ports, from their setup page.
• A migration tool. Most business email providers include one. Otherwise a desktop mail client can copy between two IMAP accounts.
• A quiet window. Pick a low-traffic evening or weekend so a brief hiccup does not land in the middle of a busy thread.

If the domain’s website also lives on GoDaddy, do not touch the hosting plan while you work on mail. Web hosting and email hosting are separate services even when one bill covers both. If you are unsure which plan you have, this review of Economy Linux hosting with cPanel at GoDaddy explains how that side of the account is structured, so you can leave it alone.

The migration, step by step

This is the sequence I would follow for a small business domain. The migration steps are broadly similar across providers, but server details and procedures can differ.

1. Create the new mailboxes. Set up every address at the new provider with the same local part, so name@yourdomain.com stays identical. Do not change the MX records yet.
2. Lower the MX record TTL. Microsoft recommends lowering the MX record TTL to 3,600 seconds (one hour) or less before starting email migration. If you have multiple MX records, each must be changed to a value of 3,600 or less before migration. Change the TTL before starting the migration so cached values can expire.
3. Run the copy in batches. A staged migration CSV file can contain at most 2,000 rows, so larger migrations require multiple batches. Small domains fit in one pass.
4. Verify the copy. Compare message counts per folder, open a few old threads, and check that attachments came across.
5. Switch the MX records to the new provider’s servers, then wait. After changing the MX record, it can take up to 72 hours for other email systems to recognize the change.
6. Test both directions. Send from an outside address to each mailbox, and send out from each mailbox. Check spam folders on both ends.
7. Keep the old account alive for a couple of weeks, then cancel it once nothing has landed there.

The batch limit is the one number people trip over. If you are moving a domain with a handful of addresses, a single batch is fine. If you are consolidating several domains or years of heavy mail, plan for several passes and give each one time to finish before you start the next.

Connection limits are the other quiet constraint. A migration scenario at one provider assumes a maximum connection limit of 10. Push more simultaneous connections than the server allows and the tool starts throwing errors that look like authentication failures. Reduce the concurrency setting and rerun the batch.

Choosing the alternative that fits your mail

The keyword question, alternatives to GoDaddy email hosting, has more answers than it needs. What matters is which kind of host suits how you actually use mail.

A full business suite. Mail plus calendar, contacts, file storage, and shared documents. Best when a team collaborates. Migration tools are usually built in, and the batch limits above come from that world.

Mailbox-only hosting. Cheaper, simpler, and fine for a solo operator or a small office that just needs reliable sending and receiving. You often get IMAP, SMTP, and a webmail interface and nothing else.

Hosting bundled with your website. If your site already sits on a cPanel-style plan, adding mail there keeps one bill and one login. Many small hosts include mailboxes with the plan. Check the mailbox count and storage per box before you commit, because the cheap tiers are stingy.

A privacy-focused provider. Worth it if your mail carries client confidences. Expect to pay more and to do more of the migration manually.

Whatever you pick, confirm three things in writing before you pay. Does the plan support the number of mailboxes you need? What is the storage per mailbox? Does it offer IMAP access at all, since some budget plans only give you a web interface and forward the rest?

That last point is the one that traps people. A host with no IMAP access cannot be the destination for a migration tool, and it cannot be the source later if you move again. You would be copying mail by hand, message by message.

Costs, and what you are really paying for

The real cost of a migration is the hours, and the real risk is losing an archive you cannot rebuild.

So do not optimize on the monthly fee alone. Ask what happens when a mailbox hits its limit, and whether you can buy more storage without changing plans.

There is also a hidden cost in keeping the old account as a fallback. Budget for the overlap and keep the old account alive past the day you flip the records.

Mistakes that lose mail

These are the ones I see repeatedly, and each one is avoidable.

Cancelling before the copy finishes. The single biggest cause of lost mail. Cancel last, never first.

Changing MX records and nameservers at the same time. If something breaks, you will not know which change caused it. Do the mail records first, confirm, then touch anything else.

Forgetting the aliases and forwarders. The main mailbox migrates, the alias that clients actually use does not, and mail to that address starts bouncing. List every address on the domain, including the ones without a login.

Skipping the TTL change. With a long TTL still cached around the world, some senders keep delivering to the old server for days after you switch. Lower it first.

Assuming the copy caught everything. Migration tools sometimes skip folders that are not in the standard set, or choke on very large attachments. Spot-check the odd folders along with the inbox.

Leaving the old account open forever. Once you are confident, close it. An abandoned mailbox with a live password is a security problem, and it keeps billing.

When to call someone else

Do the migration yourself if you have a handful of mailboxes, working passwords, and DNS access. That covers most small businesses and nearly all solo operators.

Bring in help when the domain has many mailboxes, when nobody knows the DNS login, or when the mail is legally sensitive and you need a documented chain of custody. Also call a professional if the domain is tied to a website, a shop, or booking system that shares the same DNS records, because a wrong edit there takes the site down along with the mail.

One more case. If the current account is the only place a password reset for the domain registrar can be sent, change that first. Locking yourself out of the registrar can delay the migration.

Alternatives to GoDaddy Email Hosting FAQ

How long does it take to switch email hosting without losing mail?

Plan for up to 72 hours after the MX change for other mail systems to recognize it, plus the time to copy the existing mail. Microsoft notes that after changing the MX record, it can take up to 72 hours for other email systems to recognize the change.

Can I keep my old emails when I move to a new provider?

Yes, if you copy them over IMAP before you cancel the old account. IMAP is defined by RFC 9051 and lets a migration tool read every folder on the old server and write it to the new one. Copy first, verify, then switch the records.

What is the maximum batch size for a staged email migration?

A staged migration CSV file can contain at most 2,000 rows, so larger migrations require multiple batches. If your domain has more mailboxes than that, split the work into several passes and let each one finish before starting the next.

Do I need to change my email address when I switch hosts?

No. Your address stays the same because it belongs to the domain, not the host. Only the servers behind it change. That is why the MX records are the switch you flip, and why the copy has to happen before you flip them.

What port should the migration tool use?

Use port 993, the IMAPS port for encrypted connections, whenever the provider supports it. The unencrypted IMAP port should be avoided for migration, since it can expose mailbox passwords in plain text. Sending credentials over the encrypted port keeps them out of plain text.

Thank you for reading!

Roosevelt Naylor

Editor

Roosevelt Naylor writes about referral programmes and word-of-mouth growth on Limitless Referrals: what actually makes someone recommend a business, and why most reward schemes never manage it. He prefers plain arithmetic to growth-hacking claims.