How to verify an email address without sending to it

You can check an address without sending to it, but only partially. Syntax and DNS are deterministic. The SMTP-level check — asking the receiving server whether the mailbox exists — is unreliable at exactly the providers that hold most business email. A verifier that reports "98% deliverable" is reporting its own confidence, not a fact about your list.

The four layers, and what each one proves

1. Syntax. Does the address parse? Catches john@, john @example.com, john@example. Cheap, exact, and it only removes typing errors.
2. Domain and MX. Does the domain resolve, and does it publish MX records? dig mx example.com +short is the whole test. No MX and no A record means nothing can be delivered. This also flags disposable domains and parked domains.
3. SMTP callout (the "ping"). Open a connection to the MX host, say EHLO, MAIL FROM:<>, then RCPT TO:<target@example.com>, read the response code, and QUIT before DATA. A 550 5.1.1 User unknown means the mailbox does not exist. A 250 means the server accepted the recipient — which is weaker than it sounds.
4. Risk classification. Role addresses (info@, sales@, abuse@), known spam-trap patterns, free-mail addresses on a B2B list, and recently created disposable domains. This is heuristics, not verification.

220 mx.example.com ESMTP
EHLO verifier.example.net
250-mx.example.com
MAIL FROM:<>
250 2.1.0 Ok
RCPT TO:<jane@example.com>
550 5.1.1 <jane@example.com>: Recipient address rejected: User unknown
QUIT

Why the SMTP callout fails where it matters most

• Microsoft 365 commonly accepts at `RCPT TO` and bounces later. Recipient validation happens after the message is accepted, so a 250 tells you the domain is willing to take mail, not that the mailbox exists. This is the single biggest source of "verified" addresses that hard bounce.
• Google rate-limits and greylists probe traffic. A verifier hammering RCPT TO from a handful of IPs gets 421/450 responses, or nothing useful, and the verifier has to guess.
• Probing can damage the probing IP. Connections that never send DATA look exactly like address harvesting. If you build your own verifier, never run it from your sending IP or your sending domain.
• Greylisting returns a temporary failure by design. 450 4.7.1 Try again later is not a verdict.

The catch-all problem

A catch-all (or "accept-all") domain accepts RCPT TO for every local part, including zzqx@example.com. The standard detection is to probe a random address you know does not exist; if that is accepted, the domain is catch-all and every verdict for that domain is unknown.

Catch-all domains are common in small businesses and in companies that merged domains. What to do with them:

A sensible compromise is a small, slow first touch to catch-all addresses from a mailbox that is not your main one, and to remove anything that bounces before the list ever reaches your ESP.

Bulk verification: when it is worth it

Verify when a list is cold, imported, bought, scraped, pattern-generated, or older than about six months. Do not verify a list you already mail regularly and that bounces under 1% — you are paying to confirm what your bounce log already told you. Addresses decay at a few percent a year as people change jobs, so an annual pass over your dormant segments is reasonable; a monthly pass over your engaged segment is waste.

Target a hard bounce rate under 2%, and treat anything above 5% as a stop-sending event. Google does not publish a bounce threshold, but it does publish the complaint one: keep spam complaints below 0.3%. High bounce rates and high complaint rates almost always share a root cause — an address source you should not be using.

What verification cannot tell you

• Whether anyone reads the mailbox. A valid, abandoned mailbox is worse than a bounce: it accepts mail forever and never engages, which drags your engagement signal down.
• Whether the address is a spam trap. Pristine traps are, by construction, valid addresses that have never opted in to anything.
• Whether you are allowed to email the person. Verification is not consent.
• Whether your mail will reach the inbox. Verification protects your bounce rate. Placement is a separate measurement.

Mistakes to avoid

1. Treating a verifier's score as a guarantee. Suppress "invalid", quarantine "unknown", and accept that "valid" at a Microsoft 365 domain still carries bounce risk.
2. Verifying from your sending IP or sending domain. Use a provider, or isolated infrastructure.
3. Mailing the unknown bucket anyway "to see what happens". That is the bucket that produces the bounce spike.
4. Verifying instead of fixing intake. If every import needs a 20% scrub, change where the addresses come from: double opt-in, a real form, a reply.
5. Deleting soft bounces. A 4xx is a retry, not a removal. Remove on repeated failures, not on the first one.
6. Trusting one tool. For a high-value list, run a second verifier over the "valid" set and look at the disagreement — that is where your real risk sits.

A pre-send checklist

• Syntax and MX pass for every address
• Hard-bounce suppression list imported and applied
• Unknown/catch-all addresses held back from this send
• Role addresses removed unless you deliberately want them
• Authentication (SPF, DKIM, DMARC) passing for the sending domain
• A small first batch sent and its bounces read before the full send

MailPilot sits on the other side of this problem: it warms the mailbox and measures where your mail actually lands per provider, so once your list is clean you can tell whether a disappointing campaign was a list problem or a placement problem.