How SMTP Email Verification Works (Without Sending an Email)
By Aria Pramesi, founder of InboxPolicy · Updated July 10, 2026
SMTP verification is a partial email conversation: a verifier connects to the recipient domain's mail server, works through HELO/EHLO, MAIL FROM, and RCPT TO, then disconnects with QUIT, stopping before the DATA command that would actually transmit a message. The receiving server's response to RCPT TO, usually 250 or 550, reveals whether it would accept mail for that exact address. No email is sent, no inbox is touched, and the target never sees a thing.
The verification pipeline
A single verification call runs four checks in order, and most invalid addresses get filtered out before an SMTP connection ever opens.
1. Syntax validation
RFC 5321 and RFC 5322 technically permit a wider grammar than anything you'd actually want to send mail to: quoted local parts, escaped characters, unusual but legal address forms. Verifiers generally check against a stricter, practically-deliverable pattern instead of the full legal grammar, and reject obvious malformations locally, before any network call, at no cost.
2. DNS and MX resolution
The verifier looks up the domain's MX records and sorts them by preference. If none exist, RFC 5321 §5.1 says a sending server SHOULD fall back to the domain's A/AAAA record as an implicit MX at preference 0, a legacy behavior from before MX records existed. Because it's a SHOULD rather than a MUST, not every sender honors it, and its presence alone isn't a strong signal either way. If the domain instead publishes a null MX, a single MX record at preference 0 pointing to "." per RFC 7505, that's an explicit statement that the domain accepts no mail at all, and verification stops there as a hard fail.
3. The SMTP handshake
With a mail server resolved, the verifier opens a real SMTP connection and runs through the same opening moves any sending mail server would use, minus the message itself:
220 mx.example.com ESMTP ready EHLO verify.inboxpolicy.com 250-mx.example.com Hello verify.inboxpolicy.com 250-SIZE 35882577 250 8BITMIME MAIL FROM:<[email protected]> 250 2.1.0 OK RCPT TO:<[email protected]> 250 2.1.5 OK QUIT 221 2.0.0 Bye
The connection closes right after that exchange. DATA, the command that would start transmitting an actual message body, is never sent. If the mailbox doesn't exist, the same conversation instead returns a rejection at the RCPT TO step:
RCPT TO:<[email protected]> 550 5.1.1 The email account that you tried to reach does not exist
4. Reading the response
The RCPT TO response code is the actual verdict:
- 250 / 251 — accepted. The server is willing to take mail for this address, though a catch-all domain will return this for every address regardless of whether the mailbox is real (more below).
- 550 / 551 / 553 — permanently rejected. The mailbox doesn't exist, or the server refuses to relay for it.
- 4xx (421, 450, 451, 452) — temporary failure. Could be greylisting, rate limiting, or the server being briefly unavailable. This is not a rejection; it means "ask again later."
Where SMTP verification hits its limits
This is the part vendors tend to gloss over, but it's the difference between a status field and a decision you can actually act on.
Catch-all domains. A catch-all domain accepts RCPT TO for any address, real or not, so a clean 250 doesn't confirm a specific mailbox exists on one. Roughly 30-40% of B2B domains are configured this way. See how catch-all verification works for the full mechanics.
Greylisting. A receiving server can temporarily defer mail from a sender it doesn't recognize, returning a 4xx response and expecting a retry after a delay, a practice documented in RFC 6647. A verification attempt caught mid-greylist reads as neither accepted nor rejected; the correct move is a retry, not a bounce.
Protective gateways. Many organizations route inbound mail through a filtering gateway in front of the actual mailbox server. These gateways commonly accept at the SMTP edge and evaluate the message afterward, so a 250 from the gateway doesn't guarantee the eventual mailbox exists or that content-based filtering won't still drop the message.
Port 25 blocking. SMTP verification happens on port 25, and most cloud providers and consumer ISPs block outbound port 25 by default specifically to stop spam from compromised machines. That's why verification can't run from a browser, a laptop, or a typical cloud instance, it requires dedicated infrastructure with clean IP reputation and an actual port-25 route to the wider internet.
How results map to a send decision
A response code alone doesn't tell you what to do next. InboxPolicy maps the SMTP evidence, plus catch-all and greylisting signals, onto one of five explicit actions instead of leaving that translation to you:
- send — clean 250 accept, no catch-all or greylisting evidence.
- send_with_caution — accepted, but on weaker evidence, or a catch-all domain under an aggressive policy.
- review — catch-all evidence by default; the mailbox may or may not exist and SMTP alone can't resolve it.
- retry_later — a 4xx response, most often greylisting, where a retry after a delay is the correct next step.
- avoid — a 550-class rejection, a null MX domain, or syntax that never deliverable to begin with.
See the full send decision framework for how evidence, confidence, and action are combined for every case, and the developer integration guide for the request/response shape.
Frequently asked questions
Can you verify an email address without sending an email?
Yes. A verifier opens a real SMTP connection to the recipient's mail server, sends HELO/EHLO, MAIL FROM, and RCPT TO, then disconnects with QUIT before the DATA command that would actually transmit a message. The server's response to RCPT TO reveals whether it would accept mail for that address without any message ever being sent or arriving in an inbox.
What is greylisting in email verification?
Greylisting is an anti-spam practice, documented in RFC 6647, where a receiving server temporarily rejects mail from an unfamiliar sender with a 4xx response and expects a retry after a delay. During SMTP verification it shows up as a temporary failure rather than a clean accept or reject, and the correct response is to retry later, not to treat the address as invalid.
Why can't I verify emails from my own server?
Most cloud providers and consumer ISPs block outbound connections on port 25 by default to stop spam from compromised machines, and port 25 is the port SMTP verification runs on. Without it, you cannot open the connection needed to send RCPT TO at all, which is why SMTP-level verification requires dedicated, reputation-managed infrastructure rather than a laptop or a typical cloud instance.
Is SMTP verification 100% accurate?
No. Catch-all domains accept RCPT TO for any address, so a 250 response doesn't confirm a specific mailbox exists, and protective mail gateways commonly accept at the edge and filter afterward, which SMTP can't see. A meaningful share of addresses are structurally unresolvable by SMTP alone, which is why a send decision built from all the evidence beats treating a raw status as a verdict.
What's the difference between a 550 rejection and a greylisting response?
A 550 (or 551/553) is a permanent failure: the server is telling you, right now, that this mailbox does not exist or will never accept this mail. A 4xx response during greylisting is a temporary failure: the server is asking to be tried again later. Treating a greylisting response like a hard bounce discards addresses that would have verified cleanly on retry.