uCheckeruChecker

What is SMTP verification

SMTP verification is a way to check whether an email address exists by connecting directly to the recipient's mail server. No message is sent: the connection closes before any data is transmitted.

How it works

The validator looks up the domain's MX record, opens a TCP connection on port 25, and runs three SMTP commands:

  1. EHLO — sender identification.
  2. MAIL FROM — a technical sender address.
  3. RCPT TO — the address being checked. This is where the server says whether it will accept the mailbox.

The DATA command is never sent. The connection closes right after the RCPT TO response is received.

Response codes

  • 250 — address exists, server is ready to accept mail.
  • 550 — mailbox not found or blocked; the address is invalid.
  • 450 — temporary rejection, often greylisting; the server is asking the sender to retry later.

Limitations

SMTP verification is not bulletproof. Three problems come up regularly:

  • Greylisting — the server returns 450 on the first request from an unknown IP. Without a retry, a perfectly valid address looks suspicious.
  • Catch-all domains — the server accepts mail for any address in the domain, including ones that do not exist. A 250 response tells you nothing.
  • Rate limiting — mail providers cap the number of SMTP connections from a single IP. In bulk verification runs, some requests will get rejected.

SMTP verification in uChecker

uChecker runs SMTP verification as one step in a multi-stage validation pipeline. Syntax, DNS, and MX records are checked first. After the SMTP handshake, additional signals are analyzed: catch-all status, presence in disposable email lists, and role-based addresses. The final result is a weighted deliverability score, not just a raw 250 or 550.

Why the server's answer is not always the truth

A 250 means "I will accept mail for that box", not "that box exists and someone reads it". The gap shows up on catch-all domains, where the server answers affirmatively for any address, including one you invented. The only way to detect this is a control probe with a random string — if that is accepted too, the domain is catch-all and the verdict on your actual address means nothing.

The opposite mistake is common as well. A 450 or 451 is not a rejection but a request to come back later: greylisting or a rate limit. Filing that address as dead is wrong; the check needs repeating in a few minutes.

What gets in the way

Large providers have long been wary of SMTP probes. Yahoo and many corporate servers answer 250 to everything so as not to disclose which mailboxes exist. Gmail rate-limits queries from a single address and goes quiet once you exceed it. So verification needs a pool of IPs with decent reputation — from one server it stops working within the first thousand addresses.

Which yields a practical test: the share of "unknown" verdicts in a report is a quality signal. Zero unknowns does not mean perfect accuracy; it means the ambiguous cases were quietly filed as valid.

When not to run the check

Every SMTP probe opens a connection to somebody else's server, so re-checking the same address without cause is pointless and costs reputation on the probing pool. A sensible cadence: check on entry into the list, then again before a large send if the address has been untouched for months.

A separate case is addresses that already hard bounced. Those are not re-checked but removed outright — the server has stated the mailbox does not exist, and a second opinion adds nothing.

SMTP verificationSMTP validationRCPT TOEHLOemail validation
← All terms