Google Workspace's MX record setup is one value, repeated: point every MX record at smtp.google.com, priority 1, and remove every other MX record on the domain. Google is explicit that keeping old MX records alongside the new one is a common cause of mail not working correctly, not a safe fallback.
Your registrar's DNS panel decides some of the exact formatting. Some require a trailing period after smtp.google.com., and providers like Squarespace or Wix offer a preset you select rather than typing the value yourself. Google states to allow up to 72 hours for the change to propagate before activating Gmail in the Admin console, longer than the propagation window most other DNS changes need.
| Field | Value |
|---|---|
| Type | MX |
| Host | @ (or blank, per your registrar) |
| Priority | 1 |
| Value | smtp.google.com |
| TTL | your registrar's default |
Migrations most often go wrong when the new MX record is added correctly and the old one is simply left in place, on the assumption that having both is safer than having one. Multiple MX records tell receiving servers there are multiple valid paths for your mail, and this frequently means messages route unpredictably between the old and new systems until the stale record is removed outright, not just deprioritized.
An MX cutover is also exactly where an SPF record quietly stops matching reality, since the old provider's include is easy to leave in place after mail stops actually routing through it. The Google Workspace DNS checker confirms MX, SPF, DKIM and DMARC all agree in one pass, rather than checking each one by hand.
Yes, separately. The MX record only controls where mail is delivered to; it does not authorize who can send as your domain, which is what SPF governs. An MX cutover with no matching SPF update is a common cause of legitimate mail failing authentication right after a migration.
Google states to allow up to 72 hours for the record to propagate everywhere before turning on Gmail in the Admin console, even though many resolvers pick up the change faster than that.
Google's own instructions say to remove other MX records rather than keep them, stating that old or incorrect MX records can cause mail to stop working correctly rather than providing a safe fallback.