How Email Verification Works, Step by Step

Every email verifier on the market says roughly the same thing on its homepage. The useful question is what happens between you pasting jane.doe@acme-logistics.com into a box and a word like “deliverable” appearing next to it, because that is where results get accurate or quietly wrong.

This guide follows one address through the full pipeline. At each stage you will see what is being asked, what the answer looks like on the wire, and how that stage can be fooled. The examples use RocketVerifier’s result codes, but the mechanics are the same for any serious verifier.

The pipeline at a glance

Verification is a series of increasingly expensive questions. The cheap ones run first, so an obviously broken address never costs a network round trip. Each stage can end the check early with a result.

1. 1

   Syntax

   Is this a well-formed address? Is the domain a known typo?

   Can stop here as undeliverable/ invalid_syntax risky/ possible_typo
2. 2

   Disposable

   Is the domain a throwaway inbox service?

   Can stop here as undeliverable/ disposable
3. 3

   DNS and MX network

   Does the domain exist, and does it publish a mail server?

   Can stop here as undeliverable/ invalid_domain undeliverable/ does_not_accept_mail unknown/ dns_error
4. 4

   SMTP mailbox check network

   Will the mail server accept RCPT TO for this exact mailbox?

   Can stop here as undeliverable/ mailbox_not_found risky/ mailbox_full unknown/ greylisted unknown/ blocked
5. 5

   Catch-all probe network

   Would the server also accept a random address that cannot exist?

   Can stop here as risky/ catch_all
6. 6

   Risk signals

   Role account, trap pattern, abusive address, or on your suppression list?

   Can stop here as risky/ role_based risky/ possible_trap risky/ do_not_mail
7. ✓

   Passed every stage

   Returned as deliverable/ none or, for a plus-addressed mailbox, deliverable/ alias

Two things to notice. First, only stage 4 talks to the mailbox. Stages 1 to 3 judge the domain, and stages 5 and 6 judge how much to trust a yes. Second, there are three ways to be uncertain (dns_error, greylisted, blocked) and they all lead to unknown. That is deliberate, and we will come back to it.

Stage 1: Syntax, and the typos people actually make

The formal grammar for an address lives in RFC 5322, and it is far more permissive than most people expect. Quoted local parts like "john smith"@example.com are technically valid. So are many characters that no real mailbox uses.

A practical verifier does not enforce the full RFC. It enforces what real mail systems accept: one @, a local part of at most 64 characters, a domain made of valid labels, no leading or trailing dots, no consecutive dots. Anything outside that comes back as undeliverable/ invalid_syntax .

The more valuable part of this stage is typo detection, because a syntactically perfect address can still be wrong:

Typed	Probably meant	Why it matters
maria@gmial.com	maria@gmail.com	gmial.com is a known typo domain. Some typo domains are run as spam traps.
sam@hotmial.com	sam@hotmail.com	Same pattern, different provider.
lee@company.con	lee@company.com	.con is not a real top-level domain.
ana@yahooo.com	ana@yahoo.com	Caught by edit distance, not a fixed list.

RocketVerifier checks against a curated list of misspelled provider domains, a list of bad endings like .con, and an edit-distance comparison against common providers. When it finds a likely fix it returns it in did_you_mean. On a signup form, that one field recovers real customers who would otherwise never get their confirmation email. More on that in our guide to real-time verification on signup forms.

Stage 2: Disposable domains

Disposable services such as Mailinator and Yopmail hand out inboxes that work for minutes or hours. The address is real and will accept mail, which is exactly the problem: it passes every technical check and then disappears.

There is no protocol signal for “disposable”. Detection is a lookup against lists of known services. We combine two public, community-maintained blocklists with our own overrides, because the lists are imperfect in both directions: new throwaway domains appear daily, and occasionally a legitimate small provider gets listed by mistake.

A match returns undeliverable/ disposable . You can test any domain for free with the disposable email checker, and the glossary entry covers why these addresses hurt more than they first appear to.

Stage 3: DNS and MX records

