How Email Verification Works Without Sending an Email

An email verifier can tell you that jane.doe@company.com does not exist without ever sending Jane an email. People find this surprising, and some assume the verifier must be sending something. It is not. It uses the fact that delivering an email is a conversation with several steps, and the receiving server reveals whether the mailbox exists before any message is handed over.

This post walks through that conversation, shows what each kind of answer looks like, and explains the cases where the method cannot give a clean answer.

Step 1: Is the address well formed?

Before touching the network, the verifier checks the syntax. There must be one @ sign, a local part that follows the rules for characters and length, and a domain with valid labels. This catches typos like a missing dot, a space, or two @ signs. It is also where obviously fake addresses are removed: test@test.com, addresses on reserved domains like example.com, and local parts that contain the domain itself.

Step 2: Does the domain receive mail?

The verifier looks up the domain's MX records in DNS. These name the servers that accept mail for the domain. No MX records usually means the domain is not set up for email, and every address on it is undeliverable. A domain that does not resolve at all is a typo or dead.

This step also classifies the domain: a free provider (Gmail, Outlook.com, Yahoo), a business domain on Google Workspace or Microsoft 365, a self-hosted server, or a disposable email service. You can see what a domain's MX records look like with the free MX lookup tool.

Step 3: The SMTP conversation

Now the verifier connects to the mail server on port 25 and begins exactly the exchange a sending server would. The key is that SMTP names the recipient before any message content is sent, and the server answers at that point.

Server:   220 mx.company.com ESMTP ready
Verifier: EHLO verify.example.net
Server:   250 mx.company.com Hello
Verifier: MAIL FROM:<check@example.net>
Server:   250 2.1.0 Sender OK
Verifier: RCPT TO:<jane.doe@company.com>
Server:   550 5.1.1 The email account that you tried to reach does not exist
Verifier: QUIT

The server rejected the recipient at RCPT TO. Had Jane existed, it would have answered 250 2.1.5 Recipient OK. Either way, the verifier sends QUIT and disconnects. No DATA command is ever issued, so no message exists and nothing lands in anyone's inbox.

This is why the method is safe for the recipient: the server sees a connection that was opened and closed without a message, the same thing that happens thousands of times a day when sending servers retry or abort.

Step 4: Is the server a catch-all?

A 250 at RCPT TO only means something if the server rejects addresses that do not exist. Some servers accept everything. To check, the verifier asks about a second, random address at the same domain:

Verifier: RCPT TO:<xk7q2rwb9@company.com>
Server:   250 2.1.5 Recipient OK

If that is accepted too, the domain is catch-all, and the earlier yes for Jane does not prove her mailbox exists. The address is reported as Risky with a catch-all flag rather than Deliverable. The free providers never behave this way, so they are not probed; business domains are probed once and the answer remembered. More in catch-all email verification.

Reading the answers

Where the method has limits

• Catch-all domains, as above. The server will not say, so no verifier can know.
• Greylisting. Some servers refuse the first connection from any unfamiliar sender and expect a retry minutes later. A single check returns Unknown; a second check later usually succeeds. See greylisting explained.
• Providers that block verification. Yahoo and Outlook.com are strict about who may connect, and reject unfamiliar IPs before the recipient is named. An honest verifier reports Unknown here; a careless one guesses. How each big provider behaves is in how Gmail, Outlook and Yahoo respond to verification.
• Mailboxes that exist but are abandoned. The server says yes because the mailbox is there; nobody reads it. Verification confirms existence, not attention.

Why verifiers need good manners

Mail servers watch for connections that ask about many addresses and never send. Too many, too fast, from one IP, and the provider slows its replies or blocks the IP, which turns every result into Unknown. A good verifier keeps one connection per address, spaces its checks, remembers answers for a while so it does not ask the same server the same question repeatedly, and identifies itself with a hostname that matches its IP's reverse DNS.

This is also why doing it yourself from your own mail server is a bad idea: the reputation cost lands on the domain you send real mail from. A verification service takes that activity onto its own infrastructure.

What this means for your list

Verification removes the addresses that would hard-bounce, flags the ones that cannot be confirmed, and leaves you a list whose bounce rate you can predict. It cannot promise a reply or an open. For how to use the four results in practice, see how to clean an email list before a cold campaign, and for the difference between this and simple format checking, see email verification vs validation.