Verifying B2B emails without sending a single one: how MX-only validation actually works

OutSend — Tue, 21 Jul 2026 12:08:08 +0000

When you're building or using a B2B prospecting tool, "verified email" usually means one of two things: a real SMTP handshake (connect, MAIL FROM, RCPT TO, read the response, disconnect without sending) or a lighter DNS-only check. Most articles about email verification gloss over why you'd pick one over the other. This post walks through the mechanics, the tradeoffs, and a real-world constraint that forces the decision for a lot of small/medium senders: outbound port 25 being blocked.

The three layers of "is this email real"

Syntax check — regex/RFC 5322 parsing. Catches typos (jhon@gmial.com), catches obviously malformed input. Cheap, instant, but tells you almost nothing about deliverability.
DNS / MX check — does the domain have valid MX records? Does it resolve? This confirms the domain can receive mail, not that the mailbox exists.
SMTP handshake (no send) — connect to the MX host on port 25, issue RCPT TO:<address>, read the server's response code (250 = accepted, 550 = mailbox doesn't exist, etc.), then QUIT before DATA. This is the only layer that actually confirms mailbox existence — and it's also the layer most likely to break in production.

Why the SMTP handshake breaks for so many senders

Outbound TCP port 25 is blocked by default on most consumer ISPs and a growing number of cloud/VPS providers (it's one of the oldest anti-spam measures on the internet — stops compromised machines from becoming open relays). If your verification worker runs on a box where port 25 egress is blocked, every RCPT TO attempt just times out. You get zero signal, not a "550 doesn't exist" — just silence, indistinguishable from a slow mail server.

Three ways to deal with this:

Route SMTP checks through infrastructure with confirmed port 25 egress (a subset of your VPS fleet, or a dedicated relay you control). Works, but adds an ops dependency you now have to monitor.
Pay for a third-party verification API that already solved this problem. Fine at low volume, expensive fast, and you're trusting an external service with your prospect list.
Fall back to MX-only + heuristics when port 25 is unavailable, and be honest about the confidence level of the result instead of pretending it's a full SMTP verification.

We went with the third option for our own scraper/enrichment pipeline: when port 25 egress isn't available on a given worker, the check degrades gracefully to "domain has valid MX, catch-all detection where possible, syntax valid" rather than silently returning a false "verified." The label shown to the end user reflects which layer actually ran — "MX confirmed" is not the same claim as "mailbox confirmed," and conflating the two is how verification tools end up with inflated "95% deliverable" numbers that don't survive contact with a real campaign.

Catch-all domains are the other trap

Even with full SMTP access, a lot of corporate mail servers respond 250 OK to any RCPT TO on their domain (catch-all configuration) — meaning a successful handshake doesn't actually prove the specific mailbox exists. Standard mitigation: probe a random, almost-certainly-nonexistent local part (asdkjh1928@domain.com) on the same domain. If that also comes back 250, the domain is catch-all and your original address's "verified" status should be downgraded to "plausible, unconfirmed" rather than reported as a clean hit.

The practical takeaway

If you're evaluating (or building) an email verification step in a prospecting pipeline, ask two questions before trusting a "valid" badge:

Did this go through an actual SMTP handshake, or just an MX/DNS check? (Both are useful — they are not the same guarantee.)
Was catch-all detection run, and how does the tool label a catch-all hit vs. a genuinely confirmed mailbox?

Most vendors don't surface this distinction because "98% verified" sells better than "72% SMTP-confirmed, 26% MX-only (port 25 blocked on this worker), catch-all flagged separately." We'd rather ship the second, less flattering number, because it's the one that actually predicts bounce rate.

We build OutSend, an all-in-one B2B lead generation platform — Google Maps scraping, email enrichment, deliverability verification and no-code pipelines chained end-to-end. Free during alpha, no credit card required. This post describes real constraints we hit building the verification layer, not a product pitch — happy to go deeper on any of it in the comments.

OutSend: an all-in-one B2B lead generation tool (Google Maps scraping, email finder, deliverability check)

OutSend — Fri, 17 Jul 2026 09:51:20 +0000

We built OutSend because prospecting for B2B leads usually means stitching together 3-4 different tools: a Google Maps scraper, an email finder, an email verifier, and a spreadsheet to tie it all together.

What it does

OutSend is an all-in-one B2B lead generation platform:

Scrape business leads from Google Maps by city, category and keyword
Enrich them with emails (email finder)
Verify deliverability before you send anything (anti-bounce check)
Chain scraping, enrichment and validation end-to-end with no-code pipelines
Export clean CSV files in seconds

Stack

FastAPI + SQLite on the backend, Alpine.js on the frontend, self-hosted (no paid third-party SaaS dependency in the core pipeline).

Who it's for

Sales teams, agencies and founders who prospect at scale and are tired of paying for (and wiring up) four different subscriptions to do one job.

It's free during the alpha, no credit card required: https://outsend.xyz

Happy to answer any questions about the scraping/enrichment pipeline in the comments.

DEV Community: OutSend