How email verification works: syntax, MX, SMTP and catch-all, explained

Email verification checks whether an address can receive mail without sending a message to it. A verifier checks the address's syntax, looks up the domain's mail servers (MX records), then opens an SMTP conversation with one of them and asks whether it would accept mail for that mailbox. It reads the reply code and hangs up before any message is sent. The answer is usually one of three grades: valid, invalid, or catch-all (the server accepts every address, so the check proves nothing).

This post walks through each step, with the RFC 5321 details that decide the result, and then covers what a verifier can't know, how to read the grades, and how often to check again.

What happens when you verify an email address?#

A verifier runs a short pipeline. Each step can end the check early.

The rest of this post goes through them in order.

Email validation vs verification: what's the difference?#

Validation checks that an address could work; verification checks that the mailbox does exist. The words get used loosely, and some vendors use them the other way round, so read what a tool actually does.

For a cold list, validation alone isn't enough: a well-formed jane@smithplumbing.com on a domain with working MX can still be a mailbox that closed last year. Only the SMTP step finds that.

Step 1: how is email syntax checked?#

A syntax check confirms the address has a local part, one @, and a domain, with characters and lengths the standards allow. RFC 5321 limits the local part (before the @) to 64 octets and a domain name to 255 octets.

In practice, verifiers also normalize what they're given before checking anything else:

• Trim spaces, stray punctuation and mailto: prefixes picked up from web pages.
• Lowercase the domain. Domains are case-insensitive. RFC 5321 says the local part may be case-sensitive, but almost no real mail server treats it that way.
• Reject obvious junk that scrapers pick up: name@domain.com placeholders, image file names like logo@2x.png, and tracking addresses.

Syntax is cheap and catches a surprising amount when addresses are copied from websites. It tells you nothing about whether the mailbox exists.

Step 2: what is an MX lookup?#

An MX lookup asks DNS which servers accept mail for a domain. The verifier queries the domain's MX records, each with a priority, and will talk to the lowest-numbered (most preferred) server first.

Three outcomes matter:

1. MX records exist. Continue to the mailbox test.
2. No MX records, but the domain has an address (A or AAAA) record. RFC 5321 section 5.1 says the domain itself is then treated as the mail server (the "implicit MX" rule). Some verifiers skip this case and wrongly mark the address invalid.
3. A "null MX" record (MX 0 ., defined in RFC 7505) or no domain at all. The domain explicitly accepts no mail. The address is invalid.

The MX records also tell you who hosts the mail. Records ending in google.com mean Google Workspace; mail.protection.outlook.com means Microsoft 365. That matters later, because large hosted providers answer mailbox checks differently from a small business's own server.

If you want to see this for any domain, our email domain checker shows a domain's MX setup.

Step 3: disposable and role-based addresses#

Before the slow part, most verifiers flag two kinds of address that are deliverable but often unwanted:

• Disposable domains: throwaway inbox services. Checked against a list of known providers, which needs regular updates because new ones appear constantly.
• Role-based addresses: info@, office@, sales@. These reach a shared inbox, not a named person.

For local businesses, a role address is often the right address. A plumbing company with four staff usually reads office@ every day. Flag role addresses so you can segment them; don't throw them away.

Step 4: how does the SMTP check work?#

The mailbox test is the first half of a real delivery, stopped before the message. RFC 5321 defines the conversation. A verifier's version looks like this:

S: 220 mx.smithplumbing.com ESMTP ready
C: EHLO verifier.example.net
S: 250 mx.smithplumbing.com
C: MAIL FROM:<check@verifier.example.net>
S: 250 OK
C: RCPT TO:<office@smithplumbing.com>
S: 250 OK                      <- the server will accept mail for this mailbox
C: QUIT                        <- hang up before DATA: no message is sent
S: 221 Bye

And this is what a mailbox that doesn't exist looks like, with the enhanced status code explained below:

C: RCPT TO:<jane@smithplumbing.com>
S: 550 5.1.1 <jane@smithplumbing.com>: Recipient address rejected: User unknown
C: QUIT
S: 221 Bye

