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

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, because both are needed before receivers will enforce TLS to your inbound MX. 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:..."

Older tenants still run the five-host aspmx.l.google.com set with alt1 through alt4. Both layouts are valid. Google's docs steer new tenants at the single-host form.

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.

Frequently Asked Questions

Common questions about Google Workspace DNS configuration.

The minimum is:

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. -all is the goal. ~all is fine while you're still migrating off the previous host.

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.

Older tenants run the five-host layout (aspmx.l.google.com plus alt1 through alt4.aspmx.l.google.com). Both authenticate the same way. Don't mix the two, pick one and remove every other MX entry, including leftover smarthosts from the previous provider.

Yes. MTA-STS stops a downgrade attack from stripping TLS off inbound mail. For Workspace, 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 listing aspmx.l.google.com and the alt hosts (even on single-MX tenants, the policy still names the alt set).

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. Workspace mailboxes are reached over IMAP, POP, SMTP, or the Gmail web and mobile clients. There is no Autodiscover XML endpoint and no SRV-based discovery.

If you need Outlook to auto-configure against Gmail, install Google Workspace Sync for Microsoft Outlook (GWSMO). It configures the client without touching DNS. Don't publish stub Autodiscover records for Workspace, they only confuse Outlook clients that probe the wrong endpoint first.