# Google Workspace and Gmail: MX records and email verification

How Google-hosted domains look in DNS, how Gmail answers an SMTP verification handshake, and which verdicts and reasons to expect for Google addresses.

Updated: 2026-09-03

Google hosts more mailboxes than any other provider, split between consumer Gmail and Google Workspace on company domains. Both run on the same inbound infrastructure, so Spaw reports them under one `mx_provider` value: `google`.

## How Google shows up in DNS

A Google-hosted domain publishes MX records under `l.google.com` or, for newer Workspace setups, the single host `smtp.google.com`. Gmail itself resolves to `gmail-smtp-in.l.google.com` and its `alt1` to `alt4` siblings; Workspace domains set up before 2023 typically use `aspmx.l.google.com` with `alt1.aspmx.l.google.com` and so on, and Google's current setup guide recommends the one-record form, `smtp.google.com` at priority 1.

Spaw matches either pattern and returns `mx_provider: "google"`. Google is a mailbox host: the MX points at the servers that store mail, not at a filtering layer in front of somebody else's servers. `mx_found` is true, `mx_implicit` is false, and `has_spf` and `dmarc_policy` describe the domain's own records.

## How Google answers a verification handshake

Google answers the recipient check honestly and quickly. When the SMTP handshake reaches `RCPT TO` for an address that does not exist, Gmail and Workspace both reject it in the session, typically with a `550 5.1.1` reply that says the address was not found. A mailbox that exists is accepted at the same step. Greylisting and silent throttling are uncommon for a single well-formed probe, so an answer usually arrives on the first attempt.

Workspace domains can be configured as catch-all by an administrator, but that is the exception: the default rejects unknown recipients. Google also treats dots in Gmail usernames as insignificant and delivers plus-tagged addresses to the base mailbox, which is why Spaw folds both into `normalized_email` before it does anything else.

## What that means for your verdicts

For Google addresses you should mostly see clean answers: `deliverable` with `mailbox_exists: true`, or `undeliverable` with `reason: mailbox_not_found` and `smtp_reason: no_mailbox`. Catch-all answers are rare and, when they appear, come from a Workspace domain whose admin turned the option on; Spaw then remembers the domain as catch-all for seven days and returns `mailbox_confidence` instead of spending more probes on it.

Two things happen before any probe for the consumer domains gmail.com and googlemail.com. First, Google's own username rules apply: Gmail usernames contain only letters, digits and dots, and are at most 30 characters once the dots are removed. An address that breaks those rules is answered `undeliverable` with `reason: invalid_local_part` without a handshake. Second, dots and plus-tags are normalised, so `m.ia+news@gmail.com` and `mia@gmail.com` share one cache entry and one suppression entry.

A `google` provider also adds ten points to `mailbox_confidence` when a probe could not settle a mailbox, because an established provider with strict signup rules makes a plausible-looking address more likely to exist.

## SPF and DMARC at Google

Google Workspace tells domain owners to publish `v=spf1 include:_spf.google.com ~all` and to add a DKIM key from the admin console. Consumer Gmail users have nothing to configure; gmail.com itself publishes SPF and a DMARC policy. On a Workspace domain, a missing SPF record shows up in Spaw as `has_spf: false` and costs the address ten risk points; `dmarc_policy` reports `none`, `quarantine` or `reject` from the live record.

## Practical notes for sending to Google users

Google enforces sender authentication on the receiving side: since 2024 bulk senders to Gmail need aligned SPF or DKIM, a DMARC record, one-click unsubscribe and a low complaint rate, so a list full of unverified Gmail addresses is expensive in two ways. Role inboxes such as `info@` on Workspace domains exist and are probed like any other address; Spaw still flags them `risky` with `reason: role` because a shared inbox is not a person. Plus-tags are safe to send to, but Spaw reports `is_alias: true` so you can decide whether to keep the tagged form.

For a live look at any Google-hosted domain, run it through the free MX lookup and the SPF and DMARC checker.

Reference: https://spaw.co/email-providers/google