Infrastructure explains more disagreement than anything else. A receiving server that answers one connecting address honestly may throttle or refuse another, so two services running identical logic get different answers from the same host.
Retry behavior explains most of the rest. Greylisting returns a temporary rejection on first contact by design. A verifier that retries gets the real answer; one that scores the first response marks a good address as bad.
The catch-all probe is the disagreement that matters most. If one service tests whether the domain accepts an invented address and the other does not, the first reports catch-all and the second reports valid, and the second learned nothing.
Vocabulary accounts for apparent disagreements that are not real. One vendor's risky, another's accept-all, and a third's unknown can all describe exactly the same finding, and comparing labels rather than findings produces confusion.
When two services disagree, the useful move is to read the raw response rather than count votes. A verifier that shows you the server's own words lets you judge; one that shows a verdict alone asks for trust instead.
A 1,000-address disagreement, sorted into four piles
Say you run the same 1,000 addresses through two services. They agree on 860 and differ on 140. Don't count votes. Sort the 140 by what kind of disagreement each one is.
Suppose 70 are valid at service A and catch-all at service B. That's the probe difference. B tested the domain with a made-up address and A didn't, so believe B. Another 40 are unknown at A and invalid at B. Look at B's raw replies here. If they're temporary 4xx codes scored as dead, B is wrong and those 40 people may be real.
A further 20 differ in label only, risky at one and catch-all at the other. Those aren't real disagreements. The last 10 changed between runs for the dullest reason there is: the two checks happened a week apart and a few mailboxes closed. Out of 140 conflicts, only the 40 needed a judgment call.
When the disagreement matters, and a rule for ties
For a single campaign, a small disputed pile isn't worth an afternoon. If the two services differ on 2% of your list, put those addresses in a separate small send and let the bounces settle it. You'll have the answer by tomorrow.
It matters a great deal when you're picking a vendor, because the disputed pile shows you each one's habits. A service that turns temporary failures into invalid will keep deleting real people from every list you give it. One that skips the random-address test will keep passing unproven addresses as valid.
When you have to break a tie with no raw reply to read, don't take the sunnier verdict by default. Between valid and catch-all, treat the address as catch-all. If it's invalid against unknown, go with unknown. Choosing the cautious label costs you a separate send. The hopeful one costs you a bounce or a lost customer, and you won't know which until later.
Related questions
Which verifier should I believe?
The one that shows the server's actual response. A raw reply lets you judge; a bare verdict asks for trust.
Does disagreement mean one is broken?
Usually not. Different IP standing and different retry logic produce different answers from the same server.
Should I run a list through two services?
As a one-off evaluation it is informative, especially for comparing the unresolved share. As routine practice it doubles the cost.
Why do labels differ so much between vendors?
There is no standard vocabulary. Risky, accept-all, unknown and catch-all overlap differently at every vendor.