The verifier said valid. The mail bounced anyway.
A customer took roughly 30 addresses out of our own tool and sent to them. Three bounced, and one rejection named the missing mailbox outright. So we went looking for the SMTP check that should have caught it, and there wasn't one. Here is what company mail servers will actually confirm, measured rather than assumed.
Verification is impossible on almost half of domains
We rebuilt the probe to announce a sender domain that exists, send a control address first (one that should fail), then the real address on the same connection. Valid requires a 2xx for the target and a rejection for the control. Then we ran it against 40 real company domains, one probe each.
Most verification never contacts the mailbox
The common shortcut is to confirm the domain has an MX record, check it is not catch-all, then call the address valid and attach a confidence score. Nothing in that chain opens a connection to the address you care about.
Our own tool worked this way until we caught it. We fed it an invented local part on a real customer domain, characters that could not possibly belong to anyone, and it came back valid with 0.90 confidence. The number described the domain. It said nothing about the mailbox.
For catch-all domains no vendor can do better, because the server accepts an invented address as readily as a real one. The honest output there is unverifiable, and a tool that returns a percentage instead is inventing it.
A broken probe makes an address look safer
Our old prober announced itself from sender domains that did not exist. Strict servers reject the sender before you learn anything, and one answered 553 5.1.8 on the spot. The probe fell over, and a probe that fell over was recorded as "not catch-all", which pushed the address toward valid.
That is worth checking in whatever tool you use. Ask what it returns when its own check fails, because a failure that resolves toward valid will quietly fill a list with addresses nobody ever tested.
Microsoft 365 is the same trap from the other side. Those servers answer access denied, 5.4.1 and 5.7.x, to everyone. Treating that as invalid deletes good addresses in bulk, so it needs its own status rather than a verdict.
All three failures were guesses
The addresses that bounced were pattern guesses, firstname.lastname@ and firstname@, generated from a person's name that appears nowhere on that company's site. No source, no evidence, no probe.
Counting a working bank of 969 companies showed the real shape of the problem. It held 1,530 named people and only 354 known addresses, which is 23%. Another 628 companies had a person's name and no address at all.
So the scarcity is addresses, not verification. A list that looks full because every row has something in the email column is usually a list of guesses wearing a decimal point. We now mark guessed addresses separately from verified ones and drop dead addresses out of the send column entirely.
What these numbers do and don't mean
This is 40 real company domains, one probe each, measured in September 2026. That is a sample, not a law, and the split will move with the mix of countries and mail hosts you happen to be sending to. We publish the number of domains because a percentage without one is decoration. The finding we would defend regardless of sample size is the structural one: on a catch-all domain nobody can verify an address from the outside, so any vendor reporting near-zero unverifiable results is reporting something other than what the servers said.
FAQ
Stop sending to addresses nobody ever tested
A single Windows application reads companies straight from official registers, finds the people, and probes each address against the mail server with a control address alongside it. Guessed addresses are marked as guesses, catch-all domains are reported as unverifiable, and dead addresses never reach your send column. One flat monthly fee, no credits and no per-contact charges.