Finding & verification

SMTP verification

Mailbox check done over SMTP: connect, say hello, and ask RCPT TO. Done carefully so it is not a delivery, and not a burst that looks like an attack.

Mailbox check done over SMTP: connect, say hello, and ask RCPT TO. Done carefully so it is not a delivery, and not a burst that looks like an attack.

The conversation

SMTP is the protocol mail servers use to hand messages over. Verification starts that conversation and stops before the message is sent:

  1. EHLO — introduce yourself.
  2. MAIL FROM:<sender@yourdomain.com> — name a sender.
  3. RCPT TO:<jane.doe@company.com> — name the recipient. This is the question. The server answers 250 (accepted) or 550 (no such mailbox).
  4. QUIT — leave without sending a DATA command, so no email is created and nobody receives anything.

Why it is not always conclusive

The server's answer to step 3 is only as honest as the server:

  • A catch-all says 250 to everything.
  • A greylisting server says 451 and asks you to try again later.
  • Some gateways and large providers answer ambiguously on purpose, to avoid being used to enumerate their users.
  • Some servers rate-limit or block hosts that probe repeatedly.

A good verifier reports each of these as what it is, instead of rounding to valid or invalid.

Why you probably should not run it yourself

Many cloud hosts block outbound port 25 by default, probes from a reputation-poor IP get refused or throttled, and a clumsy prober gets your IP listed. Doing it well means managing sending IPs and per-provider behaviour. That is the reason to use a service for it.

Compare with the cheaper checks it sits above: syntax and MX check. To see it in action, use the email verifier.

Also see: Mailbox check

Ready to try it on a real list?

Mailbox check done over SMTP: connect, say hello, and ask RCPT TO. Done carefully so it is not a delivery, and not a burst that looks like an attack.

Get started

Related