How Email Verification Actually Works: Syntax, MX, SMTP & Catch-All

The verification pipeline at a glance

Email verification is not a single check but a pipeline of increasingly expensive tests, each of which can rule an address in or out. A good verifier runs the cheap, deterministic checks first and only reaches the network-dependent ones when necessary. Understanding each stage demystifies what a verdict of deliverable, undeliverable, risky, or catch-all actually means.

The stages, in order, are: syntax validation, domain and MX lookup, the SMTP mailbox probe, and a set of classification checks for disposable, role, and catch-all characteristics. Let us walk through each one.

Stage 1: Syntax validation

The first and cheapest check is whether the address is even well-formed. This means confirming it has a local part, an @ symbol, and a domain part, and that all characters conform to the rules laid out in the relevant RFCs. It catches obvious garbage — missing @, illegal characters, double dots, empty local parts — instantly and for free, without touching the network.

Syntax validation also commonly folds in a typo-detection layer that flags likely misspellings of popular domains (gmial.com for gmail.com) so they can be corrected rather than mailed. Passing syntax proves only that the address could exist, not that it does — which is why the pipeline continues.

Stage 2: Domain and MX record lookup

Next, the verifier performs a DNS query for the domain’s MX (mail exchanger) records. MX records tell the internet which servers are responsible for receiving mail for that domain. If a domain has no MX records (and no fallback A record configured to receive mail), it cannot accept email at all, and every address at that domain is undeliverable regardless of the local part.

This stage catches dead domains, parked domains, and domains that were never set up to receive mail. It is still relatively cheap — a DNS lookup — and it eliminates a meaningful fraction of bad addresses before the expensive network conversation begins.

Stage 3: The SMTP mailbox probe

This is the heart of verification. The verifier opens an SMTP connection to the domain’s mail server and begins the conversation a real sending server would, up to the point of specifying the recipient — but it stops short of actually delivering a message. In simplified form, it issues the handshake, declares a sender, and then issues an RCPT TO command naming the address being checked.

How the server responds to RCPT TO is the signal. A 250 response means the server will accept mail for that mailbox; a 550 (or similar 5xx) means it rejects the recipient as unknown. From this the verifier infers whether the mailbox exists — without ever sending an actual email.

// Simplified illustration of the SMTP recipient check
> HELO verifier.example
< 250 mail.company.com
> MAIL FROM:<probe@verifier.example>
< 250 OK
> RCPT TO:<real.person@company.com>
< 250 OK           // mailbox exists -> deliverable
> RCPT TO:<nobody@company.com>
< 550 No such user  // mailbox does not exist -> undeliverable

Stage 4: Catch-all detection

The SMTP probe has a well-known blind spot: catch-all servers. A catch-all domain accepts mail for every address, so it returns 250 for real and fake mailboxes alike. To detect this, the verifier probes a deliberately random, almost-certainly-nonexistent address at the domain. If that fake address is accepted, the domain is catch-all and no per-mailbox verdict is possible.

When a domain tests positive for catch-all, an honest verifier reports the address as catch-all or risky rather than pretending to know whether the specific mailbox exists. This is the correct behavior — anything else is a guess dressed up as a fact. Our dedicated guide to catch-all email explains how to handle these results.

Stage 5: Disposable, role, and reputation classification

Alongside deliverability, a good verifier classifies the address on several other axes that inform whether you should send, even when the mailbox is technically valid.

• Disposable detection: flags addresses on temporary or throwaway providers, which are almost never worth mailing and often signal fraud or low intent.
• Role detection: flags generic mailboxes like info@, support@, and sales@ that are read by teams or automated systems rather than an individual.
• Free-provider flags: notes consumer domains (gmail.com, outlook.com) so B2B senders can weight them appropriately.
• Deliverability verdict: rolls the pipeline results into a single label — deliverable, undeliverable, risky, or catch-all — so you can act on it directly.

Reading a verification result

Putting the pipeline together, a single verification call returns a structured verdict you can filter on. Deliverable addresses are safe to send. Undeliverable addresses should be dropped. Risky and catch-all addresses need a per-campaign decision. Disposable and role flags let you strip low-value or non-individual addresses when your campaign calls for it.

That is the entire model behind a clean list: run each address through the pipeline, keep the deliverable ones, and make deliberate choices about the ambiguous ones. A single API call runs all of it:

curl -X GET "https://verifly.email/api/v1/verify?email=prospect@example.com" \
  -H "Authorization: Bearer vf_your_api_key"