Now the first network request. The verifier asks DNS for the domain’s MX records, which list the servers that accept its mail and their priority:

$ dig +short MX acme-logistics.com
10 mx1.acme-logistics.com.
20 mx2.acme-logistics.com.

Four outcomes matter here:

• The domain does not exist (NXDOMAIN). Nobody can receive mail there. Result: undeliverable/ invalid_domain
• The domain publishes a null MX, a single record of 0 . defined in RFC 7505. That is an explicit statement that the domain accepts no mail. Result: undeliverable/ does_not_accept_mail
• No MX records at all. SMTP technically allows falling back to the domain’s A record, but in practice a domain with no MX almost never runs a mail server. This is also does_not_accept_mail.
• DNS fails to answer (timeout or SERVFAIL). This says nothing about the address, only that the lookup failed. Result: unknown/ dns_error , retried later.

The MX hostnames also reveal who hosts the mail. aspmx.l.google.com means Google Workspace, *.mail.protection.outlook.com means Microsoft 365, and so on. That matters in stage 4, because each provider phrases its SMTP replies differently. You can run this lookup yourself with the free MX lookup tool.

Stage 4: The SMTP mailbox check

This is the only stage that asks about the specific mailbox. The verifier connects to the highest-priority MX on port 25 and starts an ordinary delivery conversation, the same one any mail server uses, as defined in RFC 5321. Here is what a clean “yes” looks like:

The reply to RCPT TO is the whole point. It has a three-digit code and, on most modern servers, an enhanced status code from RFC 3463 that narrows down the reason. The first digit is what decides the result:

Reply	What the server is saying	Result
250 2.1.5	I will accept mail for this mailbox	Continue to stage 5
550 5.1.1	No such user here	undeliverable/ mailbox_not_found
550 5.2.1	The mailbox exists but is disabled	undeliverable/ account_disabled
452 4.2.2 or 552 5.2.2	The mailbox is over quota	risky/ mailbox_full
450 or 451	Try again later	unknown/ greylisted
550 5.7.1 or 554 5.7.x	I do not accept mail from you	unknown/ blocked

Where verifiers get this wrong

The last two rows are where weak verifiers inflate their “invalid” counts.

A 4xx reply is temporary by definition. Many servers deliberately defer the first attempt from an unfamiliar sender, a technique called greylisting and described in RFC 6647. The mailbox might be perfectly fine. RocketVerifier marks it unknown and retries automatically, up to three times about ten minutes apart, which is long enough for most greylisting windows to pass.

A 5.7.x rejection is about the sender, not the recipient. It means the server dislikes the verifier’s IP, its reputation, or its identity. Reporting that as “mailbox does not exist” would be inventing an answer, so it becomes blocked, which is also unknown.

Why MX hosting alone is never treated as proof

Google Workspace and Microsoft 365 host a huge share of business mail, and both are cautious about answering RCPT TO honestly for unfamiliar senders. A shortcut some tools take is to assume any address on a Google or Microsoft hosted domain is fine. We do not. Only an explicit SMTP answer produces deliverable or undeliverable. If the provider blocks or defers the check, the result is unknown, and you are not charged for it.

Stage 5: The catch-all probe

A 250 OK sounds conclusive, but some servers say yes to everything. A catch-all domain (also called accept-all) accepts mail for any local part at the SMTP stage, then delivers it to a shared inbox, sorts it later, or bounces it after the fact.

The only way to know is to ask about addresses that cannot exist. After the real address is accepted, the verifier stays in the same session and tries random ones:

We send three random addresses and treat the domain as catch-all if two of the three are accepted. Using several probes avoids two failure modes: one lucky accept from a flaky server, and one rate-limited reject from a real catch-all.

On a catch-all domain the original 250 no longer tells you much, so the result becomes risky/ catch_all with a catch_all_verdict of send_safe, send_with_caution or avoid. That verdict comes from a score built on the hosting provider, how plausible the local part looks, and whether it matches the naming pattern the domain uses, such as first.last. The full method and how to act on each verdict are in Catch-all emails: should you send to them?.

