He did everything right. Then the bounce rate came in.
His name was David and he was not the kind of person who makes careless decisions. He had spent four months building the list. Three data sources, cross-referenced. Tight ICP. He had run deduplication, removed the obvious junk, and before he sequenced anything, he verified the list.
He found a tool on the first page of Google. It was priced reasonably, the UI was clean, and it returned results fast — which, at the time, felt like a sign it was doing something right. He uploaded 120,000 contacts and got back a report within a few hours.
91.4% valid. 7.2% invalid and removed. 1.4% unknown. He sent the campaign.
What nobody had told him was that there are two fundamentally different things that tools call "email verification." One checks whether a domain has mail infrastructure. The other checks whether a specific mailbox exists at that domain. David had paid for the first kind while needing the second kind — and nothing in the experience had surfaced that distinction until his bounce rate did.
What DNS lookup can and cannot tell you
When a verification tool performs a DNS-only check, it queries the DNS system — the directory that maps domain names to the servers responsible for handling them. Understanding what DNS contains, and what it does not contain, is the whole explanation for why DNS-only results misrepresent what they are.
The DNS system is a directory of routing information. It tells you where to go, not who is there. The mail server that actually knows whether j.smith@company.com exists is never contacted in a DNS-only check. You are checking the signpost, not knocking on the door.
What a real SMTP handshake actually does
SMTP is the protocol mail servers have used to transfer email since the early 1980s, and it is the only way to ask a mail server whether a specific mailbox exists. Real SMTP verification initiates a partial version of the conversation that two mail servers would have if one were actually delivering mail to the other.
The gap between this and DNS lookup is not a matter of degree. DNS lookup never contacts the mail server. SMTP verification does nothing but contact the mail server. They are not variations of the same approach. They are different approaches to different questions that happen to both be called "verification."
The response codes — and what they actually mean
The response codes your verification system receives in the RCPT TO step are where the signal lives. Most tools translate these into four categories — valid, invalid, catch-all, unknown — and present those categories with equal confidence. That translation loses information you should have.
451 · 452
When you read "invalid" in your output, it matters which code produced it. 550 is reliable. 554 is an infrastructure signal as much as an address signal. When you read "unknown," it matters whether the address received a 421 that was never retried, or whether the server timed out entirely. A result format that presents them identically makes your decisions harder than they need to be.
The catch-all mechanism — why this only shows up in SMTP
A catch-all domain is a mail server configured to return 250 for every RCPT TO command regardless of whether the specific mailbox exists. Your verification system cannot distinguish this 250 from the 250 it would receive at a domain where the mailbox is verified and active.
DNS-only verification has no mechanism to detect catch-all configuration. Whether a domain accepts all RCPT TO commands is a mail server behavior, not a DNS setting. The MX records for a catch-all domain look identical to the MX records for a domain where every SMTP response reflects the actual state of the specific mailbox.
David's list had a meaningful share of addresses at catch-all domains. His DNS-only tool had no way to know. It returned the equivalent of "domain has MX records" for every address at those domains — because it never asked the mail server anything specific. When he sent, the addresses at catch-all domains that corresponded to non-existent mailboxes bounced. The tool had not been lying. It had not had access to the information that would have told the truth.
The hybrid tool problem
There is a third category between pure DNS-only and genuine SMTP verification — the one most verification tools in the market today actually belong to: SMTP-primary with silent DNS fallback.
These tools attempt real SMTP handshakes as the primary method. When the SMTP query fails — timeout, temporary deferral, blocked connection — rather than returning the address as unknown, they fall back to DNS and classify based on MX record presence.
They then present results from both methods in the same output format, with the same confidence categories, without surfacing which method produced each result. An address marked valid because a real SMTP handshake returned 250 on a non-catch-all domain is presented identically to an address marked valid because SMTP failed and DNS found MX records.
The addresses most likely to trigger SMTP fallback in 2026 are Google Workspace and Microsoft 365 addresses — where server-side filtering is sophisticated enough to block or defer queries from infrastructure without established SMTP history. Those are precisely the addresses where DNS fallback produces the most misleading results, because they have robust MX records that will return "valid" from DNS while the specific mailboxes may or may not exist.
Ask any provider one question before you commit: "When your SMTP query receives a temporary deferral or times out, does that address go into your unknown category or fall through to DNS and get classified from there?" A clear answer means you can trust what your valid category represents. A vague answer about "multiple verification methods" usually means the fallback is happening without disclosure.
The speed trade-off
DNS lookup is fast. SMTP handshakes are slower. This is real, not trivial — and it is often used to justify DNS-only verification in contexts where it should not be justified.
David's DNS-only check on 120,000 addresses probably completed in under two hours. A proper SMTP verification on the same list would have taken ten to fourteen hours. The twelve hours he did not spend waiting cost him an 11.3% hard bounce rate on a campaign he had spent four months preparing.
What each result category actually means
What this tells you about the infrastructure underneath
The quality of SMTP verification results depends on the quality of the answers the verification system receives. And the quality of those answers depends on whether the mail server on the other end engages honestly with the query.
Mail servers evaluate the IP origin of every SMTP connection they receive. An IP with a long history of clean, consistent SMTP behavior — the kind that takes years to build, not months — receives a different quality of response from major providers than an IP making these queries for the first time. Honest 250s and 550s versus defensive deferrals and vague catch-all responses.
The verification logic is identical in both cases. The inputs are not.
This is why the infrastructure layer matters for SMTP verification in a way that it simply does not matter for DNS-only lookup. DNS queries are answered by the DNS system, which does not evaluate the reputation of the origin. SMTP conversations are answered by mail servers, which do.
David chose based on price, speed, and a clean UI. The tool was priced reasonably, it ran fast, the results looked professional. What those signals did not tell him was that fast results from a DNS-only check are fast because the check is not doing the hard work. The hard work is the SMTP handshake, the probe test, the honest response from a mail server that trusts the infrastructure making the request. That is where the difference between 91.4% valid and 11.3% bounce actually lives.
He knows this now. The question is whether you have to find out the same way he did.
Built for mail servers to answer honestly
Proxy25 provides residential proxy infrastructure with years of established SMTP history across major enterprise mail environments — built for verification systems that need real answers, not defensive deferrals.