How Email Verifiers Work: Real SMTP Verification vs DNS-Only Lookups [Technical Guide 2026]

EmailShield runs every email through a 4-stage verification pipeline that combines syntax checks, MX lookups, domain-grouped catch-all detection, and real multi-port SMTP handshakes through self-hosted proxy infrastructure. The result: 99.8% verified accuracy on definitive labels, vs 91-94% from legacy DNS-only tools. This guide breaks down exactly how email verifiers work at the protocol level, why DNS-only checks leave a deliverability gap, and what separates a production-grade SMTP verifier from one that returns "unknown" on a third of your list.

If you've ever uploaded a CSV to a verifier and gotten back a valid label that bounced anyway, the gap is almost always between two methods most tools blur together: DNS-only lookups and real SMTP handshakes. They live one OSI layer apart and they answer fundamentally different questions.

The five questions every email verifier has to answer

Before any verifier writes valid or invalid next to an address, it has to resolve five questions in order. Each one has a different cost and a different signal value.

A DNS-only verifier stops at question 3. That's where the 91-94% accuracy ceiling comes from. The domain has MX records, so the verifier returns valid, even though the specific mailbox might not exist. Anything past question 3 requires opening a TCP connection to the recipient's mail server and conducting a live SMTP conversation. That's the work most verifiers won't do reliably.

EmailShield's pipeline runs all five, in order, with deterministic labeling at the end. Here's what each stage actually looks like in the wire protocol.

Stage 1: Syntax and DNS validation

Syntax validation catches the obvious failures: missing @, spaces, double dots, invalid TLDs, characters outside the RFC 5322 character set. It costs effectively nothing and eliminates 1-3% of any list before a single network packet leaves the machine.

DNS validation runs two queries in sequence:

$ dig +short A example.com
93.184.216.34

$ dig +short MX example.com
0 .

The MX query is the gating check. If a domain has no MX records, it cannot receive email regardless of whether the A record resolves. RFC 5321 section 5.1 allows fallback to the A record when MX is absent, but in 2026 practice this fallback fails on virtually every modern receiver. No MX means no mail.

A DNS-only verification tool stops here and calls the address valid. That's the entire mechanism behind tools that claim 91-94% accuracy. They confirm the post office exists, they don't confirm there's a mailbox with your recipient's name on it.

EmailShield data: On a representative 50K-row B2B list, DNS-only validation alone produced 96.2% valid results. After we ran the same list through full SMTP verification, the true valid rate dropped to 71.4%. The 24.8% gap was a mix of non-existent mailboxes on valid domains (15.1%), catch-all domains pretending to accept everything (7.3%), and disposable or role addresses (2.4%). Any tool that stops at DNS would have classified that 24.8% as deliverable, and your bounce rate would have proved them wrong.

Stage 2: Catch-all detection (domain-level, not per-email)

Catch-all is the single most expensive misclassification in email verification, and it's the test most tools either skip or run wrong.

A catch-all domain is one configured to accept any RCPT TO command, even for addresses that don't exist. The server returns 250 OK for john@company.com, jane@company.com, and definitely-not-real-9j2k@company.com with equal enthusiasm. Roughly 30-40% of B2B domains run this configuration, especially Microsoft Exchange and on-premise setups that route unknown recipients to a generic mailbox or queue them for human review.

If a verifier runs RCPT TO against a catch-all domain without detection, every address gets labeled valid. Send to that list and the bounce rate will tell you exactly which addresses were fake.

How catch-all detection works at the protocol level

The standard technique is a deliberate-fake probe. Generate a random, plausible-but-nonexistent local-part and run RCPT TO against the same MX:

Verifier > EHLO verifier.example.com
Server   < 250-mx.target-domain.com Hello
         < 250-SIZE 52428800
         < 250 STARTTLS

Verifier > MAIL FROM:<probe@verifier.example.com>
Server   < 250 2.1.0 Sender OK

Verifier > RCPT TO:<x7k2m9q4p3w-not-real@target-domain.com>
Server   < 250 2.1.5 Recipient OK     ← catch-all confirmed

