To verify an email address without sending one, you check it at the mail-server level: validate the syntax, confirm the domain's MX records, then open an SMTP conversation and issue a RCPT TO command that asks the receiving server whether the mailbox exists—all without ever delivering a message.
That same three-step chain is how you tell if an email address is real: a real address has correct syntax, lives on a domain that can receive mail, and is accepted by name when you probe it. The rest of this guide walks through each step, the verdicts you'll get back, why you should never "just send a test email," and the one configuration—catch-all domains—where this method runs out of road.
What does it mean to verify an email without sending?
Verifying an email without sending means confirming that a mailbox exists by talking to the mail server that hosts it, rather than by delivering a message and waiting to see if it bounces. Every step happens during a handshake with the receiving server—no email is ever placed in anyone's inbox.
Think of it as knocking on a building's front desk and asking "does apartment 4B exist?" versus mailing a package and seeing whether it comes back marked "return to sender." The first approach gives you an answer in milliseconds and never bothers the resident; the second is slow, leaves a paper trail, and damages your standing with the postal service if you do it at scale.
The three checks, in order
No-send verification is a pipeline. Each stage can rule an address out before the next one runs:
- Syntax: is the address even a valid format?
- MX records: can the domain actually receive mail?
- SMTP RCPT TO: does this specific mailbox exist?
How does no-send verification actually work?
No-send verification works by running the address through syntax, DNS, and SMTP checks in sequence. Here's what happens at each layer—and the verdict each one can return.
| Check | What it confirms | How |
|---|---|---|
| Syntax | Address is correctly formatted | Parse local part + domain against RFC rules |
| MX records | Domain can receive email at all | DNS lookup for the domain's mail exchangers |
| SMTP RCPT TO | The specific mailbox exists | Open SMTP, send MAIL FROM + RCPT TO, read the reply code |
| Catch-all signal | Whether the server accepts everything | RCPT TO a random, non-existent mailbox and watch for acceptance |
Step 1 — Syntax validation
The cheapest check happens before any network call. The verifier confirms the address has a valid local part, a single @, and a domain with a real TLD. This catches typos like jane@@acme.com or jane@acme instantly, with zero impact on the receiving server.
Step 2 — MX record lookup
Next, a DNS lookup asks whether the domain publishes MX (mail exchanger) records—the records that tell the world which servers accept that domain's mail. No MX records (and no fallback A record) means the domain can't receive email, so the address is dead no matter how it's spelled.
Step 3 — The SMTP conversation
This is the step that does the real work. The verifier connects to the mail server named by the MX record and begins an SMTP handshake—the same opening moves a real sender would make—but stops short of delivery:
→ connect to mx.acme.com:25
→ HELO verifier.example
→ MAIL FROM:<[email protected]>
→ RCPT TO:<[email protected]>
← 250 OK (mailbox exists)
→ QUIT (no DATA, no message sent)
The decisive moment is the server's reply to RCPT TO. A 250 means the mailbox is accepted; a 550 ("user unknown") means it doesn't exist. Crucially, the verifier sends QUIT instead of DATA—so no body, subject, or message is ever transmitted. The mailbox owner sees nothing.
How can you tell if an email address is real?
You can tell if an email address is real by reading the combined result of those checks as a single verdict. Verifiers usually collapse the outcome into one of four labels:
Valid (ok)
Syntax passes, the domain has MX records, and the server accepted the mailbox on RCPT TO. Safe to send.
Invalid
A step failed—bad syntax, no MX records, or a 550 rejection. The address is dead; sending will bounce.
Catch-all (accept-all)
The server accepts every address you probe, including obviously fake ones—so a plain RCPT TO can't prove the specific mailbox is real.
Unknown
No definitive answer—often a catch-all domain, a server rate-limiting probes, or a greylisting policy. Not the same as "invalid."
The first two verdicts are easy. The trouble is that a large share of real B2B addresses land in the third bucket—and a plain no-send check can't tell you which of those are genuine. That's the wall we get to below.
Why not just send a test email?
Because sending a test email is the slow, risky, reputation-damaging version of the exact question no-send verification answers in milliseconds. "Send it and see if it bounces" feels intuitive, but it's the wrong tool for checking whether an address is real.
What a test email actually costs you
- 1.It delivers an unsolicited message.
If the mailbox does exist, you've now emailed someone who never asked to hear from you—the opposite of a clean, consent-aware program.
- 2.Dead addresses bounce.
Every bounce is a strike against your sender reputation. Verify first and those bounces never happen.
- 3.You can hit spam traps.
Some invalid addresses are recycled into spam traps. Mailing one can get your domain blacklisted—damage a no-send check would have prevented.
- 4.It's slow and unscalable.
You'd wait for bounce notifications that may take hours or never arrive. SMTP verification answers per-address in milliseconds.
For the bigger picture on how bounces and unverified lists erode inbox placement, see hard bounce vs soft bounce and what email verification is.
Where no-send verification hits a wall: catch-all domains
No-send verification breaks on catch-all domains. A catch-all (also called accept-all) domain is configured to accept mail for every address at the domain—even ones that don't exist. So when your verifier sends RCPT TO, the server replies 250 OK whether the mailbox is real or not. The SMTP signal is gone, and a basic check can only return "unknown."
This isn't a rare edge case. Catch-all configurations are common at mid-market and enterprise companies—the kind of accounts B2B teams most want to reach—and they make up roughly 40-60% of B2B email addresses. If you stop at a plain no-send check, you're forced to either guess or suppress a huge slice of your list. (For the full breakdown, read the hub guide: What is a catch-all email?)
How Enrichley resolves the "unknown"
This is precisely the gap Enrichley's catch-all verifier closes. Instead of stopping at the SMTP response, it analyzes additional signals to decide whether an individual mailbox on a catch-all domain is real—turning "unknown" into a usable verdict.
- Verifies individual addresses on catch-all domains, not just the domain
- Recovers roughly 20-30% more usable emails others discard as "risky"
- Keeps contacts you've already paid for from Apollo, ZoomInfo, or Cognism
In short: syntax, MX, and SMTP checks verify most addresses without sending a thing— and a dedicated catch-all verifier handles the rest, so you never have to choose between a clean reputation and a complete list.
Frequently asked questions
How do you verify an email without sending one?+
You verify an email at the mail-server level instead of delivering a message. First validate the syntax, then confirm the domain has MX records, then open an SMTP conversation with the receiving server and issue a RCPT TO command for the address. The server's response tells you whether the mailbox exists—all without a message ever landing in someone's inbox.
How can you tell if an email address is real?+
An address is real when it passes three checks in order: valid syntax (a correctly formatted local part and domain), a domain that publishes MX records so it can receive mail, and an SMTP server that accepts the specific mailbox on a RCPT TO probe. If any step fails the address is invalid; if the server accepts every address you test, the domain is catch-all and a single check can't confirm the mailbox.
Why not just send a test email to verify an address?+
Sending a test email defeats the purpose. It delivers an unsolicited message, exposes your sending domain to bounces and spam-trap hits, and harms your sender reputation if the address is dead. No-send verification asks the mail server whether a mailbox exists without ever delivering anything, so you keep a clean reputation while you clean your list.
Why does no-send verification fail on catch-all domains?+
Catch-all (accept-all) domains are configured to accept mail for every address at the domain, even ones that don't exist. So an SMTP RCPT TO check always returns 'accepted,' and standard no-send verification can only mark the address 'unknown.' Resolving these requires specialized signals—Enrichley's catch-all verifier is built for exactly this case.
What does a verification result of 'unknown' mean?+
'Unknown' means the check couldn't get a definitive yes or no—most often because the domain is catch-all, the server is rate-limiting probes, or it deliberately accepts all RCPT TO commands to hide which mailboxes exist. It does not mean the address is bad; it means a basic SMTP check can't decide, which is where catch-all verification comes in.
Verify the addresses a basic check calls "unknown"
Syntax, MX, and SMTP checks get you most of the way—Enrichley's catch-all verifier gets you the rest. Confirm which catch-all addresses are real without ever sending a message.
Try the Catch-All Verifier