What is SMTP?
SMTP — Simple Mail Transfer Protocol — is the protocol that powers email delivery across the internet. Defined originally in RFC 821 (1982) and updated in RFC 5321, SMTP is the language that mail servers speak to each other when sending and receiving email.
Every email you've ever sent or received was delivered via SMTP. When you click "send" in Gmail, your email client hands the message to Google's SMTP server, which then connects to the recipient's SMTP server and delivers it. The entire process is a structured conversation between two servers, following a specific sequence of commands and responses.
SMTP verification leverages this same protocol to check whether a mailbox exists — without actually delivering a message.
How the SMTP Handshake Works
An SMTP conversation follows a strict sequence. Understanding this sequence is key to understanding how verification works. Let's walk through a complete SMTP session.
Step 1: TCP Connection
The sending server establishes a TCP connection to the recipient's mail server on port 25 (the standard SMTP port). The recipient's server is identified by looking up the domain's MX records.
[Client connects to mail.example.com:25]
Server: 220 mail.example.com ESMTP ready
The 220 response code means the server is ready to accept commands.
Step 2: EHLO (Extended Hello)
The client introduces itself with the EHLO command, providing its hostname:
Client: EHLO verify.sendsure.ai
Server: 250-mail.example.com Hello verify.sendsure.ai
Server: 250-SIZE 35882577
Server: 250-8BITMIME
Server: 250-STARTTLS
Server: 250-AUTH LOGIN PLAIN
Server: 250 OK
The server responds with its capabilities. The 250 response code means success. The capabilities listed (SIZE, 8BITMIME, STARTTLS, AUTH) tell the client what features the server supports.
Step 3: MAIL FROM (Envelope Sender)
The client specifies who the email is from:
Client: MAIL FROM:<check@verify.sendsure.ai>
Server: 250 OK
This sets the "envelope sender" — the address that bounce notifications would be sent to. In a real email delivery, this is the sender's address. In verification, it's the verification service's address.
Step 4: RCPT TO (Recipient) — The Critical Moment
This is where verification happens. The client specifies the recipient address:
Client: RCPT TO:<user@example.com>
Server: 250 OK
The server's response to RCPT TO reveals whether the mailbox exists:
| Response Code | Meaning | Verification Result | |---|---|---| | 250 | Mailbox exists, will accept mail | Valid | | 251 | User not local, will forward | Valid (with caveats) | | 450 | Mailbox temporarily unavailable | Retry later (soft fail) | | 451 | Server error, try again later | Retry later (greylisting common) | | 452 | Insufficient storage | Valid but full | | 550 | Mailbox does not exist | Invalid | | 551 | User not local | Invalid at this address | | 552 | Storage exceeded | Valid but full | | 553 | Mailbox name invalid | Invalid | | 554 | Transaction failed | Ambiguous (may be policy block) |
Step 5: QUIT (Disconnect)
In verification, we don't proceed to send any message data. We have our answer and disconnect:
Client: QUIT
Server: 221 Bye
No email is ever sent. The verification is completely non-intrusive — it's the equivalent of knocking on a door to see if anyone's home, then walking away.
Why SMTP Verification is the Gold Standard
SMTP verification is considered the most reliable method for checking email validity because it queries the authoritative source — the actual mail server responsible for the address. No other method gets as close to ground truth.
Direct Server Communication
Unlike syntax checks (which only validate format) or MX lookups (which only validate the domain), SMTP verification communicates directly with the server that manages the specific mailbox. When Google's server says user@gmail.com exists, that's as authoritative as it gets.
No Email Sent
SMTP verification confirms existence without sending anything. This means no inbox clutter, no spam complaints, and no deliverability impact. You're checking validity without any side effects.
Rich Response Data
The SMTP response codes provide nuanced information beyond simple valid/invalid. A 452 response (mailbox full) tells you the address exists but the user may not be actively checking their email. A 550 with enhanced status code 5.7.1 tells you the address is blocked by policy rather than non-existent. This granularity enables more sophisticated list management.
Universal Protocol
SMTP is the universal standard for email. Every mail server in the world speaks it. Unlike provider-specific APIs (which only work for one email platform), SMTP verification works for any email address on any provider.
Limitations of SMTP Verification
Despite being the most reliable method available, SMTP verification isn't perfect. Several factors can complicate or prevent accurate results.
Catch-All Domains
A catch-all (accept-all) domain is configured to accept email for any address, regardless of whether the specific mailbox exists. When you send RCPT TO:<anything@catchall-domain.com>, the server always responds 250 OK.
This means SMTP verification cannot distinguish between real and non-existent mailboxes on catch-all domains. The server is saying "yes" to everything.
Catch-all domains are common in B2B email lists, accounting for 15-30% of addresses. Handling them requires additional techniques beyond SMTP — name pattern analysis, external signal cross-referencing, and AI-based resolution. This is one area where SendSure's 27-stage pipeline extends well beyond basic SMTP checking.
Greylisting
Greylisting is an anti-spam technique where the mail server temporarily rejects the first delivery attempt from an unknown sender. The assumption is that legitimate mail servers will retry (as required by the SMTP spec) while spambots won't.
During verification, a greylisting server responds with a 451 temporary rejection:
Client: RCPT TO:<user@greylisted-domain.com>
Server: 451 4.7.1 Please try again later
A naive verifier would interpret this as "unable to verify" or even "invalid." A proper verification system recognizes greylisting behavior and retries after the appropriate delay — typically 5-15 minutes.
Rate Limiting
Mail servers protect themselves from abuse by limiting the number of connections and commands from a single IP address within a time window. Gmail, for example, limits SMTP connections and will temporarily block IPs that exceed their thresholds.
Rate limiting responses look like this:
Server: 421 4.7.28 Too many connections from your IP
or
Server: 452 4.5.3 Too many recipients
For a verifier checking thousands of addresses, rate limiting is the primary operational challenge. You need enough IP addresses and careful throttling to stay within each provider's limits.
Connection Blocks
Some mail servers outright refuse SMTP connections from IPs they don't recognize as legitimate senders. They check:
- Reverse DNS (PTR records) — Does the connecting IP resolve to a hostname?
- SPF alignment — Is the connecting IP authorized to send for the MAIL FROM domain?
- IP reputation — Is this IP on any blocklists?
- Connection history — Has this IP sent legitimate mail before?
An IP that fails these checks may be rejected at the TCP connection stage, before any SMTP commands are exchanged.
Deferred Responses
Some servers accept the RCPT TO command with a 250 OK but then bounce the actual message during the DATA phase. Since verification stops before DATA, these deferred rejections aren't visible to the verifier.
This is relatively rare but does occur with some enterprise mail gateways and custom configurations. The address appears valid during verification but bounces during real delivery.
How SendSure Handles SMTP Verification at Scale
Running SMTP verification at scale — checking millions of addresses per day — requires infrastructure and techniques that go far beyond making simple SMTP connections. Here's how SendSure's verification pipeline addresses the challenges above.
VPS Load Balancing
Rather than running all verification from a single IP address (which would be rate-limited into oblivion), SendSure distributes SMTP checks across a fleet of VPS instances in multiple geographic regions. Each VPS has:
- A dedicated IP address with proper PTR (reverse DNS) records
- SPF-authorized sending configuration
- Warm IP reputation from legitimate sending history
- Independent rate limit budgets
When verifying a batch of addresses, the load balancer distributes checks across available VPS instances, routing verification requests to the instance with the best available capacity for each target domain. If one IP gets rate-limited by Gmail, another takes over while the first cools down.
Provider-Specific Strategies
Different email providers have different behaviors, thresholds, and quirks. SendSure maintains provider-specific verification strategies based on the MX record analysis performed in stage 2 of the pipeline:
Google Workspace: Reliable SMTP responses with moderate rate limiting. We throttle to stay well within their connection limits and respect their documented thresholds.
Microsoft 365: More aggressive rate limiting and occasional delayed responses. We use longer timeouts and more conservative concurrency for Microsoft domains.
Yahoo/AOL: Strict rate limiting with longer cooldown periods. We distribute Yahoo verification across more IPs with lower per-IP concurrency.
Self-hosted servers: Highly variable behavior. We adapt dynamically based on the server's responses, adjusting timeout, retry, and concurrency settings in real time.
Per-Domain Concurrency Control
Overwhelming a single mail server with simultaneous connections is the fastest way to get blocked. SendSure enforces per-domain concurrency limits — a maximum number of simultaneous SMTP connections to any single domain's mail servers.
This means that even when processing a list of 100,000 addresses all at the same domain, we space out the checks to stay within the server's comfort zone. The total verification time may be longer, but the results are accurate and the server isn't disrupted.
Greylisting Detection and Retry
When the pipeline encounters a 451 response, it doesn't immediately classify the address as unverifiable. Instead, it identifies the response as likely greylisting and schedules a retry after a 5-15 minute delay.
The retry happens on a different VPS instance than the original attempt, which sometimes bypasses the greylisting trigger entirely (since the server may have already allowlisted the verification's MAIL FROM domain after the first attempt).
Multi-Stage Fallback
When SMTP verification produces an ambiguous result (timeout, temporary rejection, catch-all 250), the pipeline doesn't stop. It proceeds to later stages that use alternative signals:
- External data sources — Gravatar, GitHub, HIBP cross-referencing
- Name pattern analysis — Is the local part a real name or random characters?
- Historical data — Have we verified this address before? What was the previous result?
- Domain behavior modeling — Based on our verification history for this domain, what's the expected false-positive rate?
These additional stages resolve many of the addresses that SMTP alone can't definitively classify.
SMTP Verification vs. Other Methods
How does SMTP verification compare to the alternatives?
SMTP vs. Syntax-Only Validation
Syntax validation catches approximately 5-10% of invalid addresses (formatting errors, typos). SMTP verification catches 85-95%. There's no comparison in accuracy, but syntax validation is free and instant, making it a useful first filter before the more expensive SMTP check.
SMTP vs. Ping/Telnet Checks
Some legacy tools use raw telnet connections to check SMTP. This is functionally identical to SMTP verification but without the error handling, retry logic, rate limit management, and provider-specific strategies that a proper verification service provides. DIY telnet checks produce unreliable results at any meaningful scale.
SMTP vs. Provider-Specific APIs
Some email platforms offer APIs that can check address validity (e.g., Google's People API, Microsoft's Graph API). These are accurate for their own platform but useless for addresses on other providers. SMTP verification works universally across all providers.
SMTP vs. Multi-Stage Verification
The most accurate approach is what modern verification services use: SMTP as the core verification method, supplemented by DNS analysis, disposable detection, catch-all resolution, risk scoring, and external signal cross-referencing. SMTP alone catches most invalid addresses; the additional stages handle the edge cases that SMTP can't resolve. For a comparison of how different providers approach this, see our comparison pages.
When to Use SMTP Verification
SMTP verification is appropriate for:
- Bulk list cleaning — Verify entire lists before campaigns
- Real-time form validation — Check addresses at the point of entry (with appropriate timeout handling)
- CRM hygiene — Periodic verification of your contact database
- Import validation — Verify purchased or partner-provided lists before adding to your system
It's less appropriate for:
- High-frequency checks of the same address — Most servers will block repeated verification attempts for the same recipient. Cache results for at least 24-48 hours.
- Checking addresses at domains you know are catch-all — SMTP will always return 250. Use quality scoring instead.
- Environments where latency is critical — SMTP verification takes 1-5 seconds per address. If sub-second response is required, pre-verify and cache results.
The Future of SMTP Verification
The SMTP protocol is over 40 years old, and while it has been extended and updated over the decades, the core verification mechanism hasn't fundamentally changed. However, the environment around it has:
Stricter ISP policies mean that poorly managed verification can damage your sending infrastructure. The bar for IP reputation has risen significantly since 2024.
Increased privacy regulations (GDPR, CCPA) have made some organizations more cautious about allowing third-party SMTP connections, though verification itself doesn't involve personal data processing.
AI and machine learning are being used to supplement SMTP with predictive models that assess address validity using behavioral patterns, historical data, and cross-platform signals. This hybrid approach is increasingly important as more domains adopt catch-all configurations.
SMTP verification will remain the backbone of email validation for the foreseeable future. But the most effective verification services are those that use SMTP as one component in a broader, multi-signal pipeline — exactly the approach SendSure takes with its 27-stage verification engine.
Try It Yourself
See SMTP verification in action by testing your email list with SendSure. Every verification runs through the full 27-stage pipeline — including SMTP checks, MX analysis, disposable detection, catch-all resolution, and risk scoring.
Sign up for free and get 100 verification credits. Upload a list or verify individual addresses and see the detailed results, including SMTP response codes, provider detection, quality scores, and sub-status classifications.
