- RCPT TO, defined
- RCPT TO is the SMTP command naming a message recipient, and the server's reply to it is the single most informative response in email verification because the server commits to accepting that address or refusing it.
The command is one line: RCPT TO:<someone@example.com>. What comes back is a verdict of sorts, and everything a verifier concludes hangs on interpreting it correctly.
A 550 is the clean answer, meaning no such user. A 250 means accepted, subject to the catch-all question. A 4xx means come back later, and a 252 means the server declines to check but will take the message anyway.
Multiple RCPT TO commands are allowed in one transaction, which is how a message to five people is transferred once. Verifiers do not use that, because probing several addresses on one connection is the pattern that trips rate limits.
Because the command precedes DATA, the server has decided about the recipient before any content exists. That ordering is the whole reason verification can happen without sending anything.
How ZapBounce reports it
The RCPT TO response is what our verdict is built on, and we return its literal reply code in smtp_code. When the reply was a 250 on a domain that also accepted our random-address probe, the result is catch_all rather than valid.
Three recipients, three different replies
Picture one hand-typed session against a company's mail server, asking about three people. First, RCPT TO:<amy@example.com> returns 250 2.1.5 Ok. Next, RCPT TO:<amy.old@example.com> returns 550 5.1.1 User unknown. Last, RCPT TO:<AMY@Example.COM> returns 250 again.
That third result surprises people. The standard says the part before the at-sign could be case sensitive and leaves it to the receiving server, while the domain never is. In practice nearly every mail system ignores case in both halves. A verifier shouldn't alter the local part anyway, since the address belongs to the recipient's server and changing it means asking about a different address.
The angle brackets aren't decoration. They're required syntax, and some strict servers return a 501 syntax error without them. Plus addressing passes straight through as well: RCPT TO:<amy+news@example.com> is a question about that full string, and whether it maps to Amy is decided on the far side.
What servers do when the questions keep coming
SMTP does have a command meant for checking addresses, called VRFY. Almost every server on the public internet disables it, answering 252 or 502, because spammers used it to harvest user lists. Probing with the recipient command is the workaround, and server operators know it.
So they watch for it. A client that collects several unknown-user replies in a row looks like a directory harvest attack. Common defenses are to slow each response by a few seconds more than the last, a practice known as tarpitting, or to close the connection with a 421 once an error limit is passed.
For your list, this means results depend on pacing. If a hundred addresses at one small company's domain are all checked within a minute, the later ones may get worse answers than the early ones, and the address has nothing to do with it. Any vendor you're considering should be able to tell you how they spread probes to a single domain over time.
RCPT TO: common questions
Does a 250 to RCPT TO mean the address is good?
Only if the same server rejects an address that does not exist. Without that control probe, a 250 proves the server accepts recipients, not that this one is real.
Can I check several addresses on one connection?
The protocol allows it. Verifiers avoid it because repeated recipient commands from one connection is the behavior rate limiters watch for.
Does RCPT TO deliver anything?
No. It names a recipient. Delivery would require the DATA command that follows, and a verification connection closes before that.