Email Verification Guide: How It Works, Stage by Stage

Every verification tool you’ve ever used runs the same four gates in the same order: check the address is well-formed, check the domain can receive mail, ask the mail server whether the mailbox exists, then classify what’s left as catch-all, disposable, role, or free. This email verification guide walks each gate with the actual rules and reply codes behind it, then covers the two things most guides skip: how to read the result without fooling yourself, and how the billing model changes what a clean list really costs. If you run outbound, the second half is where your money goes.

What is email verification, and what does it actually check?

Email verification is a chain of increasingly expensive checks that establishes, without sending anything, whether a message to an address would be delivered. Each stage filters out addresses the next stage would waste a connection on. A verifier that skips a stage either misses bad addresses or burns SMTP connections on domains that were never going to work. The pipeline, cheapest first:

Notice the right-hand column. No stage answers “will this person reply.” Verification tells you whether the address is real and what kind it is. Everything after that is reputation and content, which is the deliverability page’s territory, not this one’s.

Stage 1: What does a syntax check catch, and what does it miss?

A syntax check confirms an address is structurally legal under the email RFCs: a local part, an @, and a domain, within length limits and using permitted characters. It costs nothing because it never touches the network, and it proves nothing about existence, which is why “validated” and “verified” aren’t the same word.

The rules come from two documents. RFC 5322 defines the format: a locally interpreted string, the at sign, then a domain. RFC 5321 sets the limits: a local part is at most 64 octets and a domain name at most 255. Two details trip up home-grown validators:

• The local part is case sensitive on paper. RFC 5321 section 2.4 says it “MUST BE treated as case sensitive,” while the domain follows DNS rules and isn’t. Most providers fold case in practice, but a verifier shouldn’t normalize what the standard says to preserve.
• Quoted local parts and plus signs are legal. "john smith"@example.com is valid, and so is Gmail-style +tag subaddressing. A regex that rejects either is throwing away real people.

That’s the argument against regex as your only gate: the grammar is long enough that most regexes are too strict or too loose, and you find out from the bounces. Catch typos and garbage here, then move on; the email syntax checker runs a proper parser in the browser. And remember what syntax can’t do: idonotexist@gmail.com passes every rule in both RFCs. Shape is not existence.

Stage 2: How do domain and MX checks work?

The domain stage asks whether anything at all can receive mail for the domain. A DNS query pulls the domain’s MX records, the ranked list of mail servers that accept its inbound mail. No usable MX means no mailbox to check, and the address fails here before you spend a connection on it.

Three things about this stage matter, because cheap tools get all three wrong.

No MX doesn’t always mean no mail. RFC 5321 section 5.1 says a domain with no MX records is treated “as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host,” meaning its A or AAAA record. Plenty of small domains receive mail this way. A verifier that fails every domain without an MX is marking real addresses invalid.

A null MX means “we don’t take mail,” on purpose. RFC 7505 formalizes a single MX record pointing at ”.” as a domain’s declaration that it accepts no email. That’s a hard invalid, and it saves everyone a wasted SMTP attempt.

The MX record tells you who you’re about to talk to. The hostname usually reveals the provider (Google Workspace, Microsoft 365) or a security gateway like Proofpoint or Mimecast in front of the real server. Gateways answer on the mailbox’s behalf and tend to accept everything at the envelope, so reading the MX first tells a good verifier how much to trust the stage 3 reply. Check any domain with the MX lookup tool, or dig example.com MX at a terminal.

Stage 3: What happens during the SMTP RCPT TO probe?

The SMTP probe is where verification earns its name. The verifier connects to the domain’s mail server, runs the conversation up to RCPT TO:<address>, reads the reply, and sends QUIT before ever issuing DATA. The server has already said whether it would accept mail for that mailbox, and nothing was delivered.

This works because RFC 5321 section 3.3 fixes the transaction order: MAIL FROM, one or more RCPT TO, then DATA. The recipient is accepted or rejected before the message exists. The reply code is the whole signal. From the RFC 5321 reply code table:

• 250 requested action okay. On a normal mailbox, the address is real.
• 550 mailbox unavailable, typically “no such user.” Clean invalid.
• 551 and 553 user not local or mailbox name not allowed. Invalid.
• 450 and 451 temporary failure. Usually greylisting; retry, don’t mark invalid.
• 421 service not available. Back off and try later.
• 252 cannot verify user, but will attempt delivery. The polite non-answer.

Two things to hold onto. VRFY, the command built for exactly this job, is useless in practice: RFC 5321 section 7.3 lets sites disable it for security, and nearly all have, because it handed spammers a directory. And greylisting isn’t a verdict. RFC 6647 describes it as “providing temporarily degraded service to unknown email clients,” and a legitimate sender is expected to retry. A tool that reads a first-try 450 as invalid is deleting live addresses.

I’m keeping this short on purpose. The full handshake transcript, why a one-machine telnet probe gets your IP throttled, and why port 25 is closed on your laptop are worth a post of their own. If you want to see the outcome of that handshake on a real address, run a free check and read the SMTP step in the result.

Stage 4: How are catch-all, disposable, role, and free addresses classified?

Classification runs on addresses that survived the first three gates and asks a different question: not “does it exist” but “what kind of address is it, and how much should I trust the answer I just got.” Four labels matter for outbound, each from a different mechanism.

Catch-all (accept-all). A domain that accepts mail for every address returns 250 to everything, so the stage 3 reply is worthless on its own. Verifiers detect it with a second RCPT TO for an address that can’t exist, something like random-xyz-9182@thecompany.com. If that’s accepted too, the original address gets filed as unconfirmed rather than valid. This is the status you’ll misread most, it’s common on B2B domains, and a surprising share of “catch-alls” are really security gateways in front of a normal mailbox. Prevalence numbers and the segment-don’t-delete workflow are in catch-all email verification.

Disposable. Temporary inboxes from throwaway providers, caught by a maintained domain list and, for domains not on any list yet, by the shared MX infrastructure many of them use. They’re a signup-form problem more than a list-cleaning one; the three ways to handle them are in how to block disposable email addresses.

Role-based. info@, sales@, support@, postmaster@. Many of these names are standardized in RFC 2142, which is why a verifier can flag them from the local part alone. They’re real, usually shared, and get ignored more than they bounce. Low value for one-to-one outbound, possibly exactly who you want if you sell support tooling. Flag, don’t auto-delete.

Free provider. Gmail, Yahoo, Outlook.com. Not a risk signal by itself, but a free-mail address on a B2B list is often personal, which changes the compliance picture and the odds anyone reads work mail there.

Classification is where a good tool separates “we got a 250” from “you can trust this.” Skip it and you get a valid count padded with catch-alls: the list that bounces after it was “cleaned.”

How should you read a verification result?

Read a result as a probability with a reason attached, not as a yes or no. Every serious tool returns a status plus a reason code, and the reason is the useful part. “Valid” is the most oversold word in any verification report, and “invalid” is the only one you can act on without thinking. Label names vary by vendor, but the buckets don’t:

Two habits keep this honest. Don’t let anyone quote you an accuracy number as if it were measured; vendor figures are self-reported, and the only number that describes your list comes from running a sample through two tools. And connect the result to the outcome. Google’s sender guidelines say to “Automatically unsubscribe recipients who have multiple bounced messages” and to cut volume “if messages start bouncing.” That’s the reputation loop verification protects. What a safe bounce rate looks like, and why the 0.3% everyone quotes is a spam-complaint line rather than a bounce limit, is in what’s an acceptable email bounce rate.

Want to see a real result with its reason first? Verify an email free with an address you know is dead next to one you know is live.

How do verification tools bill, and why does it change your real cost?

The billing model decides what a definitive answer costs you, and the sticker rate hides it. Most tools charge one credit per address submitted, whatever comes back. What separates vendors is what else lands on the bill: some charge again for every duplicate you left in the file, and some make you pay for their own outages. On a B2B list exported from three systems, the gap between the two is your real invoice.

