How to Verify an Email Address Without Sending an Email

You can verify an email address without sending anything by running three checks in order: the syntax, the domain's mail servers (its MX records), and the mail server's answer when asked, at the start of an SMTP conversation, whether it would accept mail for that address. The conversation ends before any message is sent. When the server gives a clear yes or no for that one address, the result is reliable; when it accepts every address or won't answer, the honest verdict is catch-all or unknown, not valid.

Step 1: Check the syntax

An address is a local part, an @ sign and a domain. RFC 5322 defines the format, and RFC 5321 caps the local part (the bit before the @) at 64 octets. The standards allow some odd forms, such as quoted local parts, but business addresses rarely use them, so a strict check costs little.

The syntax check matters most for addresses collected from websites and old spreadsheets, which pick up predictable junk:

• Copy-paste leftovers: a mailto: prefix, spaces, or the period from the end of a sentence ([email protected].).
• Obfuscated addresses: info [at] acme [dot] example, written that way to hide from harvesting bots. Fix them or drop them.
• Template placeholders: [email protected], [email protected] and similar text from website themes that nobody replaced.
• Image file names: retina images such as [email protected] look like addresses to a careless pattern.
• Typos in big domains: gmial.com, hotmial.com, outlok.com.

This step is free and instant, and every bad row it removes is one the slower checks don't have to touch.

Step 2: Check the domain and its mail servers

Next, look up the domain's MX records in DNS: the servers that accept mail for it. For a single domain you can do it by hand with nslookup -type=mx acme.example (Windows and macOS) or dig mx acme.example (macOS and Linux), or with any online DNS lookup.

DNS also catches domains that expired, domains parked for sale, and companies that rebranded and let the old domain go. Look up each domain once, not once per address: fifty addresses at one company need one lookup.

Step 3: Ask the mail server with an SMTP handshake

Mail servers talk to each other in SMTP, defined in RFC 5321. A verifier opens the same conversation a sending server would and hangs up before the message. Here's a simplified exchange, where S is the mail server and C is the checker:

S: 220 mx.acme.example ready
C: EHLO checker.example
S: 250 mx.acme.example
C: MAIL FROM:<[email protected]>
S: 250 OK
C: RCPT TO:<[email protected]>
S: 550 5.1.1 No such user
C: RCPT TO:<[email protected]>
S: 250 OK
C: QUIT
S: 221 Bye

Two things happened. The server rejected a made-up address, which shows that it knows which mailboxes exist, so its "yes" means something. Then it accepted the real address. The checker never sent DATA, the command that carries a message, so nothing was delivered and the owner of the mailbox sees nothing.

