SMTP Verification
What is SMTP Verification?
The core technical stage of email verification where a verifier connects to the recipient domain's MX server over TCP port 25, negotiates `EHLO` / `STARTTLS`, sends `MAIL FROM` and `RCPT TO:<[email protected]>`, and evaluates the server's 2xx, 4xx, or 5xx response before closing the session (`QUIT`) without sending a `DATA` payload.
Why SMTP Verification Matters in Production
Direct SMTP handshaking is the only non-intrusive way to verify whether a specific mailbox actually exists without sending an email to the recipient. Accurate SMTP verification must also probe whether the server is a catch-all and parse provider-specific over-quota (`452`) and disabled-account codes.
Engineering & Sender Best Practices
- • Never run raw port-25 SMTP probes from your own application server or office IP—ISPs will rapidly block your IP on Spamhaus.
- • Use a managed verification API (MailVeri) that handles provider-specific SMTP quirks across Gmail, Microsoft 365, Yahoo, and custom MTAs.
- • Account for catch-all servers where `RCPT TO` returns `250 OK` for every address by testing a synthetic random local-part first.
- • Treat unresolved `4xx` greylisting or temporary throttling responses as `UNKNOWN` (0 credits billed) rather than guessing.
Handling Provider-Specific SMTP Nuances Across Gmail, Microsoft 365 & Custom MTAs
An internal engineering team tried building a DIY Python script to check `RCPT TO` on Port 25 from their AWS EC2 instance. Within 20 minutes, AWS blocked outbound Port 25, Spamhaus listed their IP on PBL/SBL, and Yahoo/Outlook returned fake `250 OK` responses to every probe. Switching to MailVeri's managed verification API ($9 per 10K) gave them accurate 7-status results without managing MTA infrastructure.
Technical Implementation & Wire Example
S: 220 mx.example.com ESMTP Postfix
C: EHLO verifier.mailveri.com
S: 250-mx.example.com
S: 250 STARTTLS
C: MAIL FROM:<>
S: 250 2.1.0 Ok
C: RCPT TO:<[email protected]>
S: 250 2.1.5 Ok
C: QUIT
S: 221 2.0.0 ByeBy terminating the SMTP session with QUIT immediately after the RCPT TO response, no email is ever delivered to the user.
SMTP Reply Codes & Bounce Classification Reference
RFC 5321 & Enhanced RFC 3463 Status Codes| SMTP Code | Bounce Classification | Server Meaning | MailVeri Status & Action |
|---|---|---|---|
| 250 2.1.5 | Deliverable (2xx) | Recipient RCPT TO accepted by destination MTA | VALID (or CATCH_ALL if wildcard server) |
| 452 4.2.2 | Soft Bounce (Storage) | Recipient mailbox has exceeded storage quota | FULL_INBOX — pause sends for 30 days |
| 421 / 450 4.7.1 | Soft Bounce (Transient) | Temporary greylisting or concurrent connection deferral | UNKNOWN (0 credits billed) |
| 550 5.1.1 | Hard Bounce (5xx) | User unknown / mailbox does not exist on server | INVALID — suppress permanently |
| 550 5.7.1 | Policy / Reputation Block | Rejected due to sender reputation, RBL, or DMARC failure | Check sender domain DNSBL & authentication |
Understanding SMTP Verification: How Direct Mail Server Handshakes Work →
Walk through the exact RFC 5321 EHLO, MAIL FROM, and RCPT TO wire protocol used to verify email addresses silently.
Free Bounces & SMTP Signals Tools & Workflows
Frequently Asked Questions About SMTP Verification
Why does SMTP verification stop before the `DATA` command?
In the RFC 5321 state machine, the receiving server validates the recipient address immediately upon receiving `RCPT TO:<address>` and replies with `250 OK`, `4xx`, or `5xx`. Sending `QUIT` right after `RCPT TO` confirms mailbox existence without transmitting a message body or notifying the recipient.
Why can't I run raw Port 25 SMTP verification from my own cloud server or laptop?
Cloud providers (AWS, GCP, Azure, DigitalOcean) block outbound TCP port 25 by default, and residential/datacenter IPs lacking matching rDNS (PTR), HELO alignment, and established sender reputation are immediately blocked or fed false replies by ISP anti-harvesting filters.
How does SMTP verification distinguish a real `250 OK` from a catch-all `250 OK`?
When a target domain accepts a probe for a non-existent random address with `250 OK`, a standard `RCPT TO` check on your real lead will also return `250 OK`. MailVeri detects this wildcard behavior and returns `CATCH_ALL` rather than falsely labeling the address `VALID`.
Closely Related Terms
Explore All Email Verification Terms (A–Z)
Glossary Index →Explore Related Verification Benchmarks, Integrations & Deliverability Hubs
Compare live 10K–5M verification rate cards, connect MailVeri to your outreach stack, or inspect domain-level SMTP rules.
- MailVeri vs Verifalia100K checks: $59 vs $389
- MailVeri vs ProspeoCompare 10K–1M pricing & accuracy
- MailVeri vs Bouncify100K checks: $59 vs $119
- MailVeri vs Reoon Email Verifier100K checks: $59 vs $116.40
- MailVeri vs Kickbox100K checks: $59 vs $500
- MailVeri vs Byteplant Email Validator100K checks: $59 vs $1,349
- Google Sheets Apps ScriptVerify cells directly in Sheets
- Amazon SES & Sendy ProtectionStay safely below 5% SES probation
- Apollo.io CSV & API VerificationKeep cold outreach bounces < 1.5%
- Klaviyo & Shopify HygieneCut active profile overpayments
- Clay.com HTTP API Waterfall0 Clay credits ($59 per 100K)
- FluentCRM & WordPress SMTPBulk CSV & PHP signup hooks
- DNSBL Blacklist CheckerScan Spamhaus, Barracuda & SORBS
- E-Commerce & Klaviyo BrandsStop fake coupon signups
- Email Bounce Rate CalculatorCheck ESP suspension thresholds
- Non-Profits & FundraisingNon-expiring PAYG donor cleaning
- ESP Overpayment CalculatorMeasure wasted CRM contact costs
- Free Email Verifier ToolInstant live deliverability check
- Email AuthenticationAuthentication & DNS definition
- Inbox Placement RateReputation & Inbox Placement definition
- Sender ScoreReputation & Inbox Placement definition
- ruutukf.com Disposable CheckRotating burner MX quarantine
- relay.firefox.com Mask GuideMozilla relay bounce behavior
- anthropic.com Domain SecurityStrict DMARC & MX inspection
Ready to start verifying emails?
Get 1,000 free credits when you sign up. No credit card required.