How verification actually works
Four steps, one of which does the real work. Knowing which is which explains why some addresses come back unresolved and why no honest verifier can fix that.
The four steps
Syntax
We parse the address against the RFC shape: a local part, an @, a domain. This catches fat-fingered typos and nothing else. A perfectly formed address for a mailbox that never existed passes this step every time, which is why regex validation on its own tells you almost nothing.
Domain and MX
We query the domain's MX records to find which servers accept its mail. No mail exchanger and no A-record fallback means nothing can be delivered there, and we stop without opening a connection. The MX host also tells us who runs the mail, which predicts how the next step will go.
The SMTP conversation
We open a connection on port 25, greet the server, name a sender, then ask about the recipient with RCPT TO. That single command is the entire test. We read the response code and close the connection, before DATA, so nothing is delivered.
The catch-all probe
We ask the same server about an address nobody could have registered. If it accepts that too, the domain is configured to take everything, and no mailbox-level verification is possible there. We label it catch-all rather than calling it valid.
What the server's answer means
One command, and a handful of codes that decide the verdict.
| Code | What the server means | How we score it |
|---|---|---|
| 250 | The server accepted the recipient. On a normal domain this is as close to certain as SMTP allows. | valid |
| 550 | No such user, or the mailbox is closed. A permanent rejection. | invalid |
| 4xx | Try again later. Usually greylisting or throttling rather than anything about the mailbox. | unknown |
| 252 | Cannot verify, but will accept. An anti-probe response that deliberately tells you nothing. | unknown |
| 530 | Authentication required. The server refuses to discuss recipients with strangers. | unknown |
| 250 on a random address | The domain accepts everything, so the specific mailbox cannot be confirmed. | catch-all |
A verifier that treats a 4xx as invalid will misclassify every greylisted domain it meets. Greylisting exists precisely to reject an unfamiliar sender once and see whether it comes back, so the honest handling is to retry and read the second answer.
The four verdicts
Unknown is one of them, reported rather than buried, and never billed.
Valid
The mailbox accepted the address at the SMTP step.
Invalid
The server rejected the address outright.
Catch-all
The domain accepts every address, so the mailbox cannot be confirmed.
Unknown
The server would not give a straight answer. We say so, and we do not bill it.
What it looks like from the API
One request, one result, and the server's own reply attached so you can audit it.
curl -s -X POST "https://api.zapbounce.com/v1/verify" \
-H "Authorization: Bearer $ZAPBOUNCE_KEY" \
-H "Content-Type: application/json" \
-d '{"email":"ada@example.com"}'
{
"email": "ada@example.com",
"result": "catch_all",
"reason": "accept_all_domain",
"domain": "example.com",
"mx_found": true,
"mx_host": "mx1.example.com",
"smtp_code": "250",
"role": false,
"disposable": false,
"free_provider": false,
"did_you_mean": null,
"billed": true,
"checked_at": "2026-09-18T10:02:41Z"
}Why some addresses cannot be resolved
Questions about the mechanism
Does verification send an email to the address?
No. We close the connection after the recipient question and before the point where a message body would be transmitted. Nothing arrives in the mailbox and nothing appears in any log the owner reads.
Do you run your own checks or resell someone else's API?
Our own SMTP check, over port 25. That is why this page can describe the conversation rather than paraphrase a supplier.
Why is a catch-all marked separately rather than valid?
Because nothing was established. The server would have accepted an address we invented on the spot. Marking that valid is the single most common way an accuracy figure gets inflated.
How long does one check take?
A DNS lookup and a short SMTP conversation, so well under a second when the server answers promptly. Greylisted domains take longer because the honest handling is to retry.
What happens with a syntactically valid address at a dead domain?
The MX step catches it. No mail exchanger and no fallback means nothing can be delivered, and it comes back invalid without an SMTP connection being opened.
Watch it run on your own addresses
100 free checks a month, no card.