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.

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.

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:..."

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 MX check alongside the four records that decide whether Gmail treats your mail as authenticated: the google._domainkey selector, the _dmarc policy, the MTA-STS policy file, and the TLS-RPT address. A domain whose MX and SPF are both correct still fails DMARC if DKIM signing was never switched on in the admin console, and neither record shows you that.

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.

📖 Further reading