The reply to RCPT TO is the result. RFC 5321 groups replies by their first digit:

Many servers add an enhanced status code (RFC 3463) after the reply, such as 550 5.1.1, where 5.1.1 means "bad destination mailbox address." That's the clearest invalid signal you'll get.

Two details trip up careless verifiers:

• The VRFY command doesn't help. SMTP has a command that asks "does this user exist?", but RFC 5321 lets servers decline to answer it, and most do. Verifiers use RCPT TO instead.
• Temporary failures are common. Greylisting (RFC 6647) deliberately answers unknown senders with a 4xx code the first time and accepts them on a retry. A verifier that treats a 4xx as invalid will throw away good addresses.

A careful verifier also paces itself: few connections per mail server, pauses between checks, and retries spread over time. Hammering a small business's mail server gets the verifier blocked, which produces more unknowns.

Step 5: what is the catch-all test?#

The catch-all test asks the same server about an address that can't exist, such as a long random string at the same domain. If the server accepts that too, it accepts every address, so its 250 for the real address carries no information. A catch-all result is a maybe, never a yes.

Whether to send to those addresses, and how, is covered in catch-all emails explained.

What do email verification results mean?#

Verifiers use different labels, but they map onto the same few outcomes:

The most common mistake is reporting catch-all as valid. A verifier that does this makes its "valid" rate look high and your bounce rate pay for it. The second most common is reporting a failed check as invalid, which quietly deletes working addresses.

What can't email verification tell you?#

A verifier sees one SMTP reply at one moment. It can't see:

• Whether a person reads the inbox. A mailbox can exist and be abandoned.
• What happens after the server says yes. Some servers accept during the conversation and bounce later, after their own checks. Those late bounces count against you like any other.
• Whether you'll reach the inbox. Spam filtering happens after delivery and depends on your domain's reputation, authentication and content, not on the address.
• Whether the address is who you think. jane@ might be Jane the owner, or a former employee whose mail now goes to someone else.
• Anything certain at catch-all domains. No test, free or paid, can confirm a single mailbox on a server that accepts everything.
• Reliable answers from some large providers. Big hosted and consumer mail services often answer every check the same way or limit checks from unknown senders. Microsoft's Outlook.com sender policy goes further and prohibits "namespace mining," which it describes as verifying addresses without sending to them. Expect more unknowns and catch-alls on these domains, and don't trust a verifier that claims certainty there.

This is why a good verifier is honest about what it doesn't know. The grade is a measurement, not a promise.

A worked example: what verification does to a list#

Here's an illustrative run on a list of local business addresses. The numbers are invented to show the arithmetic, not a measurement from any tool.

You start with 1,000 addresses collected from business websites:

1. Syntax and clean-up removes 20 junk strings (placeholders, image names). 980 left.
2. MX lookup removes 30 whose domains no longer take mail (closed businesses, expired domains). 950 left.
3. SMTP test: 60 rejected as no such user, 40 unknown after retries. 850 accepted.
4. Catch-all test: 200 of the 850 are on accept-all domains. 650 verified.

