Can you verify a Gmail address with SMTP?

Gmail rejects an unknown recipient at RCPT TO with 550 5.1.1, so a clean probe can show that a gmail.com mailbox does not exist. Many probes never get that far: rate limits, policy blocks and closed port 25 stop them first, and Workspace domains can route unknown addresses to a catch-all. Trueguard returns unknown with a reason instead of guessing.

The claim that Gmail accepts every SMTP probe does not hold for gmail.com. Google's own Gmail Help code list includes "550 5.1.1 The email account that you tried to reach does not exist." What a probe can prove depends on whether it reaches Gmail, whether Gmail answers about the mailbox or about the sender, and whether the domain is gmail.com or a company domain hosted on Google Workspace.

What does Gmail return at RCPT TO?

A dated practitioner transcript shows both answers. Mohamed Ibrahim published this exchange with gmail-smtp-in on stackpointer.io on 24 January 2016. It shows the reply format and is not a current capture.

RCPT TO:<404@gmail.com>
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 https://support.google.com/mail/answer/6596 v95si24868247ioi.98 - gsmtp
RCPT TO:<validemail@gmail.com>
250 2.1.5 OK a123si24991430ioe.104 - gsmtp

Gmail Help lists the 550 5.1.1 text but does not say at which SMTP stage it is returned. The transcript shows it at RCPT TO. No dated public transcript from 2025 or 2026 was found for this guide, but the 550 5.1.1 text is still on Gmail Help today.

The accepting reply has limits too. RFC 5321 section 3.3 says: "If accepted, the SMTP server returns a "250 OK" reply and stores the forward-path." Section 6.1 expects that delivery can still fail after acceptance, in which case the receiver "MUST formulate and mail a notification message." A 250 means Gmail accepted the recipient. A later bounce remains possible.

Why does an SMTP probe to Gmail get no answer?

Because many of Gmail's published replies concern the sending IP or the sender's rate, and a probe that never reaches Gmail gets no reply at all. The table lists only replies documented by Gmail Help or Google Workspace Help.

The two 421 rows are temporary. A verifier that probes once and reads either one as a mailbox result is reporting something Gmail never said. The meaning of 421 is set out in SMTP 421, and other temporary deferrals in greylisting. The mailbox-level rejection is covered in SMTP 550 5.1.1, and the policy class in SMTP 550 5.7.1.

Google does not publish a "new IP" or "cloud IP" trigger for these blocks. The published triggers are the PTR and forward-DNS check behind 4.7.0 and the unsolicited-rate check behind 4.7.28. No sourced figure was found for how often probes to gmail.com are blocked.

The free plan includes 100 email validations a month, with no card required. Get your free API key.

Why do SMTP checks from cloud servers time out?

Because the major cloud providers block outbound port 25 by default, and an SMTP probe needs it. AWS states: "By default, AWS blocks outbound traffic on port 25 for all EC2 instances and Lambda functions on elastic network interfaces." Removing the block requires a request to AWS. Google Cloud documents that "connections to destination TCP Port 25 are blocked when the destination is external to your VPC network", while "some projects do not have this restriction." Microsoft states that "The Azure platform blocks outbound SMTP connections on TCP port 25 for deployed VMs", with the exception of standard Enterprise Agreement and MCA-E subscriptions. Enterprise Dev/Test subscriptions are blocked by default, and the block can be removed. A probe from a blocked network times out, and the timeout says nothing about the mailbox.

What about Google Workspace custom domains?

A company domain on Google Workspace behaves differently from gmail.com, because its administrator controls routing. Google Workspace Admin Help describes the option: "Add a catch-all address to your routing settings to get all incoming messages like this in a single mailbox." The setting applies to "All inactive and unrecognized accounts."

Google defines a non-recognized address as "an address for a suspended user, an address for a user whose Gmail access is turned off, or an address that contains one of your verified domains but that isn't associated with a user in your Google Workspace account." With a catch-all in place, the server accepts every local part, and a RCPT TO probe reads 250 for real and made-up addresses alike. The probe cannot separate them. See catch-all domain.

Administrators can also reject mail by rule. Google states: "When messages are rejected, Gmail automatically adds an SMTP rejection code, for example 550 5.7.1." Errors produced by an administrator's custom rules carry the gcdp tag.

The vendor BounceZero reported Google Workspace at 22.9% catch-all and 0.8% unknown in its own probe sample (Catch-All Mirage study, published 13 July 2026). The figures are vendor-reported and not independently audited.

How do other large providers answer an SMTP probe?

Less is published for the other large consumer providers. The table records what each publishes on the pages read for this guide.

"Not published" means the provider's documentation read for this guide does not state it. It does not mean the provider never returns such a reply.

What should an honest verification API return?

A result that keeps the server's answer apart from the absence of one. Four statuses cover what a probe can honestly report:

• Safe: the mailbox was accepted and the domain is not accept-all, or the mailbox was confirmed by other means.
• Risky: the address is accepted but unproven, for example on a catch-all domain.
• Invalid: the server stated the mailbox is not deliverable, the 550 5.1.1 case.
• Unknown: the probe was deferred, blocked, timed out or met a policy rejection. No verdict either way.

Each non-safe result should carry the reason, so a 421 block is not read as a missing mailbox. Unknown is not invalid. Re-check later, or let a confirmation email decide. Why a headline accuracy figure says little about this unknown share is covered in email verification accuracy.

How Trueguard handles this

Trueguard's email verification API returns deliverability.status as safe, risky, invalid or unknown, with fields including isSmtpValid, isMxValid, isCatchall, isDisabled and isInboxFull. When it cannot reach a verdict, it returns unknown instead of guessing. Each non-safe result carries its reason, for example "Catch-all domain", "Could not verify", "Mailbox not found" or "Rejected by mail server". A 5xx 5.7.x policy rejection is reported as unknown, because the server blocked the check and said nothing about the mailbox. On a catch-all domain, Trueguard's advanced catch-all detection can validate the mailbox: a validated mailbox returns safe with isCatchall: true, and one that cannot be validated returns risky. Trueguard does not publish an accuracy percentage.

The free plan includes 100 email validations a month, with no card required. Get your free API key.