How SMTP Email Verification Works

SMTP email verification asks a receiving mail server whether it will accept a recipient. It does not send the message body, read an inbox, prove ownership, or guarantee future delivery.

The useful result is narrower: accepted, explicitly rejected as a missing mailbox, or inconclusive.

That third state is essential. Mail servers defer unfamiliar clients, block probes, hide recipient information, and apply policy rules that have nothing to do with whether a mailbox exists.

Where SMTP fits in email verification

SMTP is a mailbox-level check near the end of a verification pipeline:

1. Validate the address structure.
2. Normalize and validate the domain.
3. Resolve mail-routing DNS.
4. Classify provider, disposable, free, and role-address signals.
5. Probe recipient acceptance over SMTP when a private probe is available.
6. Map all evidence to deliverable, risky, undeliverable, or unknown.

There is no SMTP connection to make when the domain publishes a null MX record. RFC 7505 defines null MX as an explicit statement that a domain does not accept email.

For the broader sequence, read What Is Email Verification?. This guide stays at the SMTP layer.

The SMTP probe sequence

A simplified, illustrative recipient session follows the mail envelope and stops before DATA:

S: 220 mx.studio.example ESMTP
C: EHLO probe.emailverifier.dev
S: 250-mx.studio.example
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS

C: EHLO probe.emailverifier.dev
S: 250 mx.studio.example
C: MAIL FROM:<probe@emailverifier.dev>
S: 250 2.1.0 Sender OK
C: RCPT TO:<nora@studio.example>
S: 250 2.1.5 Recipient OK
C: RSET
S: 250 2.0.0 Reset
C: QUIT
S: 221 2.0.0 Bye

The commands have distinct jobs:

• EHLO identifies the client and discovers server extensions.
• STARTTLS upgrades the connection when the server offers it.
• MAIL FROM starts the envelope and supplies the return path.
• RCPT TO identifies the recipient being tested.
• RSET clears the current transaction.
• QUIT ends the session.

RFC 5321 defines the recipient command. The verifier never reaches DATA, so no message content is submitted.

Read reply classes before reply text

SMTP’s first digit tells you the broad result:

RFC 5321 explains the reply classes. The IANA enhanced status-code registry adds more specific meanings such as destination mailbox status and policy failures.

A blanket rule such as “every 550 means nonexistent” is unsafe. A server can use a permanent reply for sender reputation, authentication, relay, or local policy. Mark an address undeliverable only when the response clearly identifies the recipient mailbox as missing or invalid.

Three reply examples, three different decisions

Explicit mailbox rejection

C: RCPT TO:<missing@company.com>
S: 550 5.1.1 No such user

The basic code, enhanced code, and message agree that the destination mailbox is missing. This can support an undeliverable result.

Temporary deferral

C: RCPT TO:<nora@studio.example>
S: 451 4.7.1 Try again later

This is not a rejection of Maya’s mailbox. It is a temporary response. RFC 6647 documents greylisting, including implementations that return 4yz replies to unfamiliar SMTP tuples. A short verification request may not be able to perform the delayed retry a full mail transfer agent would make.

Result: unknown.

Policy rejection

C: RCPT TO:<nora@studio.example>
S: 550 5.7.1 Client not permitted

The response is permanent for this client under the current policy, but it does not say the mailbox is absent.

Result: unknown, unless another independent check establishes a confirmed failure.

Acceptance still has limits

A 250 reply supports one statement: the server accepted the recipient command during that session.

It does not establish that:

• The address belongs to the person who submitted it.
• The message will reach an inbox instead of a filter or quarantine.
• The user will retain access tomorrow.
• The domain is not disposable.
• The local part is not shared by a team.
• The server does not accept every recipient.

The last case is why a verifier may run a second recipient check with a random local part. If the random control is also accepted, the domain behaves like a catch-all. The catch-all email domain guide shows the full comparison.

Why SMTP verification becomes unknown

Unknown is not one error. It is a group of situations where the available evidence cannot support a mailbox claim:

• The connection times out or closes early.
• The server defers the request with a 4yz reply.
• The server rejects the probe client by policy.
• The server accepts the target but gives an ambiguous reply to the random control.
• TLS negotiation or the SMTP greeting fails.
• The provider deliberately avoids revealing recipient validity.
• Outbound port 25 is unavailable from the verifier’s network.

Turning these cases into “deliverable” inflates confidence. Turning them into “undeliverable” blocks people the server never rejected. unknown is the technically accurate result.

Safe probe implementation rules

An SMTP probe accepts a user-controlled domain and opens network connections, so the network boundary matters as much as the parsing logic.

• Resolve hostnames and reject private, loopback, link-local, documentation, and other non-public address ranges.
• Use strict connection and command deadlines.
• Bound concurrency so slow servers cannot exhaust the probe.
• Limit the number of MX hosts attempted.
• Use a stable, valid EHLO name and envelope sender.
• Stop before DATA.
• Rate-limit callers and keep the probe private.
• Return a compact result instead of exposing raw server transcripts to untrusted clients.

The raw transcript can contain operational details from another organization’s mail system. It belongs in restricted diagnostics, not in a public API response.

How the API maps SMTP evidence

Provider and address-type signals can adjust the final action without rewriting the SMTP fact. A disposable address can be accepted by its mail server and still return risky. A role address can be accepted and return deliverable with review.

Test observable outcomes

A useful test suite needs controlled SMTP servers for:

• Accepted target and rejected random control
• Accepted target and accepted random control
• Explicit missing-mailbox reply
• Temporary deferral
• Permanent policy rejection
• Multi-line EHLO reply
• STARTTLS success and failure
• Connection timeout and early close
• Multiple MX hosts
• DNS resolution to blocked address ranges

SMTP verification is useful because it adds mailbox-level evidence. It is trustworthy only when the implementation also knows when to stop claiming.

Use the emailverifier.dev REST API to receive the compact decision, or read the production result-handling guide before wiring it into a signup flow.