Google Workspace DNS guide
Gmail starts receiving business mail only after MX records point to the right place.
A clean Gmail MX record setup confirms the active DNS host, removes old routing conflicts, publishes Google's current MX target, and proves delivery with external tests before handover.
Gmail MX records are the DNS records that tell the internet where incoming email for your domain should be delivered. If your business email address is [email protected] and Google Workspace is your mail provider, the domain's MX records must route inbound mail to Google.
The hard part is not typing a record. The hard part is changing the correct DNS zone, avoiding old provider conflicts, making sure every mailbox already exists, and proving that real mail from outside Google reaches the expected inbox.
This guide covers the practical Gmail MX records setup for Google Workspace: what to prepare, what to publish, how to activate Gmail, how to test delivery, and what to do when the Admin Console still says mail is not ready.
MX setup sequence
Quick answer
Google's current Workspace MX setup guide uses smtp.google.com as the MX record value. For a standard Google Workspace Gmail setup, the practical record worksheet is:
Gmail MX record worksheet
| Field | Value to confirm |
|---|---|
| Record type | MX |
| Host or name | Usually @ or blank, depending on DNS provider |
| Value or mail server | smtp.google.com |
| Priority | Follow the value shown by Google Admin or your DNS provider's Google Workspace preset |
| TTL | Use a normal DNS TTL, or lower it before a planned cutover if your DNS host allows it |
| Old records | Remove or de-prioritize old mail-provider MX records as part of the cutover |
Always confirm the exact instruction inside your Google Admin setup flow and Google's current MX setup documentation before editing production DNS: Set up MX records for Google Workspace.
Before changing MX records
MX records affect inbound mail. Changing them too early can send new customer messages to mailboxes that do not exist yet. Changing the wrong DNS zone can make you believe mail is fixed while the internet still sees the old record.
Use this preparation checklist before you touch DNS:
Pre-cutover checklist
- Confirm the domain owner and registrar account.
- Confirm the active nameservers and DNS host.
- Export or screenshot current DNS records.
- Create the required Google Workspace users first.
- Decide aliases and groups before cutover.
- Identify the old mail provider and old MX records.
- Confirm whether historical mail needs migration.
- Confirm website forms, CRM, invoicing tools, and support tools that send email.
- Prepare external test accounts, not only Gmail-to-Gmail tests.
- Decide who approves the change and who monitors after cutover.
The active DNS host is the most common source of confusion. A domain might be registered at GoDaddy, have nameservers at Cloudflare, host the website at cPanel, and have old email at Zoho or Microsoft 365. Only the authoritative DNS host matters for the live MX record.
Publish Gmail MX records
Work in this order:
Verify domain ownership in Google Workspace and confirm the admin account belongs to the business.
Create users, aliases, and groups so mail has a valid destination after cutover.
Add the current Gmail MX value at the active DNS host and remove old routing conflicts.
Send external test mail, check aliases, and confirm business-critical senders.
Document the records, tests, support contacts, and monitoring window.
In your DNS panel, add or update the MX record for the root domain. Some DNS providers use @ for the host field. Others use a blank host or the full domain. Do not guess if the provider's interface is unusual; check its help text before saving.
After saving the MX record, return to Google Admin and continue the Gmail activation flow. If Google Admin does not recognize the record immediately, that is not automatically a failure. DNS changes can take time to be recognized globally.
Test Gmail delivery
Do not rely on the Admin Console status alone. Run operational tests that match the way the business actually receives mail.
Send from outside Google
Test from an Outlook, Yahoo, Apple Mail, or another external provider. A Gmail-to-Gmail test can hide routing issues.
Test public-facing addresses
Send to hello@, sales@, support@, and any old address the business still advertises.
Confirm group delivery rules
If a Google Group receives customer email, confirm external posting permissions and membership before go-live.
Read failures carefully
A bounce message can reveal wrong MX records, missing mailboxes, blocked external posting, or old routing.
Use a simple test matrix:
| Test | Expected result | Evidence to keep |
|---|---|---|
| External sender to primary user | Message arrives in Gmail inbox | Timestamp and sender address |
| External sender to alias | Message arrives in the mapped user inbox | Alias and destination |
| External sender to group | Members receive or can handle the message | Group address and member result |
| User sends outward | Recipient receives the message | Sender, recipient, timestamp |
| Website form sends email | Business receives form notification | Form page and destination |
| Invoice or CRM sends email | Customer receives legitimate mail | Third-party sender name |
Troubleshoot Gmail MX records
Most MX problems fall into a few categories:
Wrong DNS host
The record was added at the registrar, but the domain uses external nameservers. Check the authoritative nameservers first.
Old MX records still active
Old cPanel, Zoho, or Microsoft records can continue receiving mail if they remain in the live DNS zone with usable priority.
Wrong host field
Some DNS panels require @, some require blank, and some require the full domain. A record on www will not route root-domain email.
Mailbox not created
MX can be correct while delivery still fails because the destination user, alias, or group does not exist.
DNS delay
Google notes that MX changes can take up to 72 hours to be recognized. Keep monitoring instead of making repeated random edits.
Group posting blocked
A support or sales group may reject external senders if posting permissions are too restrictive.
When troubleshooting, change one thing at a time. If you edit MX records, SPF, DKIM, DMARC, forwarding, and group permissions all at once, you will not know which change fixed or broke mail flow.
Handover notes
A Gmail MX setup is not complete until the owner can see what changed.
MX handover should include
- Domain name and active DNS host.
- Previous mail provider and old MX records.
- New Gmail MX record.
- Date and time of DNS change.
- Person who approved the cutover.
- Users, aliases, and groups tested.
- External test evidence.
- Known items still under monitoring.
- Link to the full Google Workspace setup runbook.
If you want the complete setup path, use this with the broader guide: Google Workspace setup for small businesses.
FAQ
Do I need five Google MX records or one MX record?
Google's current Google Workspace setup uses the single smtp.google.com MX value. Older Workspace setups may still show legacy ASPMX style records, but for new work you should follow the current Admin Console and Google help instructions.
Can I change MX records before creating users?
It is safer to create users, aliases, and groups first. If mail starts routing to Google before the destination exists, senders can receive bounces.
Why can I send email but not receive email?
Sending can work before inbound MX is correct. Receiving depends on live MX records, mailbox existence, and group or alias routing.
Should SPF, DKIM, and DMARC be done with MX?
They are related but separate. MX routes inbound mail. SPF, DKIM, and DMARC help receiving systems authenticate outbound mail from your domain.
How long should I monitor after changing MX records?
Monitor at least through the DNS recognition window, and longer if the business has critical leads, invoices, support requests, or form notifications.
