Email authentication
Google Workspace setup checker
Check a domain’s MX, SPF and DKIM against the exact values Google Workspace documents.
Free, no accountLive check
Result
The verdict appears here once you press Check Workspace records.
What this is
This Google Workspace setup checker reads what a domain actually publishes and holds it against the values in Google’s own setup pages: the one MX host, the one SPF include, and the DKIM selector Google calls the default - rather than only telling you that some SPF record exists.
Workspace mail rests on three published values. Two are the same for every customer Google has: the MX host mail is delivered to, and the SPF include that authorises Google’s servers to send. The third, the DKIM public key, is generated for your domain and published at a selector whose name Google chooses for you.
That is what makes a provider-aware check worth doing. A generic checker can tell you an SPF record is syntactically fine while it authorises nobody at Google, and that a DKIM key exists at some selector that Workspace will never sign with. Both read as green and neither is what Google asked for.
How to read the result
The table pairs each of Google’s documented values with what this domain publishes, so three rows are most of the answer. A row reading "missing" is a record to add; a row reading "present, through another include" works but spends one more of the ten DNS lookups SPF allows than naming Google directly would.
Findings run from the worst down. The Workspace-specific ones come first, then the full SPF, DKIM and DMARC detail each generic checker would give, so a record that is present but faulty - a key under 1024 bits, a chain over the lookup limit, a DMARC policy still set to none - is still named.
This checker only covers Google Workspace’s own fixed SPF include and DKIM selector. For how SPF, DKIM and DMARC fit together, what order to fix them in, and what to do once one fails, see our guide How SPF, DKIM and DMARC work together, and what to do when one fails.
Common mistakes
What goes wrong most often, and how to tell.
- Changing the MX records and stopping therePointing MX at Google moves where mail arrives. It authorises nothing: until the SPF include is added and the DKIM key is published and switched on, mail sent from the new Workspace account is unauthenticated, which is the state most likely to be quietly filtered.
- Adding a second SPF record for Google beside the old oneTwo "v=spf1" TXT records on one domain is a permanent error that makes a receiver ignore both, so the domain ends up worse off than before Google was added. The include belongs inside the record that is already there.
- Publishing the DKIM key and never clicking Start authenticationGoogle treats publishing the record and turning signing on as two separate actions, in that order, and the second one is easy to miss once the DNS change has been made. The key then sits there, correct and unused, and no outgoing message is signed.
- Leaving the previous provider’s include in SPF after the moveA migration that adds Google’s include without removing the old host’s leaves a service nobody uses any more authorised to send as the domain, and spends a DNS lookup on it. Both are worth clearing out in the same change.
Questions
What people ask about this tool.
- Yes. The selector is a prefix you pick when the key is generated, and Google only calls "google" the default and recommended one. This page looks at google._domainkey, so a domain that chose its own prefix reads as having no key here even though it is signing mail correctly - check it directly with the DKIM checker instead.
- Because the two records answer different questions. MX says where mail addressed to the domain is delivered; SPF says which servers are allowed to send as it. A domain can receive every message through Workspace while authorising nobody at Google to send, which is exactly what a missing _spf.google.com include produces.
- No. Google has you publish the TXT record and then go back to the Admin console and click Start authentication; until you do, the status stays off and outgoing mail is not signed. Nothing visible in DNS distinguishes a domain that has done that from one that has not.
- Yes. Google documents a single smtp.google.com host at priority 1 now, and says older domains might have MX values starting with aspmx which still work. This checker recognises both sets and does not report the older one as a fault.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- Google, “Set up MX records for Google Workspace” read 12 October 2026
- Google, “Set up SPF” read 13 October 2026
- Google, “Set up DKIM” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.