Single-Engine vs Two-Pass Email Verification

Every email verifier on the market does roughly the same four things, and the marketing pages describing them are close to interchangeable. Where they genuinely differ is what happens after those four things fail to produce an answer. That moment accounts for a quarter of a typical business list, and almost every verifier handles it by telling you it could not tell.

A short history of the verification stack

Email verification started as syntax checking. A regular expression decided whether a string looked like an address, which caught typos and nothing else. When lists moved online in volume, DNS checks were added: does the domain exist, and does it publish mail servers? That removed the dead domains.

The step that made verification commercially useful was the SMTP probe. Rather than reasoning about the address, you open a conversation with the mail server that handles the domain and ask whether it will accept mail for that specific mailbox. The server answers before any message is sent. This is still the core of every credible verifier, and it is very good.

It has one structural weakness, and the industry has spent fifteen years reporting that weakness rather than solving it.

How a single-engine verifier works

A single-engine verifier runs its checks in sequence and stops at the first one that settles the question:

1. Syntax. Is this a structurally valid address? This removes the pasted commas and missing @ symbols.
2. Domain. Does the domain resolve in DNS? A domain that has lapsed since the contact was collected fails here.
3. Mail servers. Does the domain publish MX records? A domain can host a website perfectly well and be incapable of receiving mail.
4. Mailbox. Ask the mail server about the specific address. This is where most addresses are settled, in both directions.

Run that against a clean consumer list and it works beautifully. Nearly every address resolves to a clear yes or no, the whole thing finishes fast, and there is very little left over. If your lists look like that, a single pass is the correct tool and the rest of this article is not about you.

The three places a single pass runs out of road

The trouble is concentrated in three situations, and only one of them is talked about much.

1. Catch-all domains

Some domains are configured to accept mail for every possible address, whether or not the mailbox exists. Ask such a server about anything@company.com and it says yes. The mailbox probe, the strongest tool in the stack, returns a positive answer that means nothing at all. The verifier knows the answer is unreliable, so it reports the condition rather than a verdict: catch-all, accept-all or unknown, depending on the vendor. This is the big one, and catch-all domains have their own article.

2. Greylisting

Greylisting is an anti-spam technique where a server temporarily refuses mail from a sender it does not recognise, on the theory that legitimate senders retry and spammers do not. A verifier that meets a greylisting server gets a temporary failure rather than a real answer. Treating that as undeliverable would be wrong, so a careful verifier records it as unknown, and an incautious one silently discards a valid address.

3. Provider-specific behaviour

Mail servers are not obliged to be helpful. Some providers deliberately obscure whether a mailbox exists, on the reasonable view that answering that question freely helps people building spam lists. Others rate-limit aggressively, or answer differently depending on the reputation of whoever is asking. A single pass gets one attempt from one vantage point, and whatever it is told, it has to believe.

The two-pass model

Two-pass verification treats the ambiguous result as the beginning of the work rather than the end of it. The first pass is a conventional verifier and behaves exactly as described above. Its job is to settle everything settleable and, crucially, to sort the leftovers honestly.

The second pass takes only that leftover segment and re-tests it with different techniques: deeper SMTP-level verification and waterfall routing, approaching the same mailbox by a route that behaves differently from the one that produced the ambiguity. Because it runs on a minority of the list, it can afford to be slower and more expensive per address than a first pass ever could.

What pass one is for

Pass one carries the volume. It validates syntax, DNS, MX records and mailbox existence, running 20 concurrent checks per list, and resolves 70 to 85 percent of addresses in under a minute. Its second responsibility matters as much as its first: it has to be honest about which results it could not establish, because a first pass that rounds ambiguity to deliverable poisons everything downstream.

What pass two is for

Pass two runs at 5 concurrent checks over the flagged segment only, re-verifying catch-all and unknown results with deep SMTP-level verification and waterfall routing. It turns unknown into deliverable or risky for the remaining addresses, and attaches a confidence score so you can see how firmly each recovered verdict is supported.

The same list, both ways

Take a 10,000-address business list, which is the shape most cold outreach teams actually work with. A single pass settles about 7,500 of them cleanly. The remaining 2,500 sit on catch-all domains and come back as a status rather than an answer.

The second pass resolves roughly 72 percent of that 2,500, which is about 1,800 addresses moving from unknown to a definitive verdict. That is 18 percent of the entire list recovered, and it is the difference between the two models stated as plainly as it can be stated. The addresses were always in the file. One model can tell you about them and the other cannot.

The comparison that matters is not accuracy on the easy 75 percent, where every credible verifier agrees. It is what happens to the other quarter.

The economics

A second pass costs more per address than a first, because it is more work. The question is whether the recovered addresses are worth it, and that depends entirely on what a qualified lead is worth to you.

The useful metric is cost per usable lead rather than cost per address checked. A cheaper verifier that returns a quarter of your list as unresolved has not saved you money if those addresses were the ones you wanted. Equally, if your list is mostly consumer domains and the unresolved segment is tiny, you are paying for a capability with nothing to do. Both statements are true, and which one applies is an empirical question about your data, not a matter of taste. The MillionVerifier comparison works the arithmetic through in detail on both sides.

How to evaluate a two-pass claim

As the term spreads, tools will start describing themselves as two-pass because it sounds like more. Four questions separate a second pass from a longer first one.

1. What percentage of a B2B list comes back unresolved? Not the headline accuracy figure, which is dominated by the easy addresses. Ask specifically about the catch-all segment.
2. What happens to that segment? If the answer is a status name, there is no second pass, however many checks run inside the first.
3. What resolution rate does the second stage achieve? A vendor that has measured it will have a number. Ours is roughly 72 percent.
4. Does the second stage use a different technique? Retrying the same probe against the same server produces the same ambiguity. The second pass has to differ in method, not just in timing.

When two-pass is not necessary

It is worth being direct about this, because the answer is not always our product.

• Consumer lists. Free providers and consumer domains overwhelmingly give clean SMTP answers. Catch-all density is low, and the second pass would have almost nothing to resolve.
• Transactional validation at signup. If you are checking one address at the point a user types it, you want the fastest possible verdict. A single pass answers in a few hundred milliseconds and is the right call for that job.
• Lists you have already mailed successfully. An address that accepted mail last week does not need deep verification this week. Re-verification is about decay, and decay takes months.

Getting two-pass verification

You can build it. You need a primary verification capability, an honest classifier for what is genuinely unresolved rather than merely negative, a second technique that behaves differently on catch-all domains, and enough infrastructure reputation that mail servers keep talking to you. The last one is the part that cannot be bought quickly, and it is why most in-house verification projects end up being a wrapper around someone else's API.

Or you can use a verifier that already runs both passes. Ours does, and the free checker on the free email verifier page runs the full two-pass engine on a single address without an account, so you can see what the second pass does on a domain you already know is a catch-all. The features page covers the rest of the pipeline, and a free account comes with 100 credits to try it on a real list.

Frequently asked questions