If the server returns 250 OK for the obviously fake address, the domain is catch-all. If it returns 550 5.1.1 User unknown, the domain honors RCPT responses and you can trust per-mailbox verification for the real addresses.

Why catch-all is a domain property, not an email property

Catch-all behavior is configured at the MX server level. Every mailbox on company.com shares the same answer. Running a separate probe for each email on the same domain wastes connections, burns rate limit budget, and risks triggering anti-abuse defenses.

EmailShield groups addresses by MX host before Stage 3 even starts. For each unique (domain, MX) pair, the orchestrator runs one probe and caches the result in Redis with a 24-hour TTL. Every email on that domain inherits the verdict.

# Conceptual flow, not production code
emails_by_mx = group_by(emails, key=lambda e: e.mx_host)

for (domain, mx), addresses in emails_by_mx.items():
    cached = redis.get(f"catchall:{domain}:{mx}")
    if cached:
        catchall_result = cached
    else:
        catchall_result = probe_catchall(domain, mx)
        redis.setex(f"catchall:{domain}:{mx}", 86400, catchall_result)
    
    for addr in addresses:
        addr.details.catch_all = catchall_result == "catch_all"

If the first probe is inconclusive (timeout, transient 4xx error), EmailShield retries up to 5 times through different proxies before defaulting to not_catch_all. We never return unknown at this stage. The status field is deterministically binary.

This matters at bulk scale. For a 100K list with 8,000 unique domains, naive per-email probing would generate 100,000 probe attempts. Domain-grouped probing generates 8,000. The same accuracy at 8% of the network cost.

Stage 3: Real SMTP handshakes through proxy infrastructure

This is where most verifiers break and where EmailShield's accuracy comes from. The SMTP handshake itself is straightforward. Getting it to work reliably at scale against modern receivers is not.

The protocol-level conversation

Here is the exact byte-level exchange for a successful verification:

[TCP connect to mx.target-domain.com:25]
Server   < 220 mx.target-domain.com ESMTP ready

Verifier > EHLO check.emailshield.co
Server   < 250-mx.target-domain.com Hello check.emailshield.co
         < 250-PIPELINING
         < 250-SIZE 36700160
         < 250-STARTTLS
         < 250 ENHANCEDSTATUSCODES

Verifier > STARTTLS
Server   < 220 2.0.0 Ready to start TLS
[TLS handshake]
Verifier > EHLO check.emailshield.co
Server   < 250-mx.target-domain.com Hello (encrypted)
         < 250 ENHANCEDSTATUSCODES

Verifier > MAIL FROM:<check@emailshield.co>
Server   < 250 2.1.0 Sender OK

Verifier > RCPT TO:<john.doe@target-domain.com>
Server   < 250 2.1.5 Recipient OK     ← mailbox exists

Verifier > QUIT
Server   < 221 2.0.0 mx.target-domain.com closing connection
[TCP close]

No DATA command is ever issued. No message body is transmitted. The mailbox owner never receives anything because nothing was ever sent. The conversation ends after RCPT TO confirms whether the server will accept mail for that recipient, which is the only piece of information needed.

If the server returns 550 5.1.1 User unknown in local recipient table, the mailbox doesn't exist and the result is invalid. If it returns 450 4.2.1 Mailbox temporarily unavailable, the mailbox exists but is throttling, and the verifier should retry later. The exact response code is what drives the label.

Multi-port fallback

Port 25 is the canonical server-to-server SMTP port, but it's blocked outbound on most cloud providers (AWS, GCP, Azure all block by default) and most residential ISPs. A verifier running from a default cloud instance will silently fail Stage 3 on every domain because the SYN packet never makes it out.

EmailShield's verification nodes attempt ports in order: 25, then 465 (implicit TLS, SMTPS), then 587 (submission with STARTTLS), then 2525 (alternate submission). The fallback chain catches receivers that have moved to encrypted submission or that block port 25 inbound. Each attempt has its own timeout budget that escalates per retry: 10 seconds for the first attempt, 15 for the second, 20 for the third.

Self-hosted proxy network

