SMTP Verification: The Gold Standard for Email Deliverability

Validation

Why SMTP Verification Beats MX-Only Checks

Most email validators stop at the MX record level: they confirm the domain has a mail server but never ask that server whether the mailbox actually exists. SMTP verification goes further — it opens a real connection and asks.

How SMTP Probing Works

  1. Resolve MX records — find the mail server for the domain
  2. Open an SMTP connectionEHLO handshake
  3. MAIL FROM — declare a sender (typically a probe address)
  4. RCPT TO — ask if the target mailbox exists

If the server responds 250 OK, the mailbox exists. If it responds 550 or 551, the mailbox is unknown.

The connection is closed without sending any message — no email is ever delivered.

Limitations

Some servers return 250 OK for every RCPT TO regardless of mailbox existence (catch-all servers). The API detects and flags these separately.

Some servers block probing from certain IPs or rate-limit connections. In these cases, the API falls back to domain-level checks and marks smtp_verified: false with reason: "probe_blocked".

API Response

{
  "email": "[email protected]",
  "valid": true,
  "mx_found": true,
  "smtp_verified": true,
  "catch_all": false,
  "disposable": false,
  "score": 98
}

The score field (0–100) combines all signals into a single deliverability metric.

When to Use SMTP Verification

Use case Recommended check level
Newsletter form MX + disposable check
Transactional email Full SMTP verification
High-value user signup SMTP + manual confirmation email
Bulk list cleaning SMTP verification on all records

Rate Limits and Caching

SMTP probing is slow (1–3s per address) and some mail servers throttle repeated probes. Cache results for at least 24 hours and probe in background tasks, not in the request path.

Try it out

Browse Tools →

More from the Blog