Definition
SMTP verification: Checking whether a mailbox exists by connecting to the domain mail server, starting a normal delivery conversation and reading the reply to RCPT TO. The verifier disconnects before the DATA stage, so no email is sent.
How an SMTP verification check works
The verifier looks up the domain's MX records and connects to the preferred host on port 25. It introduces itself with EHLO, names a sender with MAIL FROM, then names the address being checked with RCPT TO.
The reply to RCPT TO is the result. 250 means the server will take mail for that address, 550 with 5.1.1 means the mailbox does not exist, and a 4xx means try later. The verifier then sends QUIT instead of DATA, so no message is ever transmitted.
Why SMTP verification sometimes gets no clear answer
Mail servers are built to receive mail, not to answer questions, and many defend themselves. Greylisting defers first contact, rate limits slow down repeated checks, and some servers block probing IPs outright.
Catch-all servers answer, but say yes to everything. A good verifier tells these cases apart instead of guessing, and returns unknown when the server gives no usable answer.
Is SMTP verification safe for my sender reputation?
Yes, when a verification service does it. The checks come from the service's own IPs and domain, not from your sending infrastructure, and recipients see nothing because no message is sent.
Running checks from your own mail server is the risky version: high volumes of RCPT TO probes from your sending IP look like directory harvesting and can get it blocked.
S: 220 mx1.example.com ESMTP
C: EHLO verify.example.net
S: 250-mx1.example.com
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<probe@verify.example.net>
S: 250 2.1.0 OK
C: RCPT TO:<no.such.person@example.com>
S: 550 5.1.1 <no.such.person@example.com>: User unknown
C: QUIT
S: 221 2.0.0 Bye How RocketVerifier handles it
Our engine looks up MX once per domain per batch, tries up to 3 MX hosts and stops before DATA, so no email is sent. Probes come from dedicated verification IPs with forward-confirmed reverse DNS and a matching HELO, under per-provider rate budgets, and replies are parsed with separate rules for Google, Microsoft, Yahoo, Mimecast, Proofpoint and Barracuda. Only an explicit SMTP answer produces deliverable or undeliverable; blocked, greylisted and timed-out checks are unknown and never charged. With a live SMTP check, the API typically answers in 1 to 3 seconds.