To route mail for your domain to Google Workspace you replace the existing MX records with Google’s, verify the domain first with a TXT record, and then add SPF, DKIM, and DMARC. Skipping any part of that order is the reason most of these setups bounce mail for an afternoon.
MX records are simple in principle — they say which server accepts mail for a domain — and the process of changing them is unforgiving in a way most DNS changes are not. Get an A record wrong and a page is briefly unavailable. Get MX wrong and mail sent to you during the gap is bounced back to the sender, permanently, with no way to recover it.
Table of contents
- What an MX record does
- Verify the domain before you touch MX
- Setting the MX records
- Verifying instead of waiting
- SPF, DKIM, and DMARC are not optional extras
- Subdomains, aliases, and the rest of the DNS
- How this fits the rest of the stack
- FAQ
What an MX record does
An MX record answers one question: which host accepts mail for this domain. When someone sends to [email protected], their mail server looks up the MX records for example.com and connects to whichever host it finds.
Each record carries a priority, sometimes labelled preference or distance. Lower numbers are tried first. If the lowest-priority host does not answer, the sender falls back to the next one up. That is the entire mechanism — a preference-ordered list of servers willing to receive mail.
The critical detail is that MX records are additive. If you add Google’s records and leave your registrar’s or previous host’s in place, you now have two mail systems claiming your domain. Mail will go to whichever has the lower priority number and will fail over to the other unpredictably. Messages will land in a mailbox nobody checks, and the pattern — some mail arrives, some vanishes — is maddening to diagnose.
That single mistake accounts for most of the confusion in support forums. Removing the old records is not optional cleanup; it is part of the change.
Verify the domain before you touch MX
Google will not activate mail for a domain you have not proven you own, and the ordering matters. Do the verification first, while your existing mail is still flowing normally.
In the Workspace admin console, start the domain verification and take the TXT record it gives you. It looks like google-site-verification= followed by a long string. Add it at your DNS host with the name left blank or set to @, meaning the root of the domain.
Type: TXT
Name: @ (or blank)
Value: google-site-verification=xxxxxxxxxxxxxxxxxxxxxxxx
TTL: 3600Wait for it to propagate, confirm verification in the console, and create your users. Only then change the MX records. If you flip MX first, mail starts arriving at Google for accounts that do not exist yet and gets rejected.
You can check the TXT record has published without waiting on the console:
dig +short TXT example.comSetting the MX records
Google’s current guidance is a single MX record, which replaced the old five-record set. If you are following an older tutorial listing five hosts with priorities from 1 to 10, that configuration still works but the single record is simpler and is what new setups should use.
Type: MX
Name: @ (or blank, or your domain name -- depends on the provider)
Value: smtp.google.com
Priority: 1
TTL: 3600Before adding it, delete every existing MX record for the domain. Registrars frequently create default MX records pointing at their own parking mail service, and many people never notice them until this moment.
The Name field is where DNS providers differ most. Some want @, some want the field left empty, some want the full domain, and some append the domain automatically so entering example.com produces example.com.example.com. If your records look wrong afterwards, this is almost always why. Check what the provider shows after saving rather than what you typed.
Lower the TTL to 300 seconds a day before making the change if you can. It means a mistake is corrected in five minutes instead of an hour, and you can raise it again once everything is confirmed working.
Verifying instead of waiting
The standard advice is to wait up to 48 hours. That is a worst case, and it is a poor substitute for checking. In practice a change with a short TTL is visible within minutes, and you can confirm it directly:
# What MX records are published for the domain
dig +short MX example.com
# Ask a public resolver, bypassing anything cached locally
dig +short MX example.com @8.8.8.8
# Check the authoritative nameservers directly
dig +short NS example.comYou want to see exactly one record pointing at smtp.google.com and nothing else. If an old host still appears, it was not deleted, or it was edited at a DNS provider that is no longer authoritative for the domain — which happens when nameservers were moved at some point and the old zone file still exists somewhere.
That last case is worth naming, because it produces the most baffling version of this problem: you edit records, they save successfully, and nothing changes, because you are editing a zone nobody is reading. Check the NS records first when a DNS change appears to have no effect at all.
Once MX resolves correctly, send a test message from an external address and confirm it lands. Then send one out and confirm it arrives without a spam warning.
SPF, DKIM, and DMARC are not optional extras
MX records govern incoming mail. Three other records govern whether your outgoing mail is believed, and skipping them is why new Workspace domains end up in spam folders.
SPF is a TXT record listing who may send on your behalf. For Workspace alone:
Type: TXT
Name: @
Value: v=spf1 include:_spf.google.com ~allA domain may have exactly one SPF record. If you also send through a marketing platform or a transactional mail service, add their include to the same record rather than creating a second one. Two SPF records is a permanent error and receivers treat it as a failure.
DKIM signs your outgoing mail cryptographically. Generate the key in the Workspace admin console under Apps, Google Workspace, Gmail, Authenticate email, then publish the TXT record it produces at the host it names — usually google._domainkey. Return to the console and click Start Authentication. Generating the key without publishing the record and without starting authentication does nothing, and it is easy to stop halfway.
DMARC tells receivers what to do when SPF or DKIM fails, and gives you reports. Start permissive and tighten once the reports are clean:
Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]Leave it at p=none for a few weeks, read what arrives, and only move to quarantine or reject once you are confident every legitimate sender is covered. Jumping straight to reject is how a company discovers its invoicing system was sending as the domain all along.
Subdomains, aliases, and the rest of the DNS
Mail for a subdomain is a separate configuration. MX records for example.com do not cover mail.example.com or eu.example.com — each needs its own MX records if it should receive mail. Workspace supports adding these as secondary domains or domain aliases, and each still needs its own DNS entries.
Changing MX records has no effect on your website. MX and A records are independent, so your site keeps resolving and serving throughout, and nothing about the mail change requires touching the host. This reassures people more than it should, but it is genuinely the case: pointing mail at Google and pointing the web at your host are two unrelated decisions made in the same DNS zone.
It also means the website and the mailbox do not have to live with the same provider, and generally should not. Bundled mail on a web host is usually the weakest part of the package, and separating them means a hosting migration no longer risks the mail.
How this fits the rest of the stack
Once the mail is settled, the other half of the zone is the part that points visitors at your site — the A or CNAME records, the certificate that has to match them, and the www variant that people still type. Custom domains and certificates on RunxBuild are handled at the project level, so pointing a verified domain at a deployed service is a records change and nothing more. If the domain is new and the site behind it is not built yet, the RunxBuild hosting calculator gives a sense of the running cost before you commit to a shape.
Useful related references:
- Is Google DNS (8.8.8.8) Down? How to Actually Tell Before You Panic
- Google Cloud vs AWS: Pricing, Networking, and When to Pick Each
- GCP and Google Cloud: What the Name Confusion Hides
- Custom domains and certificates on RunxBuild
FAQ
What MX record does Google Workspace use now?
A single record pointing at smtp.google.com with priority 1. This replaced the older set of five records with priorities from 1 to 10. The five-record configuration still works if you have it, but new setups should use the single record because there is less to get wrong.
Why is my Google Workspace email not arriving?
The most common cause is leftover MX records from your registrar or previous host competing with Google’s. Run dig MX on your domain and confirm smtp.google.com is the only result. The second most common cause is changing MX before verifying the domain and creating users, so Google rejects mail for accounts that do not exist yet.
How long do MX record changes take?
Up to the TTL on the old records, which is often an hour and occasionally longer. Lowering the TTL to 300 seconds a day before the change shortens the window considerably. Rather than waiting out a 48-hour estimate, check with dig +short MX yourdomain.com @8.8.8.8 and confirm what is actually published.
Do I need SPF, DKIM, and DMARC as well as MX records?
MX records only control incoming mail. SPF, DKIM, and DMARC determine whether your outgoing mail is trusted, and without them a new domain’s mail is very likely to be filtered as spam. Major providers now expect all three from anyone sending at volume, so treat them as part of the same setup rather than a later improvement.
Does changing MX records affect my website?
No. MX records route mail; A, AAAA, and CNAME records route web traffic. They are independent entries in the same DNS zone, so the site continues serving throughout the mail change. This also means your website and your mailboxes can live with different providers, which is usually the better arrangement.