This is where infrastructure matters more than algorithms. Major receivers (Gmail, Outlook 365, Yahoo, Proofpoint, Mimecast) actively defend against mailbox enumeration. They detect verification patterns and respond with either always-250 (accept everything, bounce later) or always-4xx (refuse everything).

The defense triggers on three signals:

1. Source IP reputation: connections from known verifier networks get blanket responses regardless of the actual mailbox state.
2. Connection rate: more than N RCPT TO commands per IP per minute against the same MX trips throttling.
3. Behavioral fingerprinting: deterministic patterns (same EHLO hostname, same MAIL FROM, same timing) look like a probe and get blocked.

Legacy verifiers that use shared proxy pools (or no proxy at all) lose accuracy on exactly the providers that matter most for B2B. ZeroBounce and MillionVerifier route through shared infrastructure where IPs are already burned. Hunter relies on third-party proxy providers. The result is exactly what you'd predict: their published accuracy claims (96-99%) don't survive contact with Gmail or Office 365 at scale.

EmailShield runs self-hosted proxy infrastructure with rotating egress IPs and per-MX health tracking. The route selection algorithm picks a proxy based on its current success rate against the specific MX, daily budget utilization, and cooldown state. A proxy that just timed out against aspmx.l.google.com is rotated out for that MX while staying active for unrelated domains. A retry against the same MX always uses a different proxy, because retrying through a path that just failed is wasted budget.

Retry logic and what counts as a failure

The distinction between proxy-layer failures and MX-policy failures matters because mass-throttling proxies on MX behavior would empty the pool the moment a slow receiver shows up. EmailShield treats those as separate signals and routes accordingly.

EmailShield data: On a 250K verification run against a target list with 38% Gmail and 22% Microsoft 365 addresses, our self-hosted proxy network maintained 94.1% definitive-answer rate (valid or invalid with confidence ≥ 0.90). A leading shared-proxy competitor running the same list returned 67.3% definitive answers, with the remainder split between catch-all, unknown, and forced valid labels that bounced at 4.2% on send.

Stage 4: Deterministic labeling and confidence scoring

After Stages 1-3 complete, every email has a bag of signals: RCPT response code, MAIL FROM behavior, catch-all probe result, disposable/role tags, retry history. Stage 4 combines those into a primary label plus tags plus a confidence score.

Primary labels

Tags stack on top of the primary label and carry their own confidence:

• disposable: 0.95 (curated database of 800+ disposable providers)
• role: 0.80 (local-part matches info@, admin@, support@, etc.)
• spam_trap: 0.75-0.95 depending on the trap source

Why we publish confidence instead of forcing binary

A lot of verifiers report valid / invalid / unknown and silently route borderline results into one of the three buckets using opaque rules. It looks clean in the UI. It causes problems on send.

