Two Validators, Two Verdicts: How to Reconcile Conflicting Email Verification Results

You did the responsible thing. Before committing a 40,000-row list to a campaign, you ran it through your usual verification tool, then ran the same file through a second one as a sanity check.

The two reports do not agree. A few thousand addresses that came back clean from the first tool are flagged by the second. A couple of hundred that the first tool rejected outright are sitting in the second tool’s deliverable bucket. The totals are close enough that both reports look credible, and far enough apart that you cannot act on either.

The instinct at this point is to decide which vendor is lying. That is the wrong question, and chasing it burns a day. Two verification tools returning different verdicts on the same address is the expected outcome of how they work, not evidence that one of them is broken. What matters is knowing which kind of disagreement you are looking at, because each kind has a different correct response.

Why two honest tools disagree

Standard email verification is an inference, not a lookup. There is no central registry of live mailboxes to query. Each tool assembles a guess from some mix of four inputs, and they weight that mix differently.

The SMTP conversation. Most tools open a connection to the recipient’s mail server and begin the handshake for a message they never send, reading the server’s response to the recipient address. This is the core signal, and it is noisier than it looks. The same server, asked the same question twice, can answer differently depending on the asking IP’s reputation, the rate at which it was asked, and the time of day.

Server behaviour that is deliberately uninformative. A large share of business domains are configured to accept mail for every address at the domain, real or not, and sort it out internally. The handshake therefore succeeds for [email protected] and equally for [email protected]. Some tools call this catch-all, some accept-all, some fold it into a generic risky bucket. None of them learned anything about the mailbox.

Greylisting and throttling. A server may temporarily defer an unknown sender rather than answer. One tool will retry and eventually get a verdict; another will record the deferral as unknown; a third will treat the deferral as a soft negative. Nothing about the mailbox changed between those three runs. If you have not met this behaviour before, greylisting is worth understanding, because it produces disagreements that look exactly like tool error.

Historical and proprietary data. Tools layer their own bounce histories, complaint data, and pattern rules over the live probe. These data sets do not overlap, so the layer that pushes an address into risky at one vendor may not exist at the other.

Two tools with different probe infrastructure, different retry policies, different taxonomies, and non-overlapping history files will disagree. A list where they agreed on every row would be the surprising result.

The four shapes of disagreement

Dump both reports side by side and join them on the address. Every conflicting row falls into one of four patterns, and conflating them is how teams make bad calls.

1. Deliverable versus undeliverable

The rare, genuine conflict. One tool says the mailbox exists, the other says the server rejected it. Usually one of three things happened: the probes ran days apart and the mailbox was deprovisioned in between, one tool’s sending IP is poorly reputed at that provider and got a blanket rejection, or the rejection was a rate-limit response misread as a permanent failure.

This bucket is almost always small. Treat it as a separate work item, not as a reason to distrust the whole report, and resolve it with a fresh third look rather than by picking a side. If you want to read the raw server responses yourself before deciding, start with SMTP bounce codes: a 550 5.1.1 and a 450 4.2.1 tell you very different things, and some tools flatten both into “invalid”.

2. Deliverable versus risky or catch-all

The big bucket, and the one that is not actually a conflict. One tool resolved the address to deliverable; the other reported that the domain accepts everything and declined to guess. These two statements are compatible. The second tool is not contradicting the first, it is declining to answer.

The mistake here is reading one tool’s confidence as independent confirmation. If a tool returns a confident verdict on a domain that accepts all mail, the confidence is derived from pattern matching and history, not from the server. It may well be right. It is not a measurement.

3. Undeliverable versus risky or catch-all

The inverse, and the most expensive one to get wrong. One tool rejected the address; the other says the domain cannot be resolved by probe. Here the rejection carries real information, because a catch-all domain is not supposed to be able to reject anything. A hard rejection from a domain the other tool called catch-all usually means the first tool reached a different mail host for that domain, or reached it before a recent MX change.

4. Anything versus unknown

Not a conflict at all. Unknown means the probe did not complete: timeout, deferral, connection refused. Treat these rows as unprocessed rather than as a verdict, and run them again later. Counting unknowns as either good or bad silently corrupts whatever decision you make next.

The reconciliation rule that destroys lists

Here is the approach to avoid, because it is the most common one. With two reports in hand, people build a rule like this:

if toolA == deliverable or toolB == deliverable:
    send

