How email verification actually works
Email verification is often described as though it were magic, or as a percentage. It is neither. It is a short, specific conversation with a mail server, and understanding it tells you exactly how much a "verified" result is worth.
The four checks, in order
A verification pipeline runs a sequence of increasingly expensive checks, stopping as soon as one fails. Cheap checks run first because there is no point opening a network connection to a domain that does not exist.
- Syntax. Is this a structurally valid address? Catches typos and malformed input at zero cost.
- Domain. Does the domain exist and resolve? A surprising share of addresses in old lists fail here, because the company folded or the domain lapsed.
- Mail exchange records. Does the domain publish MX records — that is, has anyone actually arranged for mail sent to it to go somewhere? A domain with no MX records cannot receive email regardless of what the address looks like.
- Mailbox. Does the receiving server accept mail for this specific address? This is the check that matters, and the only one that requires talking to the server.
The conversation
The fourth check works by starting to send an email and then stopping. A mail server receiving a message goes through a fixed sequence: the sender introduces itself, states who the mail is from, states who it is for, and only then transmits the message body.
A verifier performs that sequence up to the "who it is for" step. At that point the receiving server has to decide whether it will accept mail for that recipient, and it answers. The verifier records the answer and abandons the connection before any message body is sent.
The practical consequence is that the person being verified receives nothing. No email arrives, no notification is generated, and nothing appears in their mailbox. The check is a question, not a delivery.
What the answers mean
The server's response maps onto four outcomes. Two are clear and two are not, and how a provider handles the unclear two tells you most of what you need to know about them.
- Accepted — the server confirmed it will take mail for this address. This is the result you want and the only one that should be reported as verified.
- Rejected — the server refused. The address does not exist there. Sending to it produces a hard bounce.
- Catch-all — the domain accepts mail addressed to anything at all. The acceptance proves the domain works, not that this person exists. Honest providers label this as risky; less honest ones count it as a confirmation.
- No answer — the server declined to respond definitively, usually through greylisting or a firewall that blocks verification traffic. Genuinely unknown, and no provider can resolve it.
The catch-all problem
Catch-all domains are the single biggest source of inflated accuracy claims in this industry, and they are common — plenty of organisations configure their mail this way deliberately, so that misaddressed mail reaches someone rather than bouncing.
The problem is that a catch-all domain says yes to everything. Ask it about a real employee and it says yes. Ask it about an address you invented, and it also says yes. So a "yes" from a catch-all domain carries no information about whether the specific person exists.
If a provider counts catch-all acceptances as verified, its accuracy number goes up and the usefulness of its results goes down. When evaluating a tool, ask directly how it treats catch-all domains. The answer is unusually diagnostic.
What verification cannot tell you
Even a clean acceptance is a narrower statement than it sounds. It is worth being precise about the boundary, because the gap is where disappointment lives.
- It confirms the address accepts mail. It does not confirm that the person still works there — a mailbox often stays open after someone leaves, forwarding to a colleague.
- It does not predict deliverability. Whether your message reaches the inbox rather than the spam folder depends on your sending reputation, your content and your authentication, none of which verification touches.
- It does not guarantee a human reads it. Role addresses and shared inboxes verify perfectly well and may be monitored by nobody.
- It is a snapshot. An address confirmed today can be closed tomorrow. Verification close to the send is worth more than verification done months ago.
When the check ran matters as much as whether it ran
Because verification is a snapshot, the age of that snapshot is part of the result — and it is the part most often left out. "Verified" with no date attached is an incomplete statement.
This is the practical difference between the two ways contact data reaches you. One is a lookup: the provider checked an address at some earlier point, stored the outcome, and serves you that stored outcome when you ask. The other runs the check during your request, so the answer describes the mailbox as it is configured at that moment.
Neither is dishonest, and the lookup model has real advantages — it is faster, and it can answer for people you have not identified yourself. But it carries an invisible variable: how long ago was this confirmed? A provider that cannot show you the date of the check is asking you to treat a six-month-old result and a six-second-old one as the same thing.
- Ask when the address was last confirmed, not what percentage of the database is accurate — the second number tells you nothing about the row in front of you.
- Treat undated results as older than you would like. If the freshness were flattering, it would usually be shown.
- Weight verification age against how quickly your market moves. In a sector with heavy job mobility, a result from last quarter is a different asset from one from this morning.
- Re-verify before a large send regardless of source. The cost of the check is far below the cost of the bounce.
Why bother, then
Because the alternative is worse in a specific and compounding way. Hard bounces are the clearest signal a mailbox provider has that a sender is working from a list they have not checked, and providers respond by throttling delivery for the entire sending domain.
That penalty outlasts the campaign that caused it. It affects your colleagues' mail, your transactional messages and every subsequent send, and recovering from it means weeks of careful low-volume sending. Verification is cheap in comparison — it is one of the few pieces of list hygiene where the cost-benefit case is not close.
ReachNow runs this check at the moment you enrich a prospect, rather than returning a result recorded earlier, and labels catch-all results as risky rather than reporting them as confirmed.