Can you verify catch-all emails?

No, and nothing can. A catch-all server answers 250 to every address, so the reply carries no information about the individual mailbox. VerifyInbox reports these as unknown with the reason catch_all rather than letting the 250 pass as a confirmation.

How accurate is email validation, and can it catch catch-all domains?

Catch-all domains are detected by asking the server about an address that cannot exist: if it is accepted, the domain accepts everything. That detection is reliable. What is not possible is confirming an individual mailbox on such a domain, and any accuracy figure that does not separate the two cases is not measuring anything useful.

How do SMTP codes work?

Each command in an SMTP conversation gets a three-digit reply: 2xx success, 4xx transient failure, 5xx permanent failure. Most servers add an enhanced code of the form class.subject.detail, registered with IANA, saying which part of the system was involved and what happened.

SMTP reply code

250 2.0.0 — accepted — but not always a confirmation

Q: Can an email sent to a "valid" address bounce?

Yes. A 250 at RCPT TO is a statement about that moment: the server would accept mail for that recipient. The message can still be rejected at DATA, filtered after acceptance, or bounced by a downstream system. And on a catch-all domain the 250 was never a confirmation in the first place.

A 250 reply means the receiving server accepted the recipient address. On an ordinary domain that confirms the mailbox exists. On a catch-all domain the server answers 250 to every address, so the reply describes the domain rather than the mailbox.

The facts

Reference facts for SMTP 250 2.0.0
Field	Value
Reply code	`250`
Enhanced status code	`2.0.0`
Class	2 — success
Subject	0 — other or undefined status
Detail	0 — other undefined status
Bounce type	Not a bounce
Should the sender retry?	No
Representative wording	`250 2.1.5 Ok`

The representative wording is one real form of this reply. The exact string is set by the receiving server and varies between mail platforms — read the one in your own logs rather than matching on a string.

What VerifyInbox returns

What VerifyInbox returns for SMTP 250 2.0.0
Field	Value
On an ordinary domain	`deliverable` / `mailbox_exists`, `mailboxStatus: "valid"`. Charged 0.5 credits.
On a catch-all domain	`unknown` / `catch_all`, `mailboxStatus: "catch_all"`, `catchAll: true`, `retryable: false`. Charged 0.5 credits — the probe established how the domain behaves.
Role or disposable address that answers 250	`deliverable`, with `roleAccount` or `disposable` set as a flag. A classifier describes the address; it never changes the verdict.
`smtpCode` / `smtpEnhancedCode`	`250` / whatever the server sent, commonly `2.1.5`

The most misunderstood reply in email

Every other page in this family explains a failure. This one explains a success, and it is the most valuable of the set, because "it returned 250" is not the same claim as "the mailbox exists" — and the entire category is built on treating them as identical.

On an ordinary domain the two do coincide. The server looked the local part up, found a mailbox, and said it would accept mail for it. That is about as good as verification gets.

On a catch-all domain the server is configured to accept mail for any local part. Ask it about jane.doe@ and it says 250. Ask it about qx7zzz-not-a-real-person@ and it says 250 as well. The reply is identical, and it carries no information about the individual mailbox. Any tool reporting that as a confirmed deliverable is reporting a guess with a confident label on it.

A note on the enhanced code

Servers vary here more than they do on failures. The enhanced code you will most often see beside a 250 on a RCPT TO is 2.1.5, registered as "Destination address valid" — which is the precise one. 2.0.0, "other undefined status", is the generic form, and plenty of servers send a bare 250 Ok with no enhanced code at all.

None of that changes anything. The verdict comes from the 250, and the question of whether it means the mailbox exists is settled by whether the domain accepts everything — not by which enhanced code was attached.

The three-digit reply code comes from RFC 5321: a 2yz is a success, a 4yz is a transient failure the sender should retry, and a 5yz is a permanent failure the sender should not repeat in the same form. The dotted code beside it comes from RFC 3463 and has three parts — class.subject.detail — where the class repeats 2, 4 or 5, the subject says which part of the system had the problem, and the detail says what it was. The full list is an IANA registry established by RFC 5248, which is the authoritative source and the one nothing else ranking for these queries cites.

Why a 250 does not guarantee delivery either

Accepting a recipient at RCPT TO is a statement about that moment and that conversation. The message can still be rejected at DATA, filtered after acceptance, or bounced later by a downstream system the gateway forwards to. "Accepted" means the server took responsibility for the message, not that a person read it.

This is the honest limit of verification, and it is worth stating plainly: a verifier tells you whether an address is real. It cannot tell you whether mail will land in the inbox rather than the spam folder, and nobody selling you that as a verification feature is measuring it.

What to do

If you are sending

A confirmed deliverable is the strongest signal available before a send. Use it.
Treat a catch-all unknown as a different segment, not as a slightly worse deliverable.
Re-verify close to the send rather than on a calendar — a 250 describes the moment it was received.

If you own the domain

Accepting everything costs you the ability to tell anyone which of your addresses are real, including partners verifying before they contact you.
If you use a catch-all for typo tolerance, consider a short alias list instead.
Rejecting unknown recipients at RCPT TO also stops your server generating backscatter.

If you are a developer

Never treat 250 as a mailbox confirmation without checking the catch-all flag. It is the single most common integration error in this category.
Branch on emailStatus first, then on reason. catch_all is unknown for a reason.
Keep the smtpCode and smtpEnhancedCode on your own records. When a "verified" address bounces later, they are the only evidence of what was actually established.

To find out whether an address will return this before you send to it, run it through the free email verifier

Related codes

Related terms

Sources

Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.