• A catch-all mailbox forced into valid pollutes your list with deliverable-but-meaningless addresses that bounce or get routed to a junk queue.
• A 4xx temporary failure forced into invalid permanently removes recoverable addresses you should retry in 24 hours.
• A timeout forced into valid (a pattern we've documented from independent benchmarks of two major competitors) leads directly to bounce rate spikes when those addresses get sent.

EmailShield exposes confidence so you can filter however your sending policy requires. A typical workflow:

≥ 0.90  → send (definitive valid or definitive invalid)
0.70-0.89 → send for marketing, re-verify high-value contacts
0.50-0.69 → hold, don't send without prior engagement
< 0.50  → do not send, re-verify in 24 hours

The CSV export from List Cleaning includes primary_confidence and per-tag confidences for every row.

DNS-only vs real SMTP: accuracy benchmarks by competitor

The table below maps publicly documented verification methods to the accuracy floors they produce. Method classifications come from each vendor's documentation or third-party teardowns; accuracy ranges combine vendor claims with independent benchmarks.

• Vendor claims as of May 2026 published pricing pages and documentation. Real-world ranges reflect bounce-back rates on representative B2B lists processed by each tool, drawn from public benchmarks and EmailShield comparative testing.

The pattern is consistent: tools that combine real SMTP handshakes with deterministic catch-all detection and dedicated infrastructure converge on 94-97% real-world accuracy. Tools that lean on DNS lookups, shared proxies, or per-email catch-all probing cap meaningfully lower.

The 99.8% number is bounded specifically to definitive labels with confidence ≥ 0.90. EmailShield doesn't claim 100% accuracy because no SMTP verifier can. We expose the uncertainty instead of hiding it under a forced verdict.

What this means for your verification workflow

The technical details only matter if they change how you actually run lists. Two specific behaviors come out of this architecture:

1. Single Email Verification for real-time forms

When a real-time API has to return a verdict before a form submission completes, the pipeline runs in under 2 seconds end-to-end: syntax in microseconds, DNS in 10-50ms, catch-all in 200ms-2s (cached if seen recently), SMTP RCPT in 500ms-5s through the proxy network. The Single Email Verification endpoint returns a JSON payload with primary label, confidence, and tag array. Drop it in front of signup, lead capture, or checkout to keep junk addresses out at the source.

EmailShield data: One SaaS client running 80K monthly signups added Single Email Verification to their registration flow and cut downstream onboarding email bounce rate from 6.1% to 0.4% in the first 30 days. The catch was that 11.3% of attempted signups got flagged as catch-all or low-confidence; they routed those into a separate manual review queue rather than blocking them outright. Net result: legitimate users still got through, but the bounce signal sent to Gmail and Outlook dropped below the 0.3% threshold Google enforces.

2. Bulk Verification and List Cleaning for periodic hygiene

Lists decay at roughly 2-3% per month. Even a perfectly clean list from January will be 24-36% stale by year-end. Bulk Verification processes uploaded CSV/TXT/XLSX files (up to 25,000 rows per upload in the current beta) at 100K emails per minute throughput, with per-MX rate limiting to avoid tripping anti-enumeration defenses on shared receivers.

List Cleaning sits one layer above raw verification: it ingests a list, runs it through the 4-stage pipeline, deduplicates, segments by primary label and confidence, and outputs separate CSVs for valid, catch_all, risky, and invalid. The catch-all segment goes through Domain Monitoring before you decide whether to send.

EmailShield data: An agency running List Cleaning across 30 client lists totaling 1.2M addresses over Q1 2026 found the bounce-rate improvement scaled inversely with list age. Lists under 3 months old dropped from 4.1% average bounce to 0.6%. Lists over 12 months dropped from 11.8% to 1.2%. The 12-month lists had more catch-all noise that even a high-accuracy verifier couldn't fully resolve, which is why we segment those into their own bucket instead of forcing them into valid.

What real SMTP verification cannot do (and we say so)

A complete picture of how email verifiers work has to include the boundaries. Three categories of address are not fully resolvable by SMTP alone:

1. Gmail and Microsoft 365 enumeration defenses. Both providers limit RCPT TO accuracy on the public MX. Gmail returns 250 for many invalid addresses on Google Workspace tenants depending on the tenant's catch-all settings. Microsoft 365 throttles or returns generic responses after a few probes per source IP. EmailShield mitigates this with proxy rotation and dedicated routing logic for those providers, but no SMTP-based tool can claim 100% accuracy on Gmail. Anyone who does is lying.

2. Greylisting servers. Receivers running greylisting return 451 Try again later to first-contact RCPT commands and only honor RCPT on the retry, several minutes later. Verifiers without retry logic mark these as failures and discard valid addresses. EmailShield's escalating-timeout retry handles greylisting correctly, but it adds latency.

3. Servers that defer validation to DATA. Some receivers accept any RCPT TO and only bounce after the full message body is transmitted. Verification-without-sending is impossible against those servers; EmailShield labels them with unknown and a low confidence score so you know the signal is unreliable.

This is why EmailShield's accuracy claim is bounded to definitive labels at confidence ≥ 0.90, and why the confidence column on every CSV export is the most important field on the result.

FAQ

How does email verification work using SMTP?

SMTP email verification opens a TCP connection to the recipient's mail server on port 25, runs EHLO and MAIL FROM commands, then issues RCPT TO with the target address. A 250 response code means the mailbox exists, 550 means it doesn't, and 4xx means try later. The verifier disconnects with QUIT before any message body is transmitted, so no email is ever sent. EmailShield runs this handshake through self-hosted proxy infrastructure with multi-port fallback (25 to 465 to 587 to 2525).

Is SMTP verification accurate?

On non-catch-all domains where the receiving server honors RCPT TO responses, SMTP verification reaches 95-99% accuracy. DNS-only verification caps at 91-94% because it can only confirm the domain accepts mail, not that a specific mailbox exists. EmailShield reports 99.8% verified accuracy on definitive labels by layering RCPT verification with deterministic catch-all detection and confidence scoring from 0.0 to 1.0.

Why do email verifiers return "unknown" results?

Unknown results come from servers that block enumeration (Gmail, Microsoft 365), greylisting (4xx temporary rejections), connection timeouts, or catch-all domains that return 250 for every address. EmailShield retries through different proxies with escalating timeouts (10s, 15s, 20s) before falling back to unknown, and assigns 0.30-0.40 confidence to those results so users can filter them instead of being forced into a wrong yes/no.

Does SMTP verification send an actual email?

No. SMTP verification stops at the RCPT TO command and disconnects with QUIT before the DATA command (which would transmit the message body). The recipient's mail server logs the connection but never receives or delivers a message. This is why properly run verification has zero impact on the recipient's inbox.

What is the difference between DNS lookup and SMTP verification?

DNS lookup checks if the domain has MX records configured, meaning the domain can receive mail in general. SMTP verification goes further: it opens a live connection to that MX server and asks whether the specific mailbox exists. DNS-only tools typically hit 91-94% accuracy because they pass any address on a valid domain, including non-existent ones. SMTP verification reaches 99% on definitive answers because it confirms the mailbox at the protocol level.

How accurate are email verification tools?

Marketing claims sit at 95-99% across most vendors, but independent benchmarks show real-world accuracy varies widely depending on how tools handle catch-all domains and enumeration-blocked providers. EmailShield benchmarks at 99.8% verified accuracy on definitive labels through real SMTP handshakes plus 4-stage pipeline orchestration, vs 91-94% for legacy DNS-only verifiers.

Can email verifiers detect catch-all domains?

Yes, through probe testing. The verifier sends an RCPT TO command for a deliberately fake address (something like definitely-does-not-exist-12345@domain.com). If the server returns 250 OK, the domain is catch-all. EmailShield runs this probe once per domain-MX pair, caches the result in Redis for 24 hours, and tags every email on that domain accordingly instead of wasting per-email SMTP probes.

Methodology

Data sources: EmailShield platform verification logs and result classifications across production traffic processed January 2026 through May 2026. Comparative accuracy ranges for competitor tools drawn from public vendor documentation, the May 2026 EmailShield comparative benchmark (sample size 250,000 addresses across 6 industry verticals), and independent third-party benchmarks referenced in Prospeo's 2026 verifier comparison and Hunter's 15-tool benchmark.

Time period: January 1, 2026 through May 15, 2026.

Sample size: 12.4M verifications processed through the EmailShield pipeline during the reference period, segmented by primary label and confidence band for accuracy benchmarking.

Limitations: The 99.8% accuracy figure applies to definitive labels with confidence ≥ 0.90 and is bounded to non-catch-all, non-enumeration-blocked domains. Catch-all and enumeration-protected addresses are labeled separately and excluded from the definitive accuracy denominator. Competitor accuracy ranges are estimates based on public benchmarks; exact methodology varies by tool and we cannot independently audit competitor source code or infrastructure. All pricing references reflect May 2026 published rates.

External references: RFC 5321 - Simple Mail Transfer Protocol, RFC 5322 - Internet Message Format, Google Postmaster Tools, Microsoft SNDS, M3AAWG Sender Best Common Practices.

Last updated: May 2026.

Written by Pavel Stoletov, CTO at EmailShield. Pavel leads email verification and deliverability engineering, with 12 years of experience building SMTP infrastructure, mail server orchestration, and proxy networks for high-volume verification. Author page - LinkedIn