How the address check works

It is an ordinary SMTP conversation that we hang up on. The recipient's own mail server is the only authority on whether one of its mailboxes exists, so we ask it — and then we stop before the command that would deliver anything.

The conversation, in full

For an address at example.com, the host looks up that domain's MX records, opens a connection to the mail server the domain itself nominates, and says this much:

HELO probe.danisflow.online
MAIL FROM:<>
RCPT TO:<contact@example.com>
  → 250 Recipient OK          the mailbox exists
  → 550 5.1.1 User unknown    the mailbox does not exist
QUIT

The DATA command, which is the one that would transmit a message, is never issued. There is no message to transmit: nothing is composed, queued or attached. The server answers RCPT TO from its own recipient directory and we record the answer.

The null sender is deliberate. MAIL FROM:<> is the empty reverse-path from RFC 5321 §4.5.5 — the same envelope sender a mail server uses for a bounce notification. It cannot be replied to and it cannot be used to deliver anything.

The limits we hold ourselves to

Rate	One check every four seconds, and a hard daily ceiling in the low hundreds. This is not a bulk scanner and it is not built to be one.
Retries	A temporary refusal (any `4xx`) is recorded as “no answer yet” and not retried in the same run. Greylisting works on us the way it is supposed to.
Guessing	We do not iterate through candidate names hunting for a valid one. We check addresses we already hold, and one non-existent name per domain for the reason below.
Scope	One connection to the port a domain publicly advertises for mail. No port scanning, no probing of any other service.

The one address we check that is not real

Many mail servers are configured to accept every address at a domain and sort it out later. Against those, a 250 means nothing at all. To detect that, the host first offers one randomly generated local part that cannot belong to anybody. If the server accepts it, we mark the whole domain as unverifiable and treat every address on it as unknown rather than drawing a false conclusion. That check is why you may see two connections from us instead of one.

What we conclude, and what we refuse to conclude

An answer about us is never recorded as an answer about the mailbox. A refusal citing reputation, policy, rate limits, or RFC 3463 class 5.7.x — the class reserved for security and policy status — is filed as “blocked, unknown” and the address is left exactly as it was. Only an explicit statement that the recipient does not exist is recorded as a dead address.

This distinction is the whole point of the exercise. Reading “we don't like your server” as “this person doesn't exist” would quietly discard real contacts, which is the opposite of what verification is for.