The sequence is short and every step is observable. Open a TCP connection on port 25. Read the server's greeting. Send EHLO and read what it supports. Send MAIL FROM to declare a sender. Send RCPT TO naming the address being checked. Read the reply. Send QUIT.
Message content would come next, after a DATA command. That command is never sent. Since the server commits to accepting or rejecting a recipient before any body is transferred, there is a natural place to learn the answer and leave, and that is exactly where verification stops.
Buyers ask about this constantly and the worry is reasonable. Nobody wants a list-cleaning exercise to put a blank message in front of five thousand prospects, or to tip off a contact that they are being checked before a campaign.
There is one genuine trace. The connection appears in the receiving server's logs, as any connection does, showing an address connected and asked about a recipient. Mail administrators see this routinely from filters, gateways and other verifiers, and it reaches no mailbox.
The practice does have a cost elsewhere: repeated probing is why large providers throttle and why some block verification traffic from cloud infrastructure entirely. That is a constraint on coverage rather than a risk to your recipients.
What the mail admin sees in the log
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.
Four things that do send mail, and get mixed up with this
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.
Related questions
Will the recipient know their address was checked?
Nothing reaches their mailbox. A mail administrator reading connection logs would see the connection, as they would for any filter or gateway.
Does verification affect my sender reputation?
Verification runs from our infrastructure, not yours, so your sending reputation is untouched by the check itself.
Why do people think verification sends mail?
Because confirming an address sounds like it should require delivering something. The protocol commits to a recipient before content, which is what makes the shortcut possible.
Can a server tell a probe from a real delivery?
Yes. A connection that ends after the recipient command without sending data is a recognizable pattern, and some servers respond to it differently.