Optimistic reconciliation. Any clean verdict from either tool is enough. The appeal is obvious: it preserves the largest possible list, and both tools are reputable, so a clean verdict from either should be fine.

It is not fine, and the reason is structural. You are not combining two independent measurements. On every catch-all domain in the file, at most one tool actually measured anything, and frequently neither did. An or across two guesses does not average out the error, it selects for whichever tool guesses most generously, and then ships the result as though two vendors had both signed off.

The pessimistic version has the opposite failure. Requiring both tools to say deliverable throws away every address on a catch-all domain, which on a B2B list means deleting a large slice of your best accounts: the bigger the company, the more likely its mail is routed through a gateway that accepts everything. You end up with a small, clean list of mostly small companies.

Neither rule is a reconciliation. Both are a way of converting an unresolved question into a decision without answering it.

What to do instead

Stop trying to pick a winner per row. Sort the joined file by what the tools collectively established, and route each group to a different action.

Three of those seven rows resolve themselves. Three of them say the same thing: the question is still open, and no amount of further SMTP probing will close it, because the server has already told you it will accept anything you ask about.

Closing that gap takes a different method. Instead of asking the mail server whether an address exists, inbox-level validation establishes whether a message to that address actually lands. This is the specific gap Scrubby was built to close: it takes the risky and catch-all segment that standard SMTP verification cannot resolve and returns a definitive valid or invalid result, using deep inbox-level testing rather than another handshake. Deep Verification is the mode for that segment, and Quick Verification covers the rows where a standard check is sufficient, so you are not paying the deeper rate on addresses that a probe already answered.

The sequence that follows from the table is straightforward:

1. Run the full list through whichever SMTP tool you already trust.
2. Export the risky, catch-all, and accept-all segment. On a B2B list this is often a quarter to a third of the file.
3. Put only that segment through inbox-level validation.
4. Merge the definitive verdicts back and send.

The second opinion that resolves the grey bucket has to use a different method. A second SMTP tool is a second instance of the same method, which is why it produces a second copy of the same unanswered question. If you are new to why this class of address resists probing at all, the guide to catch-all emails covers the mechanics.

Check your own file before you blame the tools

A meaningful share of apparent tool disagreement is not disagreement about mailboxes. It is the two tools being handed subtly different inputs, or the same input at different times. Rule these out first, because each one is cheap to check and embarrassing to discover afterwards.

Normalisation drift. If one tool lowercases, trims whitespace, and strips plus-tags before probing and the other does not, you are comparing verdicts on different strings. Export both reports with the address exactly as each tool returned it and diff the columns before joining.

Duplicate rows resolving differently. The same human appearing twice under two address variants can legitimately produce two different verdicts, and a naive join will surface that as a conflict. Normalising aliases before you compare removes a whole class of phantom conflicts.

Elapsed time between runs. B2B addresses decay continuously as people change jobs. If the two runs are weeks apart, some disagreement is simply correct: the mailbox died in between. Record the probe date alongside the verdict and treat it as part of the result.

MX changes. A domain that migrated mail hosts between the two runs will behave differently, sometimes flipping from strict rejection to catch-all. The address did not change. The infrastructure answering for it did.

Partial files. Check the row counts. A tool that silently dropped malformed rows on import produces apparent conflicts on addresses it never actually tested.

Make this a standing process

The reason this situation feels like an emergency is that the reconciliation gets improvised under campaign pressure. It does not have to be. The whole thing reduces to a small number of decisions you can make once:

• Pick one SMTP tool as the primary. Running two for coverage duplicates a method rather than adding one.
• Define the grey bucket explicitly by the primary tool’s own labels, so the export is mechanical rather than a judgement call.
• Route that bucket through inbox-level validation as a fixed step, not as an escalation when something looks wrong.
• Treat unknown as unprocessed, never as a verdict, and give it a retry path.
• Stamp every row with its verdict date, so the next person can tell decay from disagreement.
• Wire it into the flow so it runs without anyone remembering to run it. Scrubby’s integrations cover the usual path from CRM and sequencer into validation and back.

Two tools disagreeing on an address is information. It usually tells you that the address sits on a domain neither tool can interrogate, which is a fact about the domain rather than a failure of either vendor. Once you can read the disagreement, the grey bucket stops being a judgement call and becomes a routing decision, and the addresses in it stop being a coin flip you take on send day.