The verification handshake

The check follows the SMTP handshake in RFC 5321. The verifier connects to the domain’s mail server on port 25, identifies itself (HELO/EHLO), declares a sender address (MAIL FROM), and then declares the recipient address (RCPT TO). The server’s response to RCPT TO reveals whether the mailbox exists — a 250 response typically means it does, a 550 means it doesn’t — before the message is ever actually queued or sent (the verifier disconnects before the DATA stage).

HELO verifier.example.com
MAIL FROM:<probe@verifier.example.com>
RCPT TO:<user@target-domain.com>
250 2.1.5 OK          ← mailbox likely exists

Why this requires port 25 access

Most cloud hosting providers (AWS, GCP, DigitalOcean, and most residential ISPs) block outbound port 25 by default to prevent spam abuse, which is why dedicated infrastructure — a fleet of VPS nodes with established sending reputation — is required to run SMTP checks at scale reliably. This is also why you generally can’t verify emails from a typical application server without routing through a dedicated verification service.

Limitations of SMTP verification alone

Catch-all domains, greylisting, and servers that accept all RCPT TO commands regardless of validity (to prevent address-enumeration attacks) can all produce ambiguous results from SMTP checks alone. This is why a full verification pipeline combines SMTP with syntax validation, DNS/MX lookups, disposable-domain detection, and catch-all confidence scoring rather than relying on the SMTP response in isolation.

What a 4xx vs 5xx response means

SMTP response codes starting with 4 (like 450, 451) are temporary failures — greylisting, rate limiting, or a server being momentarily unavailable — and should be retried. Codes starting with 5 (like 550, 553) are permanent failures, meaning the server has definitively rejected the address. Treating a 4xx as a hard failure is a common mistake that inflates false-invalid rates.