Google Workspace DNS Checker

Enter a domain hosted on Google Workspace / Gmail. We check the records that matter for a Google tenant: SPF includes _spf.google.com, the DKIM google selector, DMARC, an MX pointing to Google's mail servers, and MTA-STS.

Try an example: spotify.com · monzo.com · revolut.com · youtube.com

Frequently Asked Questions

Common questions about Google Workspace DNS configuration.

Google's record for a domain that sends only through Workspace:

v=spf1 include:_spf.google.com ~all

If you send through other services too, add their includes alongside. Watch the 10-DNS-lookup limit: an SPF record that exceeds it returns permerror and stops authorising anything. Google recommends ~all on its SPF setup page (read 10 November 2026), so this checker does not mark it down.

By default, google. The TXT record lives at:

google._domainkey.example.com

If you picked a custom selector when generating the key in the admin console, this checker won't see it under google. Run the DKIM checker with your selector name to confirm it resolves.

New tenants get a single host at priority 1:

example.com.  MX  1  smtp.google.com.

Domains that started on Workspace before 2023 may still have the legacy values, which start with aspmx (aspmx.l.google.com, alt1.aspmx.l.google.com and so on). Google still supports them and says no change is needed if mail is working. Either way, remove any MX entry that is not Google's, including leftovers from the previous provider.

Yes. MTA-STS stops a downgrade attack from stripping TLS off inbound mail. Publish a TXT record at _mta-sts.example.com and host a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt. Every MX host has to match an mx: line in that file (RFC 8461 §4.1), so the lines follow your MX records. On the single smtp.google.com MX:

mx: smtp.google.com

On the legacy aspmx values:

mx: aspmx.l.google.com
mx: *.aspmx.l.google.com

A * covers one label only, so *.aspmx.l.google.com matches alt1.aspmx.l.google.com but not aspmx.l.google.com itself. If your MX lists any other host, it needs a line too.

Pair it with TLS-RPT so failed connections get reported back. The MTA-STS checker validates both the DNS record and the policy file in one pass.

No. Autodiscover is how Exchange hands a mail client its settings, and Workspace mail isn't on Exchange. This page doesn't check for it.

What to do: for Outlook, Google's route is Google Workspace Sync for Microsoft Outlook (GWSMO), which sets up the Outlook profile for the user. Other clients add the mailbox over IMAP, using Google's "Add Gmail to another email client" instructions.

How this Google Workspace DNS checker works

Google Workspace needs a specific set of DNS records before it will sign outbound mail, accept inbound delivery, or align with DMARC. Stale entries from a previous provider are the usual reason Workspace mail starts landing in Gmail's own spam folder. Type a domain above and the tool runs every Workspace-specific check in one pass.

We confirm the MX hosts match Google's current set, that SPF includes _spf.google.com, that the google._domainkey selector resolves to a live key, and that DMARC is published. MTA-STS and TLS-RPT get probed too. MTA-STS makes senders insist on TLS to your inbound MX, and RFC 8461 pairs it with TLS-RPT so you hear when that fails. Each row shows what Google expects, what's actually live, and how to close the gap.

What does Workspace actually require?

The minimum viable Workspace setup is one MX, one SPF include, one DKIM selector, and a DMARC record: 

example.com.                MX   1  smtp.google.com.
example.com.                TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey.example.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."
_dmarc.example.com.         TXT  "v=DMARC1; p=reject; rua=mailto:..."

Is this the same as Google's Admin Toolbox Check MX?

Google runs its own MX checker at toolbox.googleapps.com/apps/checkmx, and its page title describes the scope exactly: "Check MX and SPF Records." For an MX or SPF question that is the whole answer.

This page runs the same MX and SPF checks. It also reads the google._domainkey selector, the _dmarc policy, MTA-STS, TLS-RPT and BIMI. Correct MX and SPF say nothing about DKIM. If signing was never started in the admin console, DMARC can only pass on an aligned SPF result.

Our take: run both. They query the same DNS and should agree on MX; if they disagree on MX, check whether the change is still propagating before you edit anything. The propagation checker queries a spread of public resolvers and shows which ones have the new answer.

What MX records should a Workspace domain have?

Newer tenants get a single host at priority 1: 

example.com.  MX  1  smtp.google.com.

Older tenants run five hosts, and Google still accepts mail on all of them: 

example.com.  MX   1  aspmx.l.google.com.
example.com.  MX   5  alt1.aspmx.l.google.com.
example.com.  MX   5  alt2.aspmx.l.google.com.
example.com.  MX  10  alt3.aspmx.l.google.com.
example.com.  MX  10  alt4.aspmx.l.google.com.

What to do: pick one layout and delete the other. The failure we see most often is a half-finished migration to the single-host record that left two of the alt hosts behind. All five still resolve, so nothing breaks and nobody notices the record is half-converted. Mixing a non-Google host into either set is worse: mail splits across two systems and only one of them has the mailbox. The MX checker resolves each host and shows the addresses behind it.

Where does Workspace mail go wrong?

Three failure modes account for most Workspace deliverability tickets. DKIM that was never turned on in the admin console, so the selector exists in DNS but signing is off in the tenant. SPF still pointing at the previous host's include, which silently breaks alignment. And MX records that mix Google with a leftover smarthost from the migration, so half your mail loops.

Our take: if the checker flags any one of those, fix it before chasing reputation issues. Misconfigured DNS looks like a reputation problem from the outside, and you can spend weeks warming an IP that was never going to authenticate.

Why this matters

Gmail enforces SPF, DKIM, and DMARC on any sender pushing more than 5,000 messages a day. That rule has been in force since February 2024. Workspace tenants get no free pass, mail from your own domain through Google's own servers still bounces with 550 5.7.26 if the records don't line up.

What to do: publish DMARC at p=quarantine first, watch the aggregate reports for a week, then move to p=reject. The DMARC checker shows what's live and where to send rua= reports.

Where to go next

For per-record detail see the SPF checker and the DKIM checker. Hybrid Microsoft 365 tenants get their own checker at the Microsoft 365 DNS checker. If MTA-STS or TLS-RPT need work, the MTA-STS checker and the TLS-RPT checker probe both ends of the policy. To upgrade Google Workspace DKIM to 2048-bit without a signing-gap surprise, see the step-by-step guide.

🤖 Using an AI agent?

This same check runs over our free MCP server. Point Claude, Cursor or any MCP client at https://tamingdns.com/mcp and ask it to call check_google_workspace. You get the same grade the page shows, as JSON, from the same engine. You don't need a key or an account. How it works →

📖 Further reading