Migrate Email to Google Workspace Without Losing Any Mail

Switching your business email to Google Workspace or Microsoft 365 sounds simple — change the MX record, done. But do it carelessly and you'll lose incoming mail for hours, break SPF for your marketing tools, and get a support ticket from every department asking why email "stopped working." Here's how to actually do the cutover without dropping a single message.

Why This Migration Trips People Up

Email isn't like moving a website. There's no maintenance window where nobody notices — mail keeps arriving every minute, from every direction, and DNS changes don't take effect everywhere at once. Between the moment you update your MX record and the moment every mail server on the internet has picked up the change, you're in a window where some senders deliver to your old mailbox and some deliver to the new one. If you're not ready for that, mail gets lost or delayed, not bounced — which is worse, because nobody gets an error to alert them.

The second problem is SPF. Your domain's SPF record lists every service allowed to send mail as you — your old hosting mail server, Mailchimp, your CRM, a WordPress contact form plugin. Swap providers without updating SPF, and Google Workspace mail either gets flagged as spam or, if you remove the old include too aggressively, your other tools stop being able to send at all.

Before You Touch DNS: Plan the Cutover

Step 1: Lower your MX TTL 24-48 hours ahead

DNS records cache for however long the TTL says, and MX records are often set high (3600-86400 seconds) if nobody's touched them in years. In cPanel, go to Zone Editor → Manage, find your existing MX record, and drop the TTL to 300 (5 minutes) a day or two before the real change. This doesn't speed up the migration itself, but it means when you do flip the record, the world catches up in minutes instead of a full day.

yourdomain.com.  300  IN  MX  10  mail.yourdomain.com.

Step 2: Audit what's currently sending mail as your domain

Pull your current SPF record and write down every include: and ip4: entry:

dig TXT yourdomain.com +short | grep spf1

You'll add Google's (or Microsoft's) include to this list — you're not replacing it, unless a service in there was only ever used by your old hosting mailbox.

Step-by-Step: The Actual Cutover

Step 3: Verify domain ownership with Google

In the Google Workspace admin console, add your domain and verify it — either with a TXT record or by uploading an HTML file. Do this before changing MX; verification doesn't touch mail flow, so there's no risk in doing it early. In cPanel's Zone Editor, add:

Type: TXT
Host: @
Value: google-site-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Step 4: Create every mailbox in the new provider first

Before you touch MX, create every user's mailbox in Google Workspace with the same address they currently use. Mail delivered mid-cutover to an address that doesn't exist yet on the new side bounces — and once it bounces, it's gone. This matters most for shared inboxes like sales@ or support@ that get mail constantly.

Step 5: Switch the MX records

Back in cPanel → Zone Editor, delete the old mail exchanger entries (or set their priority much higher than Google's so they're a fallback, not primary) and add Google's:

Priority 1   ASPMX.L.GOOGLE.COM.
Priority 5   ALT1.ASPMX.L.GOOGLE.COM.
Priority 5   ALT2.ASPMX.L.GOOGLE.COM.
Priority 10  ALT3.ASPMX.L.GOOGLE.COM.
Priority 10  ALT4.ASPMX.L.GOOGLE.COM.

If your domain's nameservers point somewhere other than Getwebup's cPanel (Cloudflare, GoDaddy DNS, etc.), make this change there instead — MX has to live wherever your domain's authoritative DNS actually resolves from.

Step 6: Update SPF, add DKIM, keep DMARC in monitor mode

Edit your existing SPF TXT record to add Google's include alongside whatever else is still sending mail for you:

v=spf1 include:_spf.google.com include:yourcrm.com ~all

Then generate a DKIM key in the Google admin console (Apps → Google Workspace → Gmail → Authenticate email) and add the TXT record it gives you. If you already have a DMARC record, leave the policy at p=none for the first week so you can watch the aggregate reports without risking legitimate mail getting rejected while SPF/DKIM settle in.

Migrating the Old Mailbox Data

Switching MX only handles new mail going forward — it does nothing for the messages already sitting in your old mailboxes. For that, use Google Workspace's built-in Data Migration Service (Admin console → Data migration), which connects over IMAP to your old mail server and copies everything across per-user. You'll need:

• The old mail server's IMAP hostname (usually mail.yourdomain.com) and port 993
• Each mailbox's existing username and password (or an app-specific password if 2FA is on)
• A day or two of patience — large mailboxes with years of attachments take time

Run this migration before you flip MX, while the old mailbox is still receiving mail, then run it again afterward to catch anything that arrived in the gap. Two passes beats one.

Avoiding Downtime During the Cutover

Because MX propagation isn't instant, keep the old mailbox account active and reachable for at least 3-5 days after the switch, even though new mail is now landing in Google Workspace. Some slow-to-update DNS resolvers will keep delivering to the old server during that window. If you disable or delete the old mailbox immediately, that stray mail bounces instead of just arriving late.

After the Cutover

Once you've confirmed mail is flowing correctly for a week, tighten your DMARC policy from p=none to p=quarantine, remove any SPF includes you confirmed are unused, and cancel or downgrade the old hosting mailbox plan. Keep the domain's SPF and DKIM records documented somewhere your team can find them — the next migration (there's always a next one) goes a lot faster with a paper trail.

Prevention: Make the Next DNS Change Boring

Most of the pain in an email migration comes from treating DNS as a set-and-forget system. Keep TTLs reasonable (an hour, not a day) year-round so future changes propagate fast, review your SPF record whenever you add or drop a marketing/CRM tool, and don't let DMARC sit at p=none forever — it's meant to be a temporary monitoring stage, not a permanent setting.