SMTP verification

SMTP verification simulates delivering an email without actually sending one. Here's the process:

1. Look up the domain's MX records to find the mail server.
2. Open a TCP connection to the mail server on port 25.
3. Send a HELO greeting to identify ourselves.
4. Send MAIL FROM with a sender address.
5. Send RCPT TO with the email address being verified.
6. Read the server's response code. 250 means the mailbox exists. 550 means it doesn't.
7. Send QUIT to close the connection — no email is actually delivered.

This is the only way to definitively confirm that a specific mailbox exists on the server. Every other check looks at indirect signals; SMTP goes straight to the source.

SMTP verification is powerful but not perfect:

• Catch-all servers. Some servers accept mail for any address at their domain. SMTP will say "yes" even for non-existent mailboxes. See Catch-all domains.
• Greylisting. Some servers temporarily reject the first connection attempt as an anti-spam measure. MailSentry handles this with retries, but it can slow down verification.
• Rate limiting. Mail servers may throttle or block connections from verification services. We rotate IPs and manage connection pools to minimize this.
• Timeouts. If the server is slow or unresponsive, the SMTP check may time out. In these cases, the result is "inconclusive" and the score is based on the other 10 checks.

Email validation has two speed tiers, and every provider — including MailSentry — is subject to the same physics:

Non-SMTP checks: under 50ms. Syntax, MX records, disposable detection, typo correction, role-based detection, free provider detection, gibberish detection, spam-trap detection, domain age, and abuse patterns all run against local data and DNS lookups. These are fast because they don't depend on a third-party server.

SMTP verification: 1–5 seconds. Confirming that a specific mailbox exists requires a real TCP connection to the recipient's mail server — DNS lookup, TCP handshake, HELO, MAIL FROM, RCPT TO. A responsive corporate mail server might answer in 1 second. A shared hosting provider (Hostgator, 1&1, small business hosts) might take 5–10 seconds. This is not a MailSentry limitation — it is how SMTP works. Any provider claiming sub-second full verification is either skipping the SMTP step or returning a cached result.

MailSentry runs all 11 checks in parallel, so the total response time equals the slowest check — usually SMTP. If SMTP completes in 1.5 seconds, you get all 11 results in 1.5 seconds, not 1.5 seconds plus the other checks stacked on top.

When SMTP is inconclusive. Some mail servers don't give a straight answer. Greylisting temporarily rejects the first connection attempt and expects you to retry later. Anti-probe servers (Gmail, Yahoo, Outlook) reject all RCPT TO probes with 550 regardless of whether the mailbox exists. Rate limiting blocks connections entirely. When this happens, MailSentry returns smtp.valid: null and the score is calculated from the other 10 checks. The verification_level field will show estimated instead of confirmed, so you always know how much certainty is behind the score.

How we handle retries. MailSentry uses progressive timeouts — 1.5s, then 2.5s, then 3.5s — retrying only on timeouts and connection errors, not on definitive server responses. If the server says "mailbox doesn't exist" on the first attempt, we trust it immediately. If the connection times out, we retry with a longer window. This balances speed against accuracy without wasting time on servers that gave a clear answer.

SMTP caching. Results are cached for 7 days. If the same email is verified again within that window, the response is instant — no SMTP connection needed. This means bulk re-verification of your list is significantly faster than the first pass.