The four layers
Verification is a stack, cheapest first. Syntax — is the string shaped like an address. Domain — does the domain exist and publish MX records, or at least an A record a server could fall back to. Mailbox — the SMTP conversation below. Classification — is the domain disposable, is the local part a role like info@, is the domain free-mail, is the address a known spam trap. The first two cost nothing and remove a third of a raw list. The third is the one that needs a network conversation.
The SMTP conversation
The verifier connects to the domain's lowest-priority MX host on port 25, introduces itself with EHLO, gives a harmless MAIL FROM, then sends RCPT TO:<the address>. The server's reply to that one line is the answer: 250 means it will accept mail for the mailbox, 550 (or a 5.1.1 enhanced code) means the mailbox does not exist, and a 4xx means try later — greylisting, or a server that hides mailbox status. The verifier then sends QUIT. No DATA command is ever issued, so no message exists.
What each status means
Valid / safe: the server accepted the exact mailbox and nothing else is wrong. Invalid: the server said the mailbox does not exist; remove it. Catch-all: the server accepts every address, so the answer is uninformative — a separate page covers it. Unknown: greylisting, a timeout, or a provider that refuses to say; retry later, do not assume bad. Disposable: a temporary-inbox provider; remove. Role: info@, sales@ and the like; exists, but read by a queue rather than a person. Spam trap: a known trap address; one send can get a domain listed.
Where it goes wrong
Consumer providers — Gmail, Outlook.com, Yahoo — rate-limit and sometimes block verification connections, and their answers are unreliable at volume, which is why verifiers treat them separately and why B2B verification is the reliable case. Greylisting makes the first attempt fail on purpose; a good verifier retries. And catch-all domains, about one in five, give a yes that means nothing. None of these is a reason not to verify; they are reasons to read the status rather than a green tick.
Verification versus validation
Validation is the first two layers: shape and domain. It runs in a browser and removes the obviously dead. Verification is the mailbox layer and needs port 25, which browsers cannot open — so it runs from a server. The list cleaner below does validation in the browser; the verifier asks the mail server.
Check yours
These run free in your browser or from the edge. Nothing is stored.
Common questions
Does verification send an email?
No. The conversation stops before the DATA command. The recipient's server sees a connection that asked about a mailbox and left; the recipient sees nothing.
Why did my verifier say unknown?
The server did not answer clearly — greylisting on the first attempt, a timeout, or a provider that deliberately hides whether mailboxes exist. Retry later. Unknown is not invalid.
How accurate is verification?
For business domains that are not catch-all, very: the server is answering from its own directory. Accuracy drops on catch-alls (no information) and consumer providers (rate limits and evasive answers).
How often should a list be verified?
Before each send. B2B data decays 2–3% a month, so a list verified six weeks ago is already over the 2% bounce line.
Can I verify from my own machine?
Only with a server that can open port 25 and a clean IP; residential connections are usually blocked and consumer providers rate-limit unknown IPs. Most people use a service.
Related concepts
If this is the thing going wrong
The pages explain it. If you would rather it was simply fixed, that is the work I do.