Does email verification send an email?

The sequence is short, and you can watch every step. Open a TCP connection on port 25 and read the server's greeting. Send EHLO and read what the server supports. Send MAIL FROM to declare a sender. Send RCPT TO naming the address being checked, and read the reply. Send QUIT.

Message content would come next, after a DATA command. That command is never sent. The server commits to accepting or rejecting a recipient before any body is transferred, so there's a natural place to learn the answer and leave. Verification stops exactly there, and the SMTP handshake page walks through each reply code.

The reply to RCPT TO carries the answer. A 250 means the server will take mail for that address. A 550 means no such user. A 4xx asks you to try later, which is often greylisting, and a 252 means the server won't say. One more probe with a made-up address tells you whether the domain accepts everything, which is what a catch-all domain does.

Buyers ask about this all the time, and the worry is reasonable. Nobody wants a cleanup to put a blank message in front of five thousand prospects, or to tip off a contact before a campaign.

There's one trace. The connection shows up in the receiving server's logs, as any connection does, noting that an address connected and asked about a recipient. Mail admins see this every day from spam filters, gateways and other verifiers, and it never reaches a mailbox.

Probing does shape coverage. Large providers throttle repeated connections, and Gmail and Microsoft 365 block probes that come from cloud networks. None of that touches your recipients, and it's why a good verifier reports the addresses it couldn't get an answer on as their own result.

Say the company you're checking runs Postfix, a common mail server. After a verification probe, its log holds one short line for the visit. It names the address that connected and ends with a tally like ehlo=1 mail=1 rcpt=1 quit=1 commands=4.

Read that tally closely. There was one greeting, one sender, one recipient and one goodbye. No data=1 appears, because no message was ever offered. For a real delivery the same line would include a data count, and the mail queue would show a message id. Here there's nothing to queue.

That line is the whole footprint. It sits in a server log that only an administrator reads, next to thousands of similar lines from spam filters and security gateways. Your contact's inbox, spam folder and phone stay untouched, because nothing was handed to the server to put there.

A confirmation email is the first. When a signup form sends a click-to-confirm message, that's a real email. It proves something verification can't: that the person wants your mail.

Warmup tools are another. They send real messages between mailboxes to build a sending history, and they have nothing to do with checking whether an address exists.

Seed tests work the same way. You send a campaign to a panel of test inboxes to see where it lands, and those are real deliveries too.

Then there's the verify-by-sending trick some old scripts use. A blank or test message goes out, and the script waits for a bounce. That one does reach inboxes, and it's the reason buyers worry.

You can settle it for yourself in a minute. Run your own address through a verifier, then watch your inbox and spam folder. With us, the free allowance of 100 checks a month covers that test many times over.