If you are searching for , , or , the real task is not only copying DNS values.
The real task is making sure your domain routes inbound mail to Google correctly after the change, without leaving a partial migration or stale provider configuration behind.
Quick answer
Google's current standard Google Workspace setup uses this MX record:
| Host | Type | Priority | Value |
|---|---|---|---|
| | | |
Google also documents a DNSSEC-signed Gmail MX option that uses:
| Host | Type | Priority | Value |
|---|---|---|---|
| | | |
| | | |
| | | |
| | | |
Always verify the exact setup path in your Google Admin guidance before replacing working production records.
Which Google Workspace MX record set should you use?
There are two common cases.
Standard Google Workspace MX setup
For most Google Workspace setups, Google currently documents a single MX target:
DNSSEC-signed Gmail MX setup
Google also documents a signed MX option for domains using DNSSEC validation:
If your domain already has older working Google MX records, do not replace them casually. Validate the correct target set in the Admin console or migration instructions before changing live DNS.
How to change Google Workspace MX records safely
Use this sequence:
- document the current MX records
- lower TTL ahead of the cutover if appropriate
- remove old provider MX entries if the migration is complete
- publish the Google Workspace MX records
- wait for DNS propagation
- verify MX resolution with MX lookup
- send and receive live test messages
The most common failure is leaving part of the old provider config active, which causes inconsistent routing during and after the migration.
How to verify Google Workspace MX records
After publishing the records, confirm:
- the domain resolves to the intended Google MX targets
- there are no stale MX entries from the old provider
- priority order matches the Google setup you intended
- test mail sent from an external address reaches the Google mailbox
Useful supporting pages:
Common Google Workspace MX mistakes
Mixing Google and previous provider MX records
If both providers remain published, some senders may route mail to the wrong system.
Updating the wrong DNS host
Some DNS providers expect , others expect the bare domain or an empty host field. Check the provider UI carefully before saving.
Forgetting propagation time
The change can look correct in one resolver while other senders still see the older records.
Replacing a working legacy Google MX set without confirming the correct new one
Do not change live records just because a different Google MX set appears in another blog post. Use Google's current admin documentation for your actual tenant configuration.
Verifying DNS but not verifying live mail
An MX lookup confirms the record. It does not prove a real message reached the expected mailbox.
When Google Workspace MX records are only part of the problem
MX records control inbound routing, but a healthy domain mail setup also needs:
- correct SPF for outbound senders
- DKIM where sending systems require it
- DMARC if you want spoofing protection and better alignment controls
If mail still behaves strangely after the MX change, check the wider DNS and sender-auth posture rather than assuming MX is the only variable.
Related Google Workspace setup guides
MX records solve only the inbound side of the Google Workspace mail path.
Use these guides when the domain migration also touches outbound senders:
- Google Workspace SMTP relay for outbound relay policy, ports, and auth choices
- Google Workspace DKIM setup for sender signing and DMARC-aligned authentication
- Google Workspace DMARC for policy rollout, alignment review, and Gmail-friendly enforcement sequencing
- What are DKIM records? for the generic selector and DNS model behind the Google-specific setup
Use MailSlurp to validate the receive path after DNS changes
MailSlurp helps verify that a Google Workspace MX change behaves correctly in a real workflow, from DNS check through message receipt.
Use it to:
- confirm MX targets with MX lookup
- run broader domain checks with Check email verification
- test receive-side behavior in isolated environments with Email sandbox
That turns a DNS edit into a repeatable verification process.
FAQ
What are the current Google Workspace MX records?
Google currently documents as the standard MX target for many Workspace setups, with a separate DNSSEC-signed Gmail MX option using through .
Do I need to keep old MX records during migration?
Usually no. Once the migration is ready, stale provider MX records should be removed so mail routes cleanly to the intended system.
How do I know the MX change worked?
Run an MX lookup, then send and receive live test messages from outside the domain.
Are MX records enough for Google Workspace mail health?
No. MX handles inbound routing. SPF, DKIM, and DMARC still matter for outbound trust and alignment.
Final take
Google Workspace MX setup is simple only when the cutover is clean. Publish the right records, remove stale provider entries, verify the DNS result, and then confirm live inbound mail before calling the migration finished.