You want to know if an email address is real before you send to it - without sending a test email and revealing your intent (or bouncing). The good news: SMTP-based verification can check whether a mailbox exists without sending anything. The bad news: some methods people try don’t actually work. This guide covers what works, what doesn’t, and why.
| Method | What it checks | Accuracy | Speed |
|---|---|---|---|
| 1. Format validation | Syntax only (@, domain, TLD) | Low - format ≠ deliverable | Instant |
| 2. MX record lookup | Domain has mail server configured | Medium - MX ≠ mailbox exists | < 1 second |
| 3. SMTP handshake | Mailbox exists on the server | High - best available signal | 1-5 seconds |
| 4. Email verification API | All of the above + catch-all scoring | Highest - multi-signal | 1-3 seconds |
| 5. Sending a test email | Actual delivery | N/A - this defeats the purpose | Minutes |
Format validation checks whether a string matches the pattern of an email address: has an @ symbol, a local part, a domain, and a TLD. This is what ISEMAIL() in Google Sheets does, and what most programming language regex validators do.
Format validation is useful as a first-pass filter - it catches obvious typos like “john@” or “@domain.com”. It does not tell you anything about whether the mailbox exists.
Example: these all pass format validation but don’t deliver:
[email protected] ✓ format valid, domain doesn’t exist
[email protected] ✓ format valid, mailbox may not exist
[email protected] ✓ format valid, likely not a real address
MX record lookup checks whether the email domain has mail server records configured in DNS. A domain without MX records can’t receive email at all - if there are no MX records, the address is definitely undeliverable.
This is a useful second-pass filter after format validation. But having an MX record doesn’t mean the specific mailbox (the part before the @) exists. [email protected] has valid MX records but the mailbox doesn’t exist.
Check MX records yourself with nslookup:
nslookup -type=MX gmail.com
Returns: gmail-smtp-in.l.google.com (priority 5), alt1.gmail-smtp-in.l.google.com, etc.
SMTP verification connects directly to the mail server and goes through the beginning of the email delivery protocol - enough to ask “does this mailbox exist?” - without sending any message. Here is what happens step by step:
SMTP response codes to RCPT TO:
250Mailbox exists (deliverable)550User unknown / mailbox does not exist421Service temporarily unavailable452Mailbox full (mailbox exists, inbox is full)Why SMTP verification can’t always give a definitive answer
Some mail servers are configured as “catch-all” - they respond 250 OK to EVERY RCPT TO command, regardless of whether the mailbox actually exists. This is common in corporate environments where all-mail-to-the-domain gets routed to a central inbox or delivery check.
In B2B cold email, 20-40% of addresses are on catch-all domains. On these domains, basic SMTP verification is not enough. This is where BounceZero’s multi-signal approach adds value: instead of returning a binary catch-all label, it uses MX provider fingerprinting, historical bounce patterns, domain age, and other signals to produce a deliverability score (0-100) for catch-all addresses.
An email verification API does everything above (format check, MX lookup, SMTP handshake) plus additional enrichment: disposable email detection, role-based address detection, catch-all scoring, and domain reputation signals. This multi-layer approach catches more bad addresses than any single method.
BounceZero API - single email verification:
curl -X GET "https://api.bouncezero.io/v1/[email protected]" \ -H "Authorization: Bearer YOUR_API_KEY" # Response: { "email": "[email protected]", "result": "valid", "format_valid": true, "mx_found": true, "smtp_valid": true, "disposable": false, "catch_all": false, "catch_all_score": null, "confidence": 0.97 }
Yes. SMTP verification tools connect to the mail server that handles the email domain and simulate the beginning of a message delivery - enough to confirm whether the mailbox exists - without actually sending any email. This is the method used by all professional email verifiers including BounceZero.
SMTP verification works in 3 steps: (1) DNS lookup to find the MX records for the email domain; (2) TCP connection to the mail server on port 25; (3) SMTP handshake through EHLO, MAIL FROM, and RCPT TO commands. The server’s response to RCPT TO tells you if the mailbox exists. A 250 response means it exists; a 550 response means it doesn’t.
A catch-all domain (also called accept-all) is configured to accept ALL incoming email at the SMTP level, regardless of whether the specific mailbox exists. This means SMTP verification gets a 250 OK response even for non-existent addresses. BounceZero handles catch-all domains by using additional signals to produce a 0-100 deliverability score rather than just labeling the domain as catch-all.
BounceZero uses SMTP verification + multi-signal catch-all scoring to tell you which addresses will deliver before you send to them. No test emails, no bounces, no domain damage.
Ayoub built BounceZero's 5-stage validation pipeline, its dedicated BGP-announced IP infrastructure, and the Patroni HA PostgreSQL cluster behind every verification. Previously built high-volume email delivery infrastructure. Trained at 1337 Benguerir (École 42 network, 2019). Open-source: bgp_analyzer.
Deep-dive guides on how email verification and inbox placement work
272,446-domain census: DMARC gap, provider divide, catch-all rates
10.2M verifications: 12.3% of addresses are dead, and where they hide
826K re-verifications: only 19% of valid addresses survive 90 days
True catch-all is 1.4% - most of what looks catch-all is unprobeable providers
info@ bounces 4.5x more than personal addresses - measured, not guessed
The 3x invalid-rate gap that vanishes when you control for domain size
Explore other topics