How to Move Business Email Off GoDaddy Without Losing Mail

Moving business email is a ten-minute change wrapped in a two-week process, and the ten minutes are the easy part. The mail that goes missing is almost always mail that arrived during the switch, mail in folders nobody copied, or messages sent from a tool that still points at the old setup.

GoDaddy is the example here because most of the search traffic to my site on this topic comes from people signing in to GoDaddy email, and many of them are on a plan they’d rather leave. The steps are the same if you’re leaving any host. If you’d rather stay, GoDaddy now runs Workspace Email on Microsoft 365, and my guide to signing in to GoDaddy email covers that.

Table of contents

Decide whether to move at all

Move if you want one admin console for mail, calendar, and files, if your team lives in Google Docs, or if you’re paying for a bundle you only use for email. Stay if the mail works and the only complaint is the login screen. A migration with no reason behind it is risk with no payoff.

Step 1: Take inventory before you touch DNS

Write down everything that depends on the current setup:

1. Every mailbox, with its owner and rough size.
2. Aliases, forwarders, and shared inboxes like info@ and billing@.
3. Every tool that sends mail as your domain: invoicing, CRM, forms, email marketing, scheduling.
4. Every phone and laptop with the account added.
5. Where your DNS lives. It may be GoDaddy, Cloudflare, or your registrar. You’ll edit records there, not at the mail provider.

The list matters most for item 3. A tool that sends through your old mail server stops working the day you cancel it, and nothing warns you.

Step 2: Lower the MX record TTL two days early

An MX record tells the internet which server receives mail for your domain. TTL is how long other networks remember the answer before checking again. Open your DNS settings and set the TTL on the MX records to the lowest value your host allows, often 300 seconds. Do this at least 48 hours before the switch, because networks that cached the old long value keep it until it expires.

This is what makes the cutover fast. Skip it and some senders keep delivering to the old server for hours.

Step 3: Create the new mailboxes first

Set up the new provider, add your domain, and create every mailbox, alias, and shared inbox before you change any MX record. The new provider will ask you to prove you own the domain with a TXT record. Add that record now. It doesn’t affect mail flow.

Do not add the new provider’s MX records yet. Mail should still flow to the old server while you copy it.

Step 4: Copy the old mail across

Google Workspace has a data migration tool in the admin console that pulls mail from another provider over IMAP, and Microsoft 365 has an IMAP migration in its Exchange admin center. Both need each user’s credentials or an admin-level connection to the old mailbox, plus the old provider’s IMAP server name. Your old host’s help pages list it.

Two limits to plan around:

• IMAP copies mail, not contacts or calendars. Export those from the old account and import them into the new one by hand.
• Large mailboxes take hours. Start the copy a day early so you aren’t waiting on it at the switch.

Run the copy once now, then again right after the cutover to catch what arrived in between.

Step 5: Switch the MX records

Pick a quiet window, a weekend morning, and do this in order:

1. Delete the old provider’s MX records.
2. Add the new provider’s MX records exactly as it lists them, with the priorities it gives you.
3. Save, then send a test message to yourself from a personal address, and one back out.

Within an hour or two, most mail will reach the new mailboxes. A few messages may land at the old server for up to a day. That’s why you keep it running.

Step 6: Fix SPF, DKIM, and DMARC

This is the step people forget, and it’s where outgoing mail starts landing in spam a week later. Your domain should have exactly one SPF record. Replace the old provider’s include: with the new one and keep the includes for every other tool on your list from Step 1. Then turn on DKIM signing in the new provider’s admin console and publish the key it gives you. Leave your DMARC record alone unless it references the old provider.

The full walkthrough, including how to check that all three pass, is in how to set up SPF, DKIM, and DMARC for business email.

Step 7: Reconnect devices and tools

Remove the old account from each phone and laptop and add the new one. Then open every tool from your Step 1 list that sends as your domain, and update its mail settings or re-authorize it. Send a test from each one.

Step 8: Keep the old plan for two weeks

Leave the old mailboxes active for at least two weeks. Check them every couple of days for stragglers, and run the IMAP copy one more time before you cancel. Only cancel when nothing new has arrived for several days. Cancelling early is the one mistake you can’t undo, because the mail on the old server is gone with it.

Tell Claude or ChatGPT to do it

The inventory and the cutover checklist are the two parts worth handing to an assistant. Paste this and fill in the brackets:

I'm moving business email for [yourdomain.com] from [GoDaddy / current provider]
to [Google Workspace / Microsoft 365]. My DNS is hosted at [DNS provider].
We have [number] mailboxes, and these tools send mail as our domain: [list].
Give me a dated cutover checklist covering: lowering the MX TTL, creating
mailboxes, copying old mail over IMAP, the exact order for changing MX records,
the SPF record I should end up with, and how to enable DKIM. Tell me where each
step happens (DNS host or mail admin console). Flag anything you aren't sure
about for my provider so I can check the provider's own documentation.

Check every DNS value it gives you against the new provider’s setup page before you save it. Assistants will confidently invent an include: or an MX hostname that looks right and isn’t.