The short answer: To migrate email to Google Workspace safely, lower your MX TTL ahead of time, verify your domain and add Google to your SPF record, prepare DKIM, copy existing mail while the old system still receives, switch the MX records in one change, then confirm SPF, DKIM, and DMARC pass and tidy up. Authenticate first, cut over second, verify third.
Most migration failures are not lost mailboxes. They are DNS mistakes: an SPF record that still names only the old provider, DKIM that was never switched on, or an MX change made with a 24-hour TTL. This checklist puts the DNS work in an order that avoids those failures.
The same logic applies to the reverse move. The Microsoft 365 authentication guide has the equivalent records.
The Principle: Overlap, Then Cut
Mail should never depend on a half-finished state. For a window of days, both systems must be able to work:
- SPF authorises both the old and new platforms.
- DKIM is ready on the new platform before anyone sends from it.
- MX changes once, in one step, after the new platform has accounts and (ideally) most historical mail.
- The old platform stays active for several days after cutover to catch stragglers.
Everything below follows from this.
Timeline at a Glance
| When | Task |
|---|---|
| 1 to 2 weeks before | Inventory senders, record current DNS, audit authentication |
| At least one old-TTL ahead | Lower TTLs on MX and related records |
| 3 to 7 days before | Verify domain, create users, add Google to SPF, prepare DKIM |
| Cutover day | Start mail copy, switch MX, send tests |
| Day 0 to 2 | Enable DKIM if not done, verify, run delta migration |
| Day 3 to 14 | Monitor DMARC reports, remove old SPF include, decommission |
Phase 1: Audit What You Have
- Export or screenshot your complete DNS zone. This is your rollback reference.
- Run the free email audit and save the SPF, DKIM, and DMARC results.
- Note your DMARC policy. If it is
p=quarantineorp=reject, treat Phase 3 with extra care (see the warning there). - List every system that sends mail as your domain: marketing platform, CRM, helpdesk, billing, website forms, scanners, monitoring alerts.
- Record the current MX values and priorities, and the current TTL on each.
- Check the domain is not listed anywhere with the blacklist checker. Migrating does not fix reputation problems.
- List aliases, distribution lists, shared mailboxes, and catch-all behaviour, since each needs a Google equivalent (alias, group, delegated or shared mailbox).
Phase 2: Lower the TTL
TTL controls how long resolvers cache a record. If your MX records have a TTL of 86400 seconds, some resolvers may keep sending mail to the old server for up to a day after you change them.
- Lower the MX TTL to 300 seconds (5 minutes).
- Make the change at least as long before cutover as the old TTL. A record previously cached for 24 hours needs 24 hours (use 48 to be safe) for caches holding the old value to expire.
- Lower TTL on any related records you may change, such as
autodiscoverormailCNAMEs. - After a stable migration, raise the TTL back to 3600 or higher.
Phase 3: Prepare Google Workspace While Old Mail Still Flows
Do not touch MX yet.
Verify the domain
- Add the domain in the Admin console and publish the
google-site-verificationTXT record Google gives you. A TXT record does not affect mail delivery. - Create users, aliases, and groups to match the old system.
SPF: authorise both platforms
Edit the existing record. Never publish a second one, because two v=spf1 records are invalid (RFC 7208, section 4.5).
Example while migrating from Microsoft 365:
v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all
Example after migration is complete and the old platform is retired:
v=spf1 include:_spf.google.com ~all
Keep your third-party senders in the record, and keep the total under 10 DNS lookups. The SPF checker reports the count. Adding third-party senders to your SPF record and SPF too many DNS lookups cover the details.
DKIM: generate the key
- In the Admin console go to Apps > Google Workspace > Gmail > Authenticate email.
- Select the domain and generate a new record. Choose a 2048-bit key if your DNS host accepts long TXT values.
- Publish the TXT record at the host Google shows, normally
google._domainkey. - Click Start authentication once the record resolves.
Google may not let you start authentication until Gmail is actually receiving mail for the domain. If the button fails or reports that the domain is not receiving, publish the record now and click it immediately after the MX change. Either way, your own outbound mail leaves Google signed only once this is on. A selector clash is not a concern: the google selector does not conflict with your old platform's selectors, so both can sit in DNS together. See the DKIM generator and DKIM signature failed if verification fails.
DMARC: leave it alone
Leave an existing DMARC record unchanged during migration. If you do not have one, publish a monitoring-only record now:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Warning for enforced domains. If you are already at p=quarantine or p=reject, any message from Google that fails both SPF and DKIM alignment will be quarantined or rejected by recipients. Do not let anyone send from Google until SPF includes Google and DKIM is enabled. Consider dropping to p=none for the migration window and restoring afterwards. See DMARC policy: none, quarantine, reject.
Phase 4: Copy Mail, Then Cut Over
Copy historical mail
Use Google's data migration service in the Admin console, or the desktop migration tools for Exchange and Outlook data. Run the first pass while the old system still receives so the bulk of mail copies in the background. A second pass after cutover picks up whatever arrived in between.
Switch the MX records
Replace the old MX records. Do not add Google's alongside them.
Google's current documentation describes a single record:
| Priority | Mail server |
|---|---|
| 1 | smtp.google.com |
The older five-record set (aspmx.l.google.com at priority 1, alt1 and alt2 at 5, alt3 and alt4 at 10) is still widely deployed and still works. Check Google's current MX page in the Admin console and use whichever it shows.
- Delete every old MX record in the same change. A leftover old MX at a lower priority number than Google's will keep receiving mail, and equal priority splits it between systems.
- Send test messages from an external Gmail and Outlook account. Confirm they land in the new mailbox.
- Send from the new mailbox to an external address and read the headers: you want
spf=pass,dkim=pass,dmarc=pass. The email header analyzer helps.
Rollback plan
If mail fails, restore the old MX records from your Phase 1 export. A 5-minute TTL means the revert takes effect fast. Keep the old mailboxes untouched until you are sure.
Phase 5: Verify and Clean Up
- Re-run the free audit. SPF, DKIM, and DMARC should all pass.
- Send a test through every third-party sender and check for
spf=passanddkim=pass. - Confirm DMARC aggregate reports arrive at your
ruaaddress. See DMARC aggregate reports. - Run the delta migration to capture mail delivered during propagation.
- After about a week, remove the old platform's include from SPF.
- If you publish MTA-STS, update the policy file's
mx:lines to the new MX hostname and increment the policyidin the_mta-stsTXT record. A policy naming the old MX will cause compliant senders to refuse delivery. The MTA-STS generator and checker cover this. - Restore TTLs to their normal values.
- Re-point mobile devices and desktop clients, and update autodiscover or CNAME entries for the old system.
Pitfalls and Fixes
| Problem | Cause | Fix |
|---|---|---|
| Some mail still arrives at the old server days later | Old MX left in place, or long TTL not lowered early enough | Remove old MX; lower TTL earlier next time |
| Outbound mail goes to spam after cutover | SPF lacks Google, or DKIM never enabled | Add include:_spf.google.com, enable DKIM |
spf=permerror |
Two SPF records or over 10 lookups | Merge records; trim includes |
| Newsletter or invoice emails fail | Third-party sender not authenticated on the new setup | Re-verify each sender |
Rejected mail with p=reject |
Unaligned Google mail | Fix SPF and DKIM first, or relax policy temporarily |
| Senders get TLS errors | Stale MTA-STS policy | Update mx: entries and policy id |
| Mail loop or bounce | Old server still forwarding to Google, which routes back | Disable the old routing rule |
Frequently Asked Questions
How long does an MX cutover take to propagate?
With a 300-second TTL set in advance, most senders switch within minutes to an hour. With a long TTL that was not lowered ahead of time, expect up to the old TTL, often 24 hours. Some stragglers can take longer.
Should I lower the TTL before or after changing MX records?
Before. A resolver caches the old value for the old TTL, so lowering the TTL at the moment of change helps only after those caches expire. Lower it at least one old-TTL period ahead of cutover.
Do I need to enable DKIM before I migrate?
Prepare it before, enable it as soon as Google lets you. Until DKIM signing is on for your domain, Google-sent mail will not align with your From domain, which hurts DMARC.
Can I run SPF for the old and new provider at the same time?
Yes, in one record with both includes, as long as you stay under 10 lookups. Remove the old include after the old system is retired.
What happens to email sent during the cutover?
Sending servers retry for days if a destination is unreachable, but mail delivered to the old server during propagation sits there. Keep it running and run a delta migration to collect it.
Next step: run the free email audit before and after cutover, or have us handle it with the email migration service. See also SPF, DKIM, and DMARC explained and the DMARC setup guide for Google Workspace.