How to Verify an Email Address Exists Without Sending Mail

The bounce that cost you a week

Picture the Monday morning. Your welcome campaign went out on Friday, 14% of it bounced, and the sending provider has put the account under review. Nobody checked the list. A third of the bad addresses are plain typos (gmial.com), the rest were mailboxes that had never existed.

A test message is the obvious way to find out whether an address works, but it is slow, the recipient can see it, and the bounce arrives hours later. Most of the answer is available beforehand from DNS and a short, polite SMTP conversation. This tutorial walks through it, layer by layer, and is honest about where the answers stop being trustworthy.

One boundary first. Verification answers a narrow question: will a mail server accept a message for this address right now? It does not say who owns the address or whether anyone reads it. For that you need registration and breach checks, covered in our email OSINT guide. We use the fictional address jane.doe@example.com throughout, and the terminal output is illustrative.

Layer 1: Syntax, kept deliberately dumb

Reject obviously malformed input first: a missing @, spaces, a domain without a dot, consecutive dots. Do not try to implement the full RFC 5322 grammar. It allows forms no real provider issues, and an over-strict regex will reject valid addresses such as plus tags (jane.doe+news@example.com), which is how you lose real customers. A simple check plus the DNS step below catches nearly every typo that matters.

Layer 2: Does the domain accept mail?

A domain that can receive mail publishes MX (mail exchanger) records in DNS. Look them up with dig or nslookup:

$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

$ dig +short MX gmial.com
# (nothing) : the domain does not exist, probably a typo

How to read the result:

These two layers alone would have saved that Friday campaign from the typo third of its bounces. The rest needs the mailbox itself.

Layer 3: Ask the mail server, then hang up

To check the mailbox you connect to the MX server and start a normal SMTP transaction, but stop before any message is sent. The server's reply to RCPT TO says whether it would accept mail for that recipient. The diagram shows the whole conversation, including the extra probe that detects catch-all domains.

By hand, with nc, it looks like this:

$ nc mx1.example.com 25
220 mx1.example.com ESMTP
EHLO verifier.example.org
250-mx1.example.com
250 STARTTLS
MAIL FROM:<probe@example.org>
250 2.1.0 Ok
RCPT TO:<jane.doe@example.com>
250 2.1.5 Ok
RCPT TO:<no-such-user-x7q2@example.com>
550 5.1.1 User unknown
QUIT
221 2.0.0 Bye

Two recipients, two different answers: the server knows Jane and does not know no-such-user-x7q2. That difference is what makes the first answer meaningful. Here is how to read each reply code:

Where SMTP probing lies to you

RCPT probing is useful and far from definitive. Five things break it, and you will meet all of them:

• Port 25 is often blocked. Many residential ISPs and cloud providers block outbound port 25. Run probes from infrastructure that is allowed to talk SMTP. Your laptop timing out is usually this.
• Greylisting. Some servers reject first contact from an unknown sender with a 4xx code and accept a retry minutes later.
• Accept-then-bounce. Some large providers accept every recipient during the session and bounce later, or never. A 250 from them proves little.
• Reputation and rate limits. Many probes from one IP look like address harvesting. Servers throttle or block the source, and the IP can end up on blocklists. Keep volumes low and cache results.
• Anti-enumeration. Security-conscious servers deliberately answer the same for valid and invalid recipients.

Layer 4a: Catch-all domains

A catch-all (or accept-all) domain takes mail for any local part. Organisations set this up so misspelled addresses still reach someone. For verification it means a 250 reply is meaningless: the server would have said yes to anything.

Detecting it is simple. Probe a random local part that cannot plausibly exist, like no-such-user-x7q2@example.com in the session above. If the server accepts that too, mark every address on the domain "unknown", not "valid".

Layer 4b: Disposable and role addresses

Disposable addresses come from services that hand out temporary inboxes for minutes or hours. They are fully deliverable, so every SMTP check passes, but they tell you the person does not plan to be reachable later. Detection relies on a maintained list of disposable domains, and new domains appear constantly, so the list has to stay current. For sign-up abuse and fraud this is one of the most useful single signals you can get. The same idea applies to phone numbers, covered in how to detect disposable phone numbers.

Role addresses such as info@, sales@, support@, admin@ or noreply@ reach a function, not a person. They are valid, but a personal account registered with one deserves a second look, and marketing to them tends to perform poorly.

Putting the layers into one verdict

Four outcomes are enough. Run the checks in order and stop at the first that decides:

If you need to know whether the address belongs to a real, long-standing identity, check registrations and breach history next. An address that shows up in breach records from years ago has been in use for a long time; see how to check if an email was in a data breach. If you have a whole list to check rather than one address, bulk email lookup does the same search for every row of a CSV.

Unknown is a legitimate answer. Rounding it up to valid is how bounce rates climb.

Frequently asked questions