How SMTP Email Verification Works
SMTP verification connects directly to the domain's mail server and starts a real mail transaction — EHLO, then MAIL FROM, then RCPT TO for the target address — but stops before the DATA command, so no email is ever sent. The mail server's response code to RCPT TO (2xx, 4xx, or 5xx) indicates whether it's willing to accept mail for that address. It's the only verification layer that asks about the specific mailbox rather than just the domain — and it's still not a guarantee, because many providers deliberately accept everything at this stage and bounce later, or run infrastructure designed to resist exactly this kind of probing.
The actual SMTP conversation
SMTP verification is a real, minimal mail transaction, sent to the domain's primary mail server (the highest-priority MX record):
→ (connect to MX host, port 25) ← 220 mx.example.com ESMTP ready → EHLO verify.emailriskradar.com ← 250-mx.example.com Hello → MAIL FROM:<> ← 250 OK → RCPT TO:<person@example.com> ← 250 OK (or 550 No such user, or 450 temporarily unavailable) → QUIT
Two details matter here. First, MAIL FROM uses a null/empty sender (<>) — the standard, low-risk convention for bounce and verification probes, the same envelope sender real mail servers use for bounce notifications. Second, and critically: DATA is never sent. No email content is transmitted, no message is delivered — the transaction ends at QUIT, right after the server's response to RCPT TO. Nothing is ever sent to the mailbox owner.
Reading the RCPT TO response code
| Response code range | Meaning | Interpretation |
|---|---|---|
| 2xx | Accepted | The server will take mail for this address |
| 5xx | Permanently rejected | No such mailbox — a hard, confident rejection |
| 4xx or anything else | Inconclusive | Temporary issue, greylisting, rate limiting — doesn't confirm anything either way |
Only the 2xx and 5xx cases produce a confident answer. A 4xx response, a connection timeout, or a server that blocks the probe outright all fall back to an unknown result — an honest "we couldn't determine this," rather than a false confident answer, which matters more than it sounds: reporting a guess as a fact is worse than reporting no answer.
Detecting catch-all domains in the same transaction
Some domains accept mail for any address at all — a catch-all configuration — which makes a 2xx response to RCPT TO meaningless as confirmation of a specific mailbox. This is detected within the same SMTP session: if the real address wasn't already rejected, a second RCPT TO is sent for a random, almost-certainly-nonexistent address at the same domain (something like verify-probe-<random hex>@domain.com). If the server accepts that address too, the domain is catch-all, and the original "accepted" result gets downgraded to unknown, because acceptance no longer means anything specific about the real address — see "How Catch-All Email Domains Work" for more on why this happens.
Why this only runs in full mode
Fast and standard modes never open an SMTP connection at all — only full mode does, and only when the domain has at least one MX record to connect to. This is deliberate: SMTP verification is the slowest layer (a live network round-trip to a third-party mail server, sometimes multiple seconds), it's the layer most likely to be rate-limited or blocked by receiving servers if run indiscriminately, and it's not needed for most checks. It's reserved for the specific requests that actually call for it.
Protecting the mail server being probed — and your own request budget
Running SMTP checks carelessly can look like abuse to the receiving mail server and get the checker's IP blocked. Several protections apply on every full-mode check:
- Only the primary (highest-priority) MX host is tried, never the full MX list — falling back through every mail server on a domain that's already struggling multiplies load on exactly the server having trouble
- A per-domain circuit breaker opens after repeated failures against the same domain within a rolling window, and stays open for a cooldown period — once a domain looks unreachable or hostile to probing, it stops being probed for a while, automatically
- Per-domain and global concurrency caps prevent too many simultaneous connections to any one mail server or in total
- Results are cached by a hash of the address (never the raw address itself) for a configured TTL, so the same mailbox isn't re-probed on every request
The full status vocabulary
| Status | Meaning |
|---|---|
| accepted | 2xx response to RCPT TO, and the domain isn't catch-all |
| rejected | 5xx response to RCPT TO — confident, permanent rejection |
| unknown | 4xx/ambiguous response, catch-all domain, or SMTP verification wasn't run (fast/standard mode, or no MX) |
| blocked | The mail server refused the connection, EHLO, or MAIL FROM outright — it's not cooperating with the probe at all |
| timeout | No response within the time budget |
The practical takeaway
SMTP verification is genuinely the closest you can get to confirming a specific mailbox without sending mail — but it's a probabilistic signal layered on top of DNS and domain checks, not a ground-truth oracle. Major consumer providers in particular often behave conservatively at this layer specifically to resist exactly this kind of probing. Treat accepted and rejected as strong evidence, and treat unknown as genuinely unknown rather than a soft "probably fine."
FAQ
No. The transaction stops after RCPT TO, before the DATA command. No message content is ever transmitted and nothing is delivered to the mailbox.
Yes, in both directions. Some servers accept everything at RCPT TO and bounce later (see Why Valid Emails Can Still Bounce); some reject probes from unfamiliar senders regardless of whether the mailbox is real. It's strong evidence, not proof.
MX records are priority-ordered, and the primary server is authoritative for accept/reject decisions in almost all real configurations. Trying every server in the list mostly just adds load and latency without adding accuracy.
The check returns timeout or blocked rather than guessing, and a per-domain circuit breaker prevents repeatedly hammering a struggling or unreachable server with further connection attempts.