Two Email Verifiers Gave Different Results on the Same List: Which Do You Trust?
When two verifiers disagree on the same list, count the rows where one says valid and the other says invalid, hold those back, and settle them with a fresh check or a small test send. Neither result file can say which tool is right, because both are opinions formed at a moment in time.
Why verifiers disagree
An email check asks a mail server whether it would accept mail for an address, and reads the answer. Several things make two checks differ:
- Time. Mailboxes are closed and opened, and servers change their rules. Two runs a week apart are two different measurements.
- Different questions. Some checks stop at the domain, some talk to the server, some add their own data. How to check if an email is valid without sending anything sets out what each kind of check can see.
- Catch-all domains. A domain that accepts every address cannot be checked mailbox by mailbox. One verifier calls these risky, another valid, another unknown. Accept-all vs unknown shows why the two need different handling.
- Large providers. Some webmail providers do not allow an honest mailbox check, so every tool is guessing or reporting uncertainty its own way. Outlook and Hotmail rows come back risky for this reason.
- False answers. SMTP checks can be wrong in both directions. Why SMTP verification gets it wrong lists the causes.
Different status words also hide agreement. One tool's deliverable and another's valid mean the same thing, while one tool's unknown might be another's risky.
Step 1: Put both results side by side
Download each result file as a CSV with the address and the status in one row each. Paste or upload both into the free verifier results disagreement finder. It maps the status words into four buckets (valid, risky, invalid, unknown), matches rows on the address, and shows:
- How many addresses are in both files, and how many only in one
- The share with the same verdict
- A table of one verifier's verdict against the other's
- The addresses they split on, as a CSV
If the files hold different lists, or one of them was run on a cleaned version, the "only in one file" counts tell you so.
Step 2: Look at where the disagreements are
Read the table, not just the total.
| Pattern in the table | What it usually means | What to do |
|---|---|---|
| Valid in one, invalid in the other | The risky disagreement: one is wrong, or the mailbox changed | Hold these rows and settle them |
| Valid in one, risky in the other | A catch-all or provider-limited domain | Treat as risky; send in a small batch |
| Risky in one, unknown in the other | Two ways of saying "not confirmed" | Treat as risky |
| Invalid in one, risky in the other | One saw a rejection, the other saw an accept-all | Suppress unless the stakes are high |
Group the valid-against-invalid rows by domain. If most sit on two or three domains, the domain is the story, not the tools. A look at those domains in the bulk catch-all checker will often explain it.
Step 3: Settle the rows that matter
Three ways to settle a disputed row, from cheapest to most certain:
- Check them again, now. Take just the disagreement rows and run them through a live check. Upload them on the verify page. A mailbox that closed between the two earlier runs shows up here.
- Look at the reason, not just the status. A reason of mailbox not found is stronger than a generic risky. Compare the reasons in the two files for the same address.
- Send a small test batch. Pick a few hundred of the disputed rows, send the real email, and read the bounces. It is the only test that is not an opinion. Pick a small test batch shows how to choose the sample.
Step 4: Decide the rule for the whole list
- Rows both call valid: send first.
- Rows both call invalid: suppress.
- Everything else: send after the first group, in small batches, and read the bounces between them.
This is the careful order. It does not depend on whose tool is better.
If you are choosing a verifier
A single disagreement table is a small test, not a verdict on the tool. A fair comparison uses the same list, run at about the same time, with a sample you can check independently. How to bench test email verifiers fairly sets that out, and questions to ask before buying an email verifier lists what to ask besides price.
What the tool cannot do
It cannot say which verifier is right, and it skips statuses it does not recognise. It reads the two files you give it in your browser and sends nothing anywhere.
Keep the files
Save both result files, the disagreement CSV and the date you ran each one. If you later send to the disputed rows and read the bounces, you will know which verifier was closer on your kind of list. That is more useful than any general claim, because it is your data, your domains and your sending setup. Record it once and you will not have to guess the next time.
Check the list
Take the disputed rows to the verify page and check them again: 100 free checks, Google sign-in, no card.
Common questions
Why do two email verifiers disagree?
They run at different times, so a mailbox can change between checks. They also ask the server different questions, use different timeouts, and each decides for itself what to call a domain that accepts every address.
Which verifier is right?
Neither file can say. The way to find out is to check the disputed rows again now and, if the stakes are high, to send a small test batch and read the bounces.
How many disagreements are normal?
There is no fixed number. Disagreement is concentrated on risky rows and on large webmail providers, so a list full of catch-all business domains will show more than a list of consumer Gmail addresses. Look at where the disagreements are, not only how many.
Should I just send to anything either tool calls valid?
That treats the more generous verifier as the standard, which is the opposite of a careful rule. Send to rows both call valid first, then settle the rest.
Check your list before you send
Real mailbox checks over SMTP, and nothing is sent to the address. Sign in with Google and your first 100 email checks are free, no card. Plans for bigger lists are on the pricing page.