SMTP Verification: The Gold Standard for Email Deliverability
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
- Resolve MX records — find the mail server for the domain
- Open an SMTP connection —
EHLOhandshake MAIL FROM— declare a sender (typically a probe address)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.