So you have 650 verified, 200 accept-all, 40 to re-check, and 110 to drop. If you'd sent to all 1,000, the 110 dead addresses alone are an 11% bounce rate before counting any catch-all bounces. That's far above the thresholds most sending tools act on (see what's a good cold email bounce rate). Sending the 650 first, then the 200 in small separate batches, keeps one bad segment from damaging the rest.

How often should you re-verify an email list?#

Re-verify any address you haven't checked in the last 30 days before you send to it, and re-check the whole list before a large campaign. That's our rule of thumb rather than a measured threshold, but the reasons it goes stale are well documented:

• People change jobs. The US Bureau of Labor Statistics reported median tenure with a current employer of 4.1 years in January 2026, and 3.0 years for workers aged 25 to 34. Every departure can close a named mailbox.
• Businesses close. Of private-sector establishments born in March 2013, BLS found the survival rate fell 20.4 percentage points in the first year, and only 34.7% were still operating ten years later. When a business closes, its domain and mailboxes eventually go with it.
• Listings change too. Google recommends refreshing stored Place IDs that are more than 12 months old, because places close, move and get new IDs.

For local business lists, closures and domain changes matter more than job changes, because the address you want is often the shared office@ inbox rather than a person's. A list built from Google Maps a year ago will contain businesses that have since closed, and their domains will start bouncing.

Practical rhythm:

• Verify at collection.
• Re-verify before each send if the last check is more than 30 days old.
• Remove every hard bounce immediately and add it to your suppression list.
• Rebuild the list from source, not just re-verify, when it's more than a year old, so new businesses get in and closed ones drop out.

How to choose an email verifier#

Ask any verifier, including us, these questions:

1. Does it separate catch-all from valid? If it can't tell you which domains accept everything, its valid rate is meaningless.
2. What does it do with timeouts and 4xx replies? The right answer is "retry later," not "invalid."
3. Does it send email to check? It shouldn't need to.
4. Does it tell you when an address was checked? A grade without a date can't tell you whether it's stale.
5. Does it charge for unknowns? Some charge for every check, some only for conclusive ones. Read the pricing.

If you're building lists of local businesses, verification works best when it's part of finding the email, not a separate step afterwards. That way every address carries its source page, grade and check date together. See how Leadraft finds and checks emails and pricing if you want that in one place.

FAQ#

How does email verification work without sending an email?#

A verifier checks the address format, looks up the domain's MX records, then connects to the mail server and starts an SMTP conversation. It names the recipient with RCPT TO, reads the reply code (250 accepted, 550 rejected), and hangs up before the DATA command, so no message is ever delivered.

Is a verified email guaranteed not to bounce?#

No. Verified means the mail server accepted that mailbox at the moment of the check. The mailbox can be closed later, the server can bounce mail after accepting it, and filtering can still block a message. Verification lowers bounce risk; it doesn't remove it.

What does catch-all or accept-all mean in an email verifier?#

The domain's server accepts mail for any address, including one that can't exist. Because it says yes to everything, its yes about your address proves nothing. Treat catch-all results as unconfirmed, not as valid. Our catch-all guide covers when they're worth sending to.

Why do some verifiers return unknown?#

The server didn't give a usable answer: it timed out, greylisted the check with a temporary 4xx code, rate-limited the verifier, or blocked it. An unknown is a failed check, not a bad address, and should be retried later rather than marked invalid.

How often should I re-verify an email list?#

Re-verify any address you haven't checked in the last 30 days before a send, and re-check a whole list before any large campaign. People change jobs and businesses close every month, so a list verified once slowly goes stale. The 30-day figure is a rule of thumb, not a measured threshold.

Can email verification tell me if someone will read my email?#

No. Verification can only tell you whether a mail server accepts an address. It can't tell you whether a person reads that inbox, whether your message will land in spam, or whether the address belongs to the person you think it does.

What is the difference between email validation and email verification?#

Validation checks that an address could work: correct format, a real domain and mail servers in its MX records. Verification adds an SMTP conversation with the mail server to check that the mailbox itself exists, stopping before any message is sent. For a cold list you need verification; validation alone misses closed mailboxes.

Sources#

1. IETF, RFC 5321: Simple Mail Transfer Protocol (the SMTP conversation, reply codes, VRFY, MX and implicit MX in section 5.1, address length limits in section 4.5.3.1).
2. IETF, RFC 3463: Enhanced Mail System Status Codes (5.1.1 bad destination mailbox).
3. IETF, RFC 7505: A "Null MX" No Service Resource Record.
4. IETF, RFC 6647: Email Greylisting.
5. Microsoft, Outlook.com Postmaster: Policies, Practices, and Guidelines (namespace mining; bounce handling).
6. US Bureau of Labor Statistics, Employee Tenure in 2026 (released September 24, 2026).
7. US Bureau of Labor Statistics, 34.7 percent of business establishments born in 2013 were still operating in 2023.
8. Google for Developers, Place IDs (refresh IDs older than 12 months).
9. Leadraft, Verification methodology.