# How Email Verification Works (Without Sending an Email)

URL: https://leadraft.co/blog/how-email-verification-works
Summary: How email verifiers check an address without sending mail: syntax, MX records, the SMTP RCPT TO test, catch-all detection, their limits, and when to re-verify.

[ All articles](https://leadraft.co/blog)

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

How email verifiers check an address without sending mail: syntax, MX records, the SMTP RCPT TO test, catch-all detection, their limits, and when to re-verify.

The Leadraft teamLeadraft

Published

October 31, 2026

Updated

November 3, 2026

Read time

12 min

Category

Deliverability

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?[#](#what-happens-when-you-verify-an-email-address)

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

Scroll horizontally if needed →

| Step | What it checks | What a fail means |
| --- | --- | --- |
| 1\. Syntax | Is this a well-formed address? | Invalid. Stop. |
| 2\. Domain and MX | Does the domain exist and publish mail servers? | Invalid (no way to deliver). |
| 3\. Disposable and role checks | Is it a throwaway domain? Is it `info@`, `sales@`? | Flag, not usually a fail. |
| 4\. SMTP mailbox test | Does the server accept `RCPT TO` for this address? | Invalid if the server rejects it permanently. |
| 5\. Catch-all test | Does the server also accept an address that can't exist? | Catch-all: the step 4 yes proves nothing. |

A verifier does the first half of a delivery and stops before anything is sent. Accept-all (catch-all) servers say yes to every address, so they get their own grade: a maybe, never a yes.

The rest of this post goes through them in order.

## Email validation vs verification: what's the difference?[#](#email-validation-vs-verification-whats-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.

Scroll horizontally if needed →

|  | Email validation | Email verification |
| --- | --- | --- |
| What it checks | Format, domain, MX records, disposable or role flags | All of that, plus an SMTP conversation with the mail server |
| Steps in the table above | 1 to 3 | 1 to 5 |
| Talks to the mail server? | No (DNS only) | Yes, stopping before any message is sent |
| Catches | Typos, fake domains, domains that take no mail | Also mailboxes that don't exist, and catch-all domains |
| Typical use | A signup form checking input as you type | Cleaning a list before a cold email campaign |

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?[#](#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?[#](#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](https://leadraft.co/tools/email-domain-checker) shows a domain's MX setup.

## Step 3: disposable and role-based addresses[#](#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?[#](#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:

```text
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:

```text
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:

Scroll horizontally if needed →

| Reply | Meaning | What a verifier should do |
| --- | --- | --- |
| `250` | Accepted | Looks valid (go to the catch-all test) |
| `550`, `551`, `553` | Permanent failure, typically "no such user" | Invalid |
| `450`, `451`, `452` | Temporary failure: try later | Retry later. Never mark invalid |
| Timeout or connection refused | No usable answer | Unknown. Retry later |

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?[#](#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**.

On a normal server, real and made-up addresses get different answers. A catch-all server says 250 OK to both, which is why those addresses get an Accept-all grade instead of Verified.

Whether to send to those addresses, and how, is covered in [catch-all emails explained](https://leadraft.co/blog/catch-all-emails-explained).

## What do email verification results mean?[#](#what-do-email-verification-results-mean)

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

Scroll horizontally if needed →

| Common labels | What happened | Send? |
| --- | --- | --- |
| Valid, Verified, Deliverable | Server accepted this mailbox and rejected a made-up one | Yes |
| Catch-all, Accept-all, Risky | Server accepts every address | Only as a separate, smaller segment |
| Invalid, Undeliverable | Server rejected the mailbox, or the domain takes no mail | Never |
| Unknown, Timeout | No usable answer | Not yet. Re-check later |
| Disposable, Role (flags) | Deliverable, but a special type | Depends on your use |

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?[#](#what-cant-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[#](#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](https://leadraft.co/blog/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?[#](#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[#](#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](https://leadraft.co/product/emails) and [pricing](https://leadraft.co/pricing) if you want that in one place.

## FAQ[#](#faq)

### How does email verification work without sending an email?[#](#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?[#](#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?[#](#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](https://leadraft.co/blog/catch-all-emails-explained) covers when they're worth sending to.

### Why do some verifiers return unknown?[#](#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?[#](#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?[#](#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?[#](#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[#](#sources)

1.  IETF, [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321) (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](https://www.rfc-editor.org/rfc/rfc3463) (`5.1.1` bad destination mailbox).
3.  IETF, [RFC 7505: A "Null MX" No Service Resource Record](https://www.rfc-editor.org/rfc/rfc7505).
4.  IETF, [RFC 6647: Email Greylisting](https://www.rfc-editor.org/rfc/rfc6647).
5.  Microsoft, [Outlook.com Postmaster: Policies, Practices, and Guidelines](https://substrate.office.com/ip-domain-management-snds/postmaster/Policies) (namespace mining; bounce handling).
6.  US Bureau of Labor Statistics, [Employee Tenure in 2026](https://www.bls.gov/news.release/archives/tenure_09242026.htm) (released September 24, 2026).
7.  US Bureau of Labor Statistics, [34.7 percent of business establishments born in 2013 were still operating in 2023](https://www.bls.gov/opub/ted/2024/34-7-percent-of-business-establishments-born-in-2013-were-still-operating-in-2023.htm).
8.  Google for Developers, [Place IDs](https://developers.google.com/maps/documentation/places/web-service/place-id) (refresh IDs older than 12 months).
9.  Leadraft, [Verification methodology](https://leadraft.co/methodology/verification).

## Keep reading

-   [
    
    November 3, 2026Deliverability
    
    ### Domain check vs mailbox check: what email verification actually proves
    
    An MX (domain) check proves a domain takes mail. An SMTP (mailbox) check asks about the address. What each proves, why some verifiers skip SMTP, how to tell.
    
    Read article
    
    ](https://leadraft.co/blog/domain-check-vs-mailbox-check)
-   [
    
    November 3, 2026Deliverability
    
    ### How to check if an email domain is catch-all
    
    To check if an email is catch-all, ask the mail server about an address that can't exist. How the test works, why a verifier should run it, and which tools do.
    
    Read article
    
    ](https://leadraft.co/blog/how-to-check-if-email-is-catch-all)
-   [
    
    October 31, 2026Deliverability
    
    ### What's a good cold email bounce rate? (And how to get yours under it)
    
    Aim for a cold email bounce rate under 2%. What Gmail, Yahoo, Outlook and sending tools actually publish, what causes bounces, and how to fix a high rate.
    
    Read article
    
    ](https://leadraft.co/blog/cold-email-bounce-rate)

Last built: 2026-11-09