One edge case worth knowing: if the real address was accepted but the catch-all probe itself gets blocked or times out, we cannot rule out an accept-all domain. That result is unknown, not deliverable.

Stage 6: Risk signals

An address can exist, accept mail and still be a poor idea to send to. The last stage flags those:

• Role accounts such as info@, support@, sales@ or billing@ reach a team or a ticket queue rather than a person. They are real, but they complain more and convert less in marketing sends. Result: risky/ role_based . See role-based addresses.
• Known trap patterns. We flag addresses on known typo-trap domains and local parts like spamtrap@ or honeypot@. To be clear about the limits: nobody can reliably detect pristine or recycled spam traps from the outside, because they are designed to look like normal mailboxes. Treat any vendor who claims otherwise with suspicion. Result: risky/ possible_trap
• Toxic addresses: abusive words, placeholders like test@test.com, keyboard mashes like asdfgh@. These can only lower a result, never raise it. Result: risky/ toxic
• Your own suppression list and known complainers. If someone unsubscribed or marked you as spam, verification should say so before you mail them again. Result: risky/ do_not_mail

An address that clears all six stages is deliverable/ none . If the local part contains a plus tag, such as jane+newsletter@, it is deliverable/ alias , which tells you two records might belong to one person.

What “unknown” really means

Unknown is the result people like least and should respect most. It means the verifier asked and did not get a trustworthy answer: DNS failed, the server deferred, the server blocked the check, or the connection timed out.

A verifier that never returns unknown is guessing on your behalf. The guesses usually go one of two ways, and both cost you. Guess “invalid” and you delete real customers. Guess “valid” and you send to addresses that bounce.

The practical way to handle unknowns:

How accurate can verification be?

RocketVerifier verifies with 99.5% accuracy, and that number comes from the decisions described above rather than from any single check. Only an explicit SMTP answer produces a deliverable or undeliverable result. Deferrals, policy blocks and timeouts are returned as unknown instead of being guessed, and you are never charged for them. Catch-alls get a scored verdict instead of a shrug.

Some things sit outside what any check can see. A server can accept at RCPT TO and bounce later, and a mailbox can be deleted the day after you verify it. That is why we put credits behind our results: connect SendGrid, Mailgun, Amazon SES or Postmark, and every hard bounce on an address we marked deliverable is refunded automatically. The bounce guarantee has the details.

When you compare vendors, ask each one how it treats 4xx replies, how it detects catch-alls, whether it marks Google and Microsoft addresses deliverable without a real SMTP answer, and whether it charges for unknowns. Our guide to testing a verification service turns those questions into a test you can run on your own data.

The infrastructure behind stage 4

You can reproduce stages 1 to 3 with a regex, a disposable list and dig. Stage 4 is where home-grown scripts and weaker verifiers fall down. Most cloud providers block outbound port 25, receiving servers rate-limit and blocklist IPs that probe carelessly, and reading replies correctly means knowing how each provider phrases them.

This is the part we built the platform around:

• Dedicated verification IPs. Every probing IP self-tests before it carries traffic: port 25 open, forward-confirmed reverse DNS, and a HELO name that matches. Probes come from a dedicated verification domain, never yours.
• Automatic IP warm-up. New IPs ramp through seven stages over about three weeks, move up only while blocklist checks stay clean, and step back automatically if one is listed.
• Per-provider rate budgets. Each IP has its own budget for Gmail, Outlook, Yahoo and every other receiver, with automatic back-off after a deferral, so providers keep answering instead of blocking.
• Provider-specific reply parsing. Google, Microsoft, Yahoo, Mimecast, Proofpoint and Barracuda each get their own rules, so a policy block is never mistaken for a missing mailbox.
• Greylisting handled for you. Deferred addresses are retried automatically, and a stalled bulk job moves to another verification node.

For a quick check of one address, the free email verifier runs the syntax, MX and disposable checks with no signup. For lists, or anything that needs the full mailbox check, use the dashboard or the API, which typically answers in under 400ms, or 1 to 3 seconds when a live SMTP check is needed.