Gmail Email Verification

What Gmail's MX records look like

Any domain hosted by Google, whether it is gmail.com itself or a Google Workspace tenant on a custom domain, publishes MX records pointing at Google's inbound cluster. The canonical primary host is aspmx.l.google.com, usually accompanied by backup hosts such as alt1.aspmx.l.google.com and alt2.aspmx.l.google.com at higher priority numbers. Some tenants front their mail with a third party security gateway, in which case the MX points at the gateway instead and the real Google endpoint sits behind it. Mailthentic detects Google hosting from the MX chain rather than from the domain name, so a company running Workspace on its own domain is correctly identified as Google infrastructure.

How Gmail answers an SMTP probe

This is the part that matters. Google's inbound servers accept the RCPT TO command with a 250 response for addresses that do not exist. The connection completes normally, the server sounds happy, and nothing about the conversation distinguishes a real mailbox from a fabricated one. This is not a bug and it is not something a verification tool can engineer its way around. It is a deliberate anti harvesting measure: if Google rejected unknown recipients at RCPT TO, anyone could enumerate valid Gmail addresses at scale simply by walking through a dictionary.

Google does its recipient decision later. If the address does not exist, the message is accepted at the SMTP layer and then bounced afterwards with a Non Delivery Report, typically carrying a 550 5.1.1 style code inside the NDR body. That bounce only happens if you actually send a message, which a verification probe never does.

Why a Gmail mailbox cannot be confirmed by SMTP

Because every recipient gets the same 250, an SMTP probe against Gmail carries no information about whether the individual mailbox exists. Mailthentic runs a catch all detection pass anyway: it probes the domain with a randomly generated local part that could not plausibly belong to anyone. Google accepts it, which confirms the accept all posture. From that point, honesty requires reporting the address as accept-all and unconfirmed rather than dressing the 250 up as a valid verdict. Any verification vendor that returns a confident valid for a Gmail address is inferring, guessing, or lying.

Mailthentic still extracts real value from a Gmail probe. It confirms that the domain resolves and that its MX hosts are reachable and answering, it identifies the address as Google hosted, it applies syntax and normalisation rules specific to Gmail such as dot insensitivity in the local part and the +tag convention, it flags disposable and role based addresses, and it checks the address against bounce feedback already known to the system. What it will not do is manufacture certainty that the protocol did not give it.

Rate limiting, deferrals and greylisting

Google will throttle a source IP that opens a large number of connections in a short window. When that happens the response is a temporary one, typically in the 421 or 451 family, and it means slow down, not this address is bad. Mailthentic treats 421, 450 and 451 as deferrals and retries with a backoff before making any decision, and it throttles probes per MX cluster rather than per domain so that a burst of different Workspace tenants does not all pile onto the same Google endpoint at once. A temporary deferral is never converted into an invalid verdict.

So what does a Gmail result actually mean?

A clean Gmail result from Mailthentic means the domain is real, Google hosted, correctly configured, the address is well formed, it is not disposable, and no bounce history counts against it. It does not mean somebody is sitting behind that mailbox. Treat it as a domain level clearance with an unresolved recipient, and use the rest of the signals below to decide whether to mail it.

Read the verdict for what it is

On Gmail, an accept-all or unknown verdict is the correct and expected outcome, not a failure of the verification. It tells you the domain is sound and the address is deliverable at the transport layer, and that mailbox existence is undecidable over SMTP. Do not treat it as risky in the way you would treat an accept-all verdict on an obscure self hosted domain, because on Google you already know exactly why the answer is ambiguous.

Send, but earn the send

For most senders the right call is to keep syntactically clean, non disposable, non role Gmail addresses in the list and mail them, while accepting that a small share will bounce back as Non Delivery Reports. The way you keep that safe is on the sending side rather than the verification side:

• Warm up gradually. Gmail judges a sending IP and domain by its behaviour over time. A cold IP that suddenly pushes tens of thousands of messages will get throttled or filtered regardless of how clean the list is.
• Process bounces immediately. Google's NDR is the only authoritative answer you will ever get about a Gmail mailbox. Feed those bounces straight back in and suppress the address permanently. Mailthentic's bounce feedback loop exists precisely to close this gap.
• Keep your complaint rate low. Gmail weighs spam complaints heavily. A high complaint rate will hurt you far more than a handful of unknown addresses ever will.
• Authenticate properly. SPF, DKIM and a DMARC policy on your sending domain are effectively mandatory for bulk mail to Google.

Prune on signals SMTP cannot give you

Since the protocol will not tell you whether the mailbox exists, use the signals that are actually available. Remove role addresses such as info@, admin@ and support@ unless they are genuinely your audience, since these attract complaints. Remove addresses that have bounced before. Remove disposable and throwaway domains. Watch engagement: a Gmail address that has never opened or clicked across many campaigns is far more likely to be dead or abandoned than any SMTP probe could reveal, and Google reads that lack of engagement as a negative signal against you.

Verify at the right moment

Verify at the point of capture, on the signup form, so bad addresses never enter the database, and re verify the whole list before a large campaign. For Gmail the point of the pre send pass is to catch typos, disposables and known bouncers, not to re litigate mailbox existence, which will still come back unconfirmed.

Be sceptical of vendors who claim more

If a verification service returns a confident valid for an arbitrary Gmail address, it is not reading the SMTP conversation, because the SMTP conversation does not contain that answer. Mailthentic would rather tell you the truth about what is knowable than sell you a number that a technical reader can disprove in one telnet session.