DNS
Google Workspace MX records and cutover
Google Workspace now uses a single MX record, smtp.google.com at priority 1, replacing the older 5-record ASPMX set. Lower the TTL to 300 seconds at least 48 hours before cutover, publish SPF and DKIM first, and mail queues at the sender rather than bouncing while the change propagates.
| Current MX record | smtp.google.com at priority 1, single record |
|---|---|
| Legacy record set | ASPMX.L.GOOGLE.COM plus 4 alternates, still honoured |
| TTL before cutover | Lower to 300 seconds at least 48 hours ahead |
| SPF | v=spf1 include:_spf.google.com ~all, one TXT record only |
| DKIM | 2048-bit key generated per domain in the admin console |
| Sender retry window | Typically 24–72 hours of queueing before a bounce |
The records, in the order they must exist
Order matters because each record protects the next. Publish SPF and turn on DKIM signing while the old platform is still receiving mail, so that outbound authentication is already correct when Google starts handling delivery. Publish DMARC at p=none at the same time to start collecting reports without affecting delivery. Only then change MX.
Doing it in the wrong order produces the classic post-cutover week: mail flows, but a proportion of it lands in recipients' spam folders because SPF still authorises the old sending platform and DKIM signatures do not validate against the new one.
- Verify the domain and add every secondary domain and alias first
- Publish one SPF TXT record; multiple SPF records is a permanent failure, not a warning
- Generate and publish the DKIM key per domain, then enable signing in the console
- Publish DMARC at p=none with a report mailbox you actually read
- Change MX last, then confirm delivery from an external address before telling anyone
TTL is your cutover window
The time-to-live on your existing MX records decides how long the old platform keeps receiving mail after you change DNS. A record still sitting at 14400 seconds means resolvers can keep using the old answer for four hours. Lower it to 300 seconds two days before the change and the propagation tail collapses to minutes.
Keep the old mailboxes reachable for a fortnight regardless. Some sending systems cache aggressively and ignore TTL entirely, and a small trickle of mail will arrive at the old platform after cutover. A forward from the old system into the new one catches it without anyone noticing.
| T-48 hours | TTL lowered to 300s, SPF/DKIM/DMARC verified live |
|---|---|
| T-0, Friday evening | MX switched to smtp.google.com, delivery tested externally |
| T+15 minutes | External send and receive confirmed from two networks |
| T+14 days | Old platform forwarding removed, TTL restored to 3600s |
What actually breaks
Three failures account for nearly every messy mail cutover. Two SPF records published by different people at different times, which fails permanently rather than degrading. Application and device senders — copiers, CRMs, monitoring tools — that relay through the old platform and were never inventoried. And catch-all routing on the old system that quietly swallows mail addressed to typos nobody knew existed.
Discovery catalogues every sending system before cutover, which is the only way to authorise them properly in SPF or move them to authenticated submission. That inventory is the deliverable people underestimate and later depend on.
Confirming the change worked
Do not trust the admin console alone. Send from two external providers, check the received headers for a Google delivery hop, and confirm SPF, DKIM and DMARC all pass in those headers. Then check DMARC aggregate reports two days later for sources you did not expect, which is where forgotten application senders surface.
Only after reports come back clean is it safe to tighten DMARC towards quarantine and then reject. Tightening before you have read the reports is what breaks legitimate mail, and it always breaks the mail somebody important sends.
What we see that others don't say
The MX change itself is the fastest part of a cutover: with a 300-second TTL most resolvers follow within 15 minutes, while the SPF flattening and DKIM key publication that must precede it are what genuinely take a working day to get right.
What this doesn't cover
- We do not manage third-party DNS zones you do not control; the registrar or hosting provider change is yours to make or delegate in writing.
- Mail routing for non-Google systems that must stay authoritative for some addresses needs a split-delivery design, which is scoped separately.
- Bulk and transactional sending belongs on a dedicated platform with its own authenticated subdomain, not on Workspace MX.
- Google may revise its published MX record; verify against Google's Admin Help article on the day you make the change.
Questions we get asked
- What are the current Google Workspace MX records?
- A single record, smtp.google.com at priority 1. The older five-record ASPMX set is still honoured for existing tenants, but new setups should use the single record and remove the legacy entries once delivery is confirmed.
- How long does an MX record change take to propagate?
- As long as the previous record's TTL. With the TTL lowered to 300 seconds beforehand, most resolvers follow within about 15 minutes; without that step a 4-hour TTL means a 4-hour tail.
- Will we lose mail during the MX change?
- No. Sending servers that cannot deliver queue and retry, typically for 24 to 72 hours, so mail arrives late rather than bouncing. Keeping the old mailboxes forwarding for two weeks covers aggressively cached senders.
- Do we need SPF and DKIM before changing MX?
- Yes. Publish SPF, enable DKIM signing and publish DMARC at p=none first. Changing MX before outbound authentication is correct is the usual cause of mail landing in spam after an otherwise clean cutover.
How this page is verified
Reviewed by Pearl Lemon Cloud migrations desk, Google Workspace migration engineers. Last checked .
- MX record values reflect Google Workspace Admin Help guidance as of 2026-08-06.
- Sender queueing and retry behaviour follows RFC 5321 section 4.5.4.
- Cutover timings reflect the sequence Pearl Lemon Cloud uses on fixed-price migrations.
Sources you can check
Related pages
Want the DNS cutover run on a Friday evening, not learned on a Monday?
We inventory every sending system, publish authentication records ahead of the change, switch MX in the agreed window and confirm delivery from outside your network before anyone starts work.