Google Workspace vs Gmail: tell them apart from DNS

“Sign in with Google” looks identical for a personal Gmail account and a Google Workspace account. For your product, they’re very different. Workspace accounts belong to an organization with an admin, Shared Drives, organization-level APIs and domain-wide delegation. Consumer Gmail accounts have none of that.

If your onboarding depends on any Workspace feature, you want to know which one you’re dealing with before the user hits the integration step. For a company domain, DNS tells you most of what you need. Here’s how to read it, and where it lies.

Start with the obvious: the domain

gmail.com and googlemail.com are consumer Gmail, full stop. Workspace accounts always live on the organization’s own domain (jane@acme.io). So the interesting case is a custom domain: is its mail on Google Workspace, on Microsoft 365, somewhere else, or nowhere?

Signal 1: MX records

MX records say which servers accept mail for the domain. Google uses different hosts for Workspace and for consumer Gmail.

Consumer Gmail (gmail.com):

$ dig +short MX gmail.com
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.

A Workspace domain set up the classic way (illustrative output):

$ dig +short MX acme.example
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

Newer Workspace setups often use a single record instead:

1 smtp.google.com.

Very old setups may still list aspmx2.googlemail.com and friends alongside aspmx.l.google.com.

The rule of thumb: gmail-smtp-in means consumer Gmail; aspmx or smtp.google.com means Workspace. A custom domain whose MX points at gmail-smtp-in is unusual and worth treating with suspicion.

Signal 2: mail gateways hide Google

Larger companies often put a security gateway in front of their mailboxes: Proofpoint, Mimecast, Cisco, Barracuda and others. Then MX shows the gateway, not Google:

$ dig +short MX bigcorp.example
10 mx0a-001234.pphosted.com.
10 mx0b-001234.pphosted.com.

MX alone says “corporate mail, probably a decent-sized company”, but not which suite sits behind the gateway. For that, look at authentication records.

Signal 3: DKIM at google._domainkey

Workspace signs outgoing mail with DKIM. When an admin generates the key in the Workspace admin console, the default selector is google, so the public key is published at google._domainkey.<domain>:

$ dig +short TXT google._domainkey.bigcorp.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

This is the most useful second signal: it survives mail gateways, because outgoing mail is still signed by Google. Admins can choose a different selector, so absence proves little; presence is strong.

Signal 4: SPF

SPF lists who may send mail for the domain (the SPF and DMARC checker shows a domain’s record and its includes). Workspace domains usually include Google:

$ dig +short TXT acme.example | grep spf
"v=spf1 include:_spf.google.com include:mailgun.org ~all"

include:_spf.google.com is a medium-strength signal: it means Google sends mail for the domain, which is almost always Workspace. The other includes are interesting too: business SaaS senders (HubSpot, Salesforce, Zendesk, Mailgun, SendGrid…) are a decent hint that the domain belongs to a functioning company.

Weak signals, and why they’re weak

• google-site-verification= TXT records. Workspace uses them for domain verification, but so does Google Search Console. Plenty of non-Workspace domains have one.
• ghs.googlehosted.com CNAMEs. Legacy Google Sites and custom URL setups. Historical, not current.

Use these to break ties, never on their own.

Where DNS misleads you

DNS describes the domain’s mail setup. It doesn’t describe the person typing the address. Known gaps:

1. Consumer Google accounts on custom domains. Anyone can create a Google account using an existing non-Gmail address. That account has no Workspace behind it, whatever the domain’s DNS says. If such an account predates the company adopting Workspace, Google calls it a “conflicting account”.
2. Identity without mail. A company can use Google for identity (Cloud Identity) while its mail runs elsewhere. DNS may show only a verification token.
3. Migrations and split delivery. Mid-migration, MX points one way while DKIM and SPF point the other. Some companies route some mailboxes to Google and others elsewhere.
4. Both Google and Microsoft. Identity on Microsoft Entra ID, mail on Google (or the reverse) is common. Check for both; don’t treat them as exclusive.

Putting the signals together

No single record is conclusive, so combine them. A practical reading:

MX	DKIM google._domainkey	SPF _spf.google.com	Reading
aspmx / smtp.google.com	any	any	Google Workspace
Security gateway	present	any	Workspace behind a gateway
Security gateway	absent	present	Probably Workspace; confirm another way
Microsoft 365	present	present	Mixed setup or migration: check both suites
Other host	absent	present	Google sends mail for the domain; mailboxes may live elsewhere
gmail-smtp-in	any	any	Odd for a custom domain: treat as personal or review
None	any	any	Can’t receive mail: invalid

When the evidence conflicts, say “unknown” and route the user to a review lane rather than guessing. A wrong “this is Workspace” costs you more than a cautious “we’re not sure”.

The sign-in signal: the hd claim

If the user signs in with Google, you get a much better per-person signal than DNS: Google’s ID token includes an hd (hosted domain) claim only for Workspace accounts. A consumer account, even one with a custom-domain address, has no hd.

A robust setup uses both:

• Email/password or magic-link signup: classify the domain from DNS.
• Google sign-in: check hd. No hd means a consumer account, whatever the address.

You can also pass hd=acme.io when starting Google OAuth to hint which Workspace domain you expect. Treat it as a UX hint and still validate the claim in the token.

A small classifier

Here’s the core logic in Node, using DNS-over-HTTPS (Cloudflare’s JSON API), so it runs anywhere fetch does:

const TYPE = { MX: 15, TXT: 16 };

async function resolve(name, type) {
  const url = `https://cloudflare-dns.com/dns-query?name=${encodeURIComponent(name)}&type=${type}`;
  const res = await fetch(url, { headers: { accept: 'application/dns-json' } });
  if (!res.ok) throw new Error(`DoH ${res.status}`);
  const body = await res.json();
  return (body.Answer ?? []).filter((a) => a.type === TYPE[type]).map((a) => a.data);
}

export async function googleSignals(domain) {
  const [mx, txt, dkim] = await Promise.all([
    resolve(domain, 'MX'),
    resolve(domain, 'TXT'),
    resolve(`google._domainkey.${domain}`, 'TXT'),
  ]);
  const hosts = mx.map((r) => (r.split(' ')[1] ?? '').toLowerCase().replace(/\.$/, ''));

  return {
    consumerGmail: hosts.some((h) => h.endsWith('gmail-smtp-in.l.google.com')),
    workspaceMx: hosts.some((h) => h === 'smtp.google.com' || h.endsWith('aspmx.l.google.com')),
    googleSpf: txt.some((t) => t.includes('include:_spf.google.com')),
    googleDkim: dkim.some((t) => t.includes('v=DKIM1')),
  };
}

Then decide: workspaceMx || googleDkim is a strong Workspace signal; googleSpf alone is medium; consumerGmail on a custom domain deserves a closer look.

Production versions need more: timeouts and fallbacks when DNS is slow, looking up the registrable domain (mail.acme.co.uk → acme.co.uk), caching, and the same treatment for Microsoft 365 so you can handle mixed setups. Check for a business email in JavaScript, Python and PHP covers the do-it-yourself route in more detail.

Or let us do it

That’s what /v1/check does, along with Microsoft 365 tenant detection, disposable and relay detection, and a policy-based recommendation:

curl -sG https://api.isbusinessemail.com/v1/check \
  --data-urlencode "email=workspace@test.isbusinessemail.com"

The workspace.google_workspace.evidence array tells you which of the signals above matched. Try a real domain with the Google Workspace checker, or read how detection works.