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 [email protected] and [email protected] 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.