Why not just ask directly? SMTP has a VRFY command meant for exactly this, but RFC 5321 lets servers disable it for security reasons, and many do, or answer 252 (can't verify, but will try to deliver). So checkers use RCPT TO instead.

Why you shouldn't run these checks yourself at volume

Walking through one address teaches you how verification works. Checking a whole list from your own computer or server is a bad idea:

• Port 25 is often blocked. Many internet providers and cloud platforms block outgoing connections to port 25, the port mail servers listen on. Google Cloud's documentation says: "Due to the risk of abuse, connections to destination TCP Port 25 are blocked when the destination is external to your VPC network."
• Servers read many checks as an attack. Lots of RCPT TO checks from one IP address look like address harvesting, known as a directory harvest attack. Servers slow down, block or blocklist that address, and if your real email leaves from the same one, you've hurt your own deliverability.
• A badly configured checker gets refused. A checker without proper reverse DNS or a sensible EHLO name is turned away, and every refusal becomes a false "unknown".

For more than a handful of addresses, use a verification service, or a lead tool that verifies as part of the job. Glintscout, for example, verifies every address it finds on Google Maps and its other sources: each one gets a single verdict (valid, invalid, catch-all or unknown) from a check that contacts the mail server without sending an email, an optional second verification re-checks the unknown ones, and only valid addresses go into the CSV.

How to read the server's reply

The reply codes carry the verdict. RFC 3463 defines the detailed codes that follow the first three digits; 5.1.1, for example, means the mailbox doesn't exist.

Why some answers stay uncertain

Catch-all domains

A catch-all (or accept-all) server says yes to every address on its domain, real or not, and sorts the mail out later: a shared inbox, a forward, or a bounce after the fact. That's why a checker tries a made-up address first. If that's accepted too, the server's yes tells you nothing about the real address. Catch-all describes the domain, not the address: plenty of real, read mailboxes sit on catch-all domains. Catch-all emails explained covers whether to send to them.

Greylisting

Greylisting turns away mail from senders a server hasn't seen before, on the assumption that a real mail server will try again. RFC 6647 defines it as "the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism" and recommends that, by default, retries arriving between one minute and 24 hours after the first attempt are let through. A first check that meets greylisting gets "try later", and a second check after a pause often gets a real answer. That's what a second verification of unknown addresses is for.

Gateways, rate limits and silent servers

Some domains sit behind a filtering gateway that answers for the real mail server. When the gateway accepts an address that the server behind it later rejects, the check passes and the message still bounces. Other servers limit how many recipients one connection may check, or slow down clients they don't trust until the check times out. Large free-mail providers have their own policies for these checks, and verifiers handle their addresses in different ways.

Valid, but not safe to mail

An abandoned mailbox that a provider has turned into a spam trap can accept mail and pass every check. Verification can't detect that; list hygiene can. Yahoo's sender best practices put it plainly: "Remove invalid recipients from your list promptly." And don't keep mailing addresses that have ignored every message.

What each verdict means, and what to do

Key takeaway: a verifier can only be as certain as the mail server lets it be. Send to valid, drop invalid, re-check unknown, and treat catch-all as a risk you test in small batches, never as a yes.

Some tools add labels that describe the kind of address rather than whether it works. "Role-based" marks addresses such as info@ or sales@; for a small business, that's often the only published address and the right one to use. "Disposable" marks temporary inbox services, which don't belong in a B2B list. "Free mail" marks personal providers such as Gmail.

What verification can and can't tell you

Even a clean "valid" answers only one question: could this address receive mail at the moment of the check? Know where that answer stops.

When to verify, and when to check again

• Right before the first send, not when you collect the list. Every week between the check and the send is a week for mailboxes to close.
• Unknown addresses, after a pause. Re-check after a few hours rather than a few seconds, because greylisting is built around a delay.
• Old lists, before reuse. A common rule of thumb is to re-verify any list that has sat unused for more than a month.
• After each send. Remove hard bounces at once; don't re-verify them and try again. A common rule of thumb is to keep hard bounces under 2%, and our guide to email bounce rates explains how to get there.

Verification protects your bounce rate, but it doesn't replace sender authentication. Google's email sender guidelines require SPF or DKIM from every sender, SPF, DKIM and DMARC from bulk senders, and a spam rate reported in Postmaster Tools below 0.3%. Cold email deliverability: the rules that protect your domain covers the rest of the setup.

A verification checklist

1. Trim spaces, strip mailto: and trailing punctuation, and lowercase the domain.
2. Remove placeholders, image names and obvious typos.
3. Remove duplicates.
4. Look up MX records once per domain, and drop domains that can't receive mail.
5. Check each mailbox, with a made-up address first to detect catch-all domains.
6. Re-check unknown addresses after a pause.
7. Send only to valid addresses, and keep catch-all ones for a separate, smaller test.
8. Send within days, remove hard bounces at once, and keep opt-outs suppressed for good.

Common mistakes

• Sending a "test" email to see if it bounces. That's the bounce you were trying to avoid, and to a stranger it's an unsolicited message anyway.
• Counting catch-all as valid. It's a domain that says yes to everything, not a confirmed mailbox.
• Verifying at collection time and sending months later. A verdict describes the mailbox on the day of the check, not on the day you send.
• Running checks from the server you send from. A block on that IP address blocks your real email too.
• Expecting verification to fix inbox placement. It removes bad addresses; authentication, volume and content decide where your mail lands.

FAQ

Does verifying an address notify its owner?

No. No message is delivered, so nothing reaches the inbox. The mail server may log the connection, as it logs every connection.

Can email verification be 100% accurate?

No. It's accurate when the server gives a clear answer about the address. It can't be when the server accepts everything, refuses to answer, or accepts first and bounces later. Good tools report those cases as catch-all or unknown instead of guessing.

What's the difference between email validation and verification?

The words are used loosely. "Validation" often means the format and domain checks; "verification" usually adds the mailbox check with the mail server.

Can I verify an address with a DNS lookup alone?

Only halfway. DNS tells you whether the domain can receive mail, not whether the mailbox exists.