GICT knowledge base
Google Workspace MX Records: Current and Legacy Setup
Published
Google Workspace uses MX records to receive mail for a domain provisioned in that service. Adding Google MX records alone does not create users, verify ownership or move old mail. Consumer Gmail forwarding and Workspace domain-mail setup are different tasks.
Use the current Workspace setup instructions
Google currently documents a single MX destination smtp.google.com with priority 1. Older Workspace domains can have supported legacy aspmx records; Google says a working legacy setup does not require replacement merely because the newer single record exists. Use the domain’s actual Admin-console guidance rather than blindly combining old and new tables.
| Field | Current single-record setup |
|---|---|
| Type | MX |
| Owner | The domain’s apex, represented by @, blank or the full name according to the authoritative DNS editor |
| Preference | 1 |
| Destination | smtp.google.com, using a trailing dot if the editor requires an absolute name |
| TTL | A deliberate provider-supported value in the editor’s stated units, not an unexplained copied number |
Coordinate the cutover
- Verify domain ownership in Workspace, provision required users/aliases and preserve the current MX set and old messages.
- Identify the actual authoritative DNS provider, which may differ from the registrar or web host.
- Apply the reviewed receiving configuration there. Remove obsolete receiving entries only as part of the planned provider change; unrelated providers are not automatic backups.
- Complete Gmail activation in the Google Admin console and confirm the intended domain.
- Verify authoritative MX answers and actual authorized receiving/reply tests before retiring old service.
Lower preference numbers are favored. MX destinations are hostnames, not IP addresses or SMTP-client login settings. Keep local hosting mail-routing settings consistent if websites on the old host send to this domain. Authentication records and historical mailbox transfer need separate work.
Cached old answers and provider activation can delay the transition, but a fixed waiting period is not proof of correctness. Inspect authoritative records and account provisioning immediately if they are wrong. Google publishes timing guidance in its setup documentation; do not interpret it as a guaranteed worldwide completion deadline.
Reference: Google Workspace MX setup, legacy support and Gmail activation.
Reviewed October 15, 2026. Documentation review only; no Workspace account, MX record, migration or mail-delivery test was performed.
Related guides
How to Test Application Emails with Mailpit
Capture staging emails with Mailpit over a private connection. Inspect message formats and attachments without confusing capture with real delivery.
EmailHow to Test SMTP Login and TLS with swaks
Diagnose SMTP connectivity, TLS and authentication with swaks. Protect credentials and distinguish server acceptance from recipient delivery.
EmailResolving: This message was classified as rSPAM and may not be delivered
Resolve InterServer rSPAM rejections using the SMTP code and MailBaby rule details. Check authentication, security and false positives through support.
EmailHow to Check SPF, DKIM and DMARC Using Message Evidence
Diagnose email authentication using real message identities and selectors, DNS answers and alignment instead of guessed records or delivery assumptions.
