You can verify an email address without sending an email by checking three things in order: that the address is correctly formatted, that its domain has working MX records, and, if you have the access, that the domain’s mail server accepts the recipient during an SMTP conversation that you end before any message is sent. The first two checks are reliable and anyone can run them in a minute. The third gives a strong hint but is often inconclusive, because many servers accept every address or refuse to answer.

Below is a hands-on walkthrough of each method, with the exact commands and what the responses mean.

Method 1: Check the address format by eye (or with a regex)

Before touching DNS, rule out addresses that can’t possibly work. Look for:

Exactly one @, with something on both sides.
No spaces, commas, or angle brackets in the address itself.
A domain with at least one dot and a real-looking top-level domain (.com, .org, .io, .co.uk).
No dot at the start or end of the local part, and no two dots in a row (john..smith@).
A total length of 254 characters or fewer. That limit comes from RFC 3696 erratum 1690, which corrected the original figure based on the path limit in RFC 5321.

For code, the pragmatic choice is the pattern the HTML standard uses for <input type="email">. The WHATWG HTML spec describes it as a “willful violation” of RFC 5322, because the full RFC grammar allows things (quoted strings, comments) that no real user should type into a form. That trade-off is usually right.

A format check tells you an address is possible. It says nothing about whether it exists.

Method 2: Look for domain typos

Many “invalid” addresses are real people who mistyped a well-known domain. Before you discard an address, scan the domain for near-misses:

Typed	Probably meant
`gmial.com`, `gmal.com`, `gmail.co`	`gmail.com`
`yaho.com`, `yahooo.com`	`yahoo.com`
`hotmial.com`, `hotmail.co`	`hotmail.com`
`outlok.com`	`outlook.com`
`icloud.co`	`icloud.com`

Some typo domains are actually registered by third parties, so they may even pass an MX check. That’s why typo detection is its own step rather than something DNS catches. Our post on common email typos has a longer list.

Method 3: Look up the domain’s MX records

This is the most useful check you can run without sending anything. MX records tell the world which servers accept mail for a domain. If there are none, and no fallback, the address can’t receive email.

On macOS or Linux

$ dig +short MX widgets.example
10 aspmx.l.google.com.
20 alt1.aspmx.l.google.com.

The number is the preference; lower values are tried first. The hostnames tell you who hosts the mailbox. In this example, Google Workspace handles mail for the domain.

On Windows

C:\> nslookup -type=mx widgets.example
widgets.example   MX preference = 10, mail exchanger = aspmx.l.google.com
widgets.example   MX preference = 20, mail exchanger = alt1.aspmx.l.google.com

In a browser

If you’d rather not use a terminal, Google’s Admin Toolbox Dig lets you pick “MX” and query any domain.

Reading the result

One or more MX hosts returned: the domain accepts mail. Move on.
NXDOMAIN (domain doesn’t exist): the address is dead. This is common with defunct companies and typos.
No MX records but the domain exists: RFC 5321 (section 5.1) says senders treat the domain’s A or AAAA record as an implicit MX. Delivery may still work, but a business domain without MX records is a yellow flag.
A single MX record of 0 .: this is a null MX, defined in RFC 7505. The domain is explicitly saying it accepts no mail. Treat the address as invalid.

For more ways to run this check, including from code, see how to check MX records for any domain.

Method 4: Run a manual SMTP check

This is the method most guides mean when they say “verify without sending.” You connect to the domain’s mail server, start a normal delivery, give the recipient address, read the response, and then quit before sending any message content.

Before you try it

Two practical warnings first:

Outbound port 25 is often blocked. Many home ISPs and cloud providers block it by default to stop spam. If your connection just hangs, that’s probably why. Our post on why EC2 blocks port 25 explains the cloud side.
Don’t do this at volume from an IP you care about. Mail servers notice when one IP opens lots of connections and probes recipients without delivering anything. That’s exactly how address harvesters behave, so you can end up rate-limited or blocklisted.

The conversation

Connect to the highest-priority MX host from Method 3:

$ telnet aspmx.l.google.com 25
220 mx.google.com ESMTP ...
EHLO mail.yourdomain.com
250-mx.google.com at your service
...
MAIL FROM:<you@yourdomain.com>
250 2.1.0 OK
RCPT TO:<jane.doe@widgets.example>
250 2.1.5 OK
QUIT
221 2.0.0 closing connection

Use a real hostname and a real sender address on a domain you control. Some servers reject obviously fake EHLO names or senders, which gives you a misleading result.

