What is email verification?

Syntax. Is this a well-formed address under RFC 5322? A library answers this offline, in microseconds, and it is the layer every tutorial teaches. It is also the layer that tells you the least: [email protected] is perfectly well-formed.

Domain and MX. Can this domain receive mail at all? A DNS lookup answers it. This is what libraries usually mean by "check deliverability", and the name misleads people — it is a check on the domain, not on the mailbox.

Mailbox. Does this specific mailbox exist? Only the receiving mail server knows. There is no local computation, no database and no pattern that can answer it, which is why this layer needs a conversation with the server and why everything difficult about verification lives here.

The probe resolves the domain’s MX, opens an SMTP session, greets the server with EHLO, names a sender with MAIL FROM, names the address with RCPT TO, and reads the reply. Then it stops. DATA is never sent, so there is no message — nothing appears in anyone’s inbox and nothing is recorded against the recipient.

The reply is the answer. 250 means the server would accept mail for that address. A 5xx naming the mailbox means it would not. A 4xx means "not now" — the server is greylisting, throttling, or having a bad minute.

Verification and validation are used interchangeably in most marketing, including ours. Where a distinction is drawn, validation means the local layers — syntax and DNS — and verification means asking the server. The distinction worth insisting on is not the word: it is whether a mail server was asked.

A verifier is only as accurate as the IP addresses it probes from. A brand-new address opening thousands of SMTP sessions looks exactly like a dictionary attack against the receiving server — because at the protocol level it is the same traffic — and it gets blocked. Every result produced after that is unknown at best and a false negative at worst.

So every probe here is metered against a specific sending IP with its own warmup day, pacing curve, per-provider sub-caps, reputation score and cooldown. It is the least visible part of the product and it is the part that decides whether any of the answers are worth having. It is also the reason implementing this yourself is harder than the protocol makes it look.

At signup: syntax in the browser, instantly. A network round trip in a form field is a worse experience than the typo it catches.

On submission: syntax and MX server-side. Fast enough to run inline, and it catches the whole class of addresses at domains that cannot receive mail.

In a background job: the SMTP probe. It takes seconds rather than milliseconds — it involves a conversation with someone else’s server — so it belongs on a queue, not in a request handler.

Before a campaign: in bulk, close to the send. That is where list hygiene and verification meet.

A verification costs half a credit. The free plan is 100 credits every month, renewing, with no card — about 200 verifications a month. A result marked retryable is never charged, because the mailbox was not tested.

What verification cannot do: predict whether a mailbox will still exist next month, tell you whether mail will land in the inbox rather than the spam folder, or say anything about a catch-all domain’s individual mailboxes. Anyone selling those three as verification features is selling something else.