Walk the math on a per-check tool. A chunk of your list comes back unknown because of greylisting and gateways, and you’ve paid for the tool’s failure to answer. You retry tomorrow. Billed again. Duplicates you didn’t catch were billed too. None of those credits produced a row you can act on, so your cost per usable result climbs above the rate on the pricing page.

Three questions to ask any vendor before you load a list:

1. Are unknowns charged? If the pricing page doesn’t say, assume yes and ask in writing.
2. Are duplicates charged? Some tools dedupe free, some bill every row.
3. Do credits expire? Resetting monthly plans can cost more than pay-as-you-go if you verify in bursts.

Our position is the one this post argues for. On VerifyEmail, one credit verifies one address, duplicates and failures on our side are never charged, and pay-as-you-go credits never expire. The terms are on the guarantee page and current rates on pricing. The tradeoff, said plainly: we’re not the lowest sticker rate in the category, and a couple of pure bulk verifiers post cheaper per-thousand numbers at volume. Run that arithmetic against every vendor you shortlist, ours included; the numbers for ours are on the pricing page.

Single check, bulk list, or API: which one do you need?

Pick by where bad addresses enter your system, not by list size. If they arrive through a form, verify at the point of capture. If you already have a list, clean it in bulk before you send. If you’re building the thing that collects addresses, use the API and never let a bad one in.

The tradeoffs. Bulk is the best effort-to-result ratio in outbound, and it’s also the one that makes your list smaller, which every founder hates for about a month. The API is the only way to stop bad addresses at the door, but it puts a network call in your signup path, so it has to return fast and fail gracefully. VerifyEmail’s runs at 10k/min; which vendor’s API fits your stack, ours or someone else’s, is the API docs’ job. All three surfaces draw from one credit wallet, so you don’t buy a second product to verify at signup after cleaning a list.

One thing we don’t do, so you don’t find out after switching: no prospecting or address lookup. Verification cleans a list you earned. It can’t launder one you bought, and Google is blunt about it: “Don’t purchase email addresses from other companies.”

Where I’d start

Run the whole list through bulk verification once, mail the valid segment, and work the catch-all segment separately in small batches. Then put real-time verification on whatever form feeds the list so you’re not repeating the cleanup every quarter. Three things to hold onto on the way: a 250 is a probability, not a promise; unknown is a retry, not a delete; and on any list with a B2B share, the billing model matters more than the sticker rate.

The tradeoff is the one every clean list carries: it gets smaller and your send velocity drops for a while. Do it anyway. A smaller list that lands beats a bigger one that teaches Gmail to distrust your domain, and that repair takes far longer than a verification pass.

Get Started Free includes 100 free credits, no credit card required.

Frequently asked questions

Does email verification send an email to the address?

No. A verifier opens an SMTP conversation with the domain’s mail server, issues RCPT TO for the address, reads the reply code, and disconnects before the DATA step. Nothing is transmitted and the mailbox owner never sees anything. That’s the whole trick, and it’s why verification is safe to run on a list before you mail it.

Why did a “valid” email still bounce?

Usually one of four things: the domain is catch-all or sits behind a security gateway that accepts every RCPT TO, the server rejected the message after accepting the envelope, the mailbox was closed between verification and send, or the tool called a greylisted 4xx reply “valid” by mistake. Treat valid as a strong probability, not a promise, and re-verify anything older than about 90 days.

What’s the difference between email validation and email verification?

In everyday use the words overlap, but the useful split is this: validation checks that an address is well-formed and its domain can receive mail (syntax and MX), while verification goes further and asks the mail server whether the specific mailbox exists. A validated address can be shaped perfectly and still not exist.

Should I delete unknown results from my list?

Not on the first pass. Unknown means the server didn’t give a usable answer, often because of greylisting or a timeout, not that the mailbox is dead. Re-run unknowns after a day or two and most resolve. Only cut the ones that stay unknown across retries, and check whether your tool charged you for them, because it shouldn’t.

How often should I re-verify my email list?

Before any send to a segment you haven’t mailed in about 90 days, and always before a large campaign to an older list. People change jobs, mailboxes get closed, and domains lapse, so a list that was clean in spring bounces by autumn. Real-time verification at the point of capture cuts down how much re-verification you need later.