How to Check If an Email Address Is Valid Without Sending Anything

Here are the four checks, in the order they should run, and what each can actually prove.

1. Syntax

Does the address follow the rules for an email address? This catches typos, missing @ symbols and invalid characters.

It is cheap and instant, and it proves almost nothing. [email protected] is perfectly valid syntax and certainly not a real mailbox. Any tool that stops here is a spell-checker.

2. Domain and MX records

Every domain that receives mail publishes MX records in DNS, naming the servers that accept mail for it. If a domain has none, it cannot receive email and every address at it is dead.

You can check by hand:

$ dig +short MX gmail.com
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.

No MX record and no fallback A record means the domain cannot receive mail. RFC 5321 says a sender falls back to the domain's A record when no MX exists, so a missing MX alone is a strong signal rather than proof. A null MX (MX 0 .) is definitive: the domain has declared it accepts no mail. Either way, this is the cheapest check available, and it catches typo'd and abandoned domains.

3. Disposable and role checks

Two things worth knowing before you send anything:

Disposable domains — Mailinator, Guerrilla Mail and thousands of others — are throwaway inboxes. Technically the mailbox is real, but the person behind it will never see the message.

Role addresses — info@, sales@, admin@ — are read by several people or nobody, attract spam complaints, and are sometimes recycled into spam traps.

Neither is a hard failure. Both are decisions you should make deliberately rather than discover afterwards.

4. The SMTP mailbox check

This is the one that actually answers the question.

You connect to the domain's mail server and start the conversation you would start if you were delivering a message — then stop before sending anything:

$ telnet gmail-smtp-in.l.google.com 25

> HELO yourdomain.com
< 250 mx.google.com at your service

> MAIL FROM: <[email protected]>
< 250 2.1.0 OK

> RCPT TO: <[email protected]>
< 250 2.1.5 OK                    ← the mailbox exists

If the mailbox does not exist:

> RCPT TO: <[email protected]>
< 550-5.1.1 The email account that you tried to reach does not exist

Then QUIT. No message is sent, and nothing appears in anyone's inbox. The DATA command — the one that actually transmits a message — is never issued.

That difference between 250 and 550 is the whole of email verification.

Why you probably cannot run this yourself

Try that telnet command from your laptop and it will most likely hang. Almost every home ISP and cloud provider blocks outbound port 25 to prevent spam. We measured it on two major hosts:

Host	Outbound port 25
Railway	Blocked
DigitalOcean	Blocked

This is the single reason email verification exists as a paid service. The check itself is simple; being on a network permitted to make it, from an IP with a clean reputation and matching reverse DNS, is the hard part.

It is also worth knowing because of how some tools handle it. If a verifier's SMTP check fails and the code falls back to reporting valid, then every address on a live domain passes and nothing has actually been verified. We know that failure mode intimately — our own engine did it until we found it.

What cannot be answered

Two cases defeat the method entirely:

Catch-all domains accept every address at the domain, real or not. Acceptance proves nothing, so nothing can be confirmed. We wrote about that here.

Providers that do not answer clearly. Yahoo often declines to confirm or deny a mailbox at the RCPT stage, so the probe is inconclusive. iCloud rejects unknown users with 550 5.1.1, and Microsoft 365 business tenants usually reject unknown recipients during the conversation. Consumer Outlook.com and Hotmail do too, but Microsoft is currently refusing mailbox checks from our server's network, so SimpleVerifier does not probe them right now and marks those addresses risky instead.

An honest verifier reports both as risky. A verifier that reports them as valid is guessing and hoping you never check.

The short version

1. Syntax — catches typos, proves little
2. MX records — shows whether a domain can receive mail at all
3. Disposable and role flags — decisions, not failures
4. SMTP mailbox check — the actual answer, when the network allows it

Anything that cannot be established should come back risky. The tools worth paying for are the ones willing to tell you when they do not know.

How each big provider answered on 23 October 2026 is in our mailbox provider study.

Check your own list

Paste one address into the checker above, or upload the whole CSV on the verify page: the first 100 email checks are free with a Google sign-in, no card. Every address comes back valid, risky or invalid with a reason and send advice, and you can download only the safe-to-send rows. Nothing is sent to the people on the list. For bigger or recurring lists, see bulk email verification, list cleaning and pricing.