What the RCPT TO reply means

Reply	Meaning	What to conclude
`250 2.1.5 OK`	Recipient accepted for now	Likely valid, unless the domain accepts everything
`550 5.1.1 ...`	Bad destination mailbox (RFC 3463)	Address doesn’t exist
`550 5.2.1 ...`	Mailbox disabled	Treat as invalid
`452 4.2.2 ...`	Mailbox full (temporary)	Exists but can’t take mail right now
`450` or `421` with “try again later”	Often greylisting	Inconclusive; retry later or treat as unknown
`550 5.7.1 ...`	Policy rejection of you	Says nothing about the address

Google documents its own versions of these messages in its Gmail SMTP error reference. For example, Gmail’s 550 5.1.1 reply says the account you tried to reach doesn’t exist and suggests checking for typos.

Why a 250 isn’t proof

An accepted RCPT TO is weaker evidence than it looks:

Catch-all domains accept every recipient and sort it out later. random-gibberish@ gets the same 250 as ceo@. You can test for this by trying an address that can’t exist; if that’s accepted too, the domain is catch-all. See how to handle catch-all domains.
Accept-then-bounce servers say yes during the SMTP conversation and send a bounce message afterward.
Greylisting temporarily rejects unknown senders on purpose. RFC 6647 describes it: the server returns a 421 or 450, and legitimate mail servers retry later. A one-shot manual test can’t get past it.

What about VRFY?

SMTP has a VRFY command that, in theory, asks the server whether a user exists. In practice it’s rarely useful. RFC 5321 lets administrators disable it, and when a server can’t or won’t verify, it’s supposed to answer 252, which means “can’t verify, but I’ll accept the message and try to deliver it.” Most public mail servers either disable VRFY or return 252 for everything, so RCPT TO is the check that matters.

Method 5: Use a free email verifier

Running Methods 1 through 3 by hand works for one address. For more than a few, a tool is faster and more consistent.

Our free email verifier automates the parts that are reliable: syntax, domain and MX lookup (including null MX), typo suggestions for common providers, disposable domain detection, role-based address detection (info@, sales@), and free-provider detection. It deliberately does not open an SMTP connection to the recipient’s server, so it won’t claim a specific mailbox exists. For most list-cleaning and form-validation work, the DNS-level checks catch the bulk of bad addresses without the reputation risk of SMTP probing.

Method 6: Search for the address publicly

For a single high-value contact, such as a sales prospect or a partner, a quick web search for the exact address in quotes sometimes turns up a company page, a conference speaker bio, or a public profile. It’s slow and only works for people who publish their address, but a hit is strong evidence the address is real and current.

Avoid tricks that involve interacting with someone else’s account, such as starting a password reset to see whether an account exists. That’s account probing, it can trigger security alerts for the owner, and it doesn’t belong in a legitimate verification process.

Which method should you use?

Situation	Best approach
One address, quick sanity check	Methods 1–3, or the verifier on this site
Signup or checkout form	Automated syntax, MX, typo, and disposable checks in real time
Cleaning a list before a campaign	Bulk DNS-level checks, then bounce handling on the first send
A single important B2B contact	MX check, then SMTP test or public search if you need more certainty
You need proof the person owns the inbox	Send a confirmation email; nothing else proves ownership

The last row is worth repeating. Every technique on this page estimates deliverability. If you need to know a real person controls the address, use double opt-in.

FAQ

Is it legal to verify an email address without sending a message?

Checking syntax and public DNS records is just reading public information. SMTP checks use the standard mail protocol the way any sending server would. Where you get into trouble is what you do with the addresses afterward; sending marketing email in the US still has to follow CAN-SPAM, and our post on consent and email law covers the broader picture.

Why does the SMTP check say every address is valid for some domains?

That domain is probably configured as catch-all, so it accepts any recipient at the SMTP stage and decides later. Many corporate domains are set up this way. The honest result for those addresses is “unknown” or “accept-all,” not “valid.”

Can I verify a Gmail or Outlook address without sending?

You can confirm the format and that the domain’s MX records are fine, and you can check for typos like gmial.com. Mailbox-level results from big providers are less predictable, and there’s no external check that guarantees a specific consumer inbox exists and is active.

Why does my telnet connection to port 25 time out?

Your ISP or cloud provider is probably blocking outbound port 25. That’s common and intentional. Use a DNS-based verifier instead, or run SMTP checks from infrastructure that’s allowed to send mail.

How to Verify an Email Address Without Sending an Email