Step by Step SMTP Handshake Process for Email Verification Services

What Happens During an SMTP Handshake When Verifying an Email?

You send an email to a list. It bounces. You don’t know why. Is the address wrong? Or is the server blocking it? A simple syntax check won’t tell you.

MailTester and similar verification services don’t guess. They simulate the actual SMTP handshake process for email verification services — a live, real-time TCP-level connection to the recipient’s mail server. This isn’t about checking if an email has the right format. It’s about confirming whether that server actually accepts mail for that address.

The step by step smtp handshake process for email verification services reveals the truth: an address is only valid if the server responds as expected to a full SMTP transaction. This exposes invalid, disabled, or catch-all addresses that syntax checks miss.

Key takeaways

• The SMTP handshake during email verification replicates a real email send attempt at the protocol level.
• It detects active mail servers and real inboxes, not just formatted addresses.
• Static checks fail on catch-all domains or temporary blocklists; the handshake exposes these limitations.

Why Does SMTP Verification Matter for Email List Hygiene?

You need SMTP verification because syntax checks alone can’t spot dead accounts, server rejections, or temporary blocks. A real-time handshake with the recipient’s mail server confirms whether an address is actually accepting mail—helping you avoid bounces, protect your sender reputation, and improve deliverability before you send.

Static Checks Fall Short in the Real World

Just because an email looks right doesn’t mean it’s live. Format validation finds typos and invalid syntax, but it can’t detect a deactivated account, a full inbox, or a server blocking your domain. According to RFC 5321, the SMTP protocol defines how mail servers talk, and real-world acceptance isn’t just about format—it’s about what the server says during the handshake.

Let’s say you send to 10,000 emails that passed syntax checks. If 1,200 of them are inactive or filtered by the recipient's server, those hard bounces hurt your sender reputation. Over time, senders with high bounce rates get flagged by major email providers, even if the emails were technically valid. That’s why relying only on static checks is like checking a car’s tires before a trip but not testing if the engine starts.

SMTP Handshake as Proactive Defense

SMTP verification simulates the first real step of email delivery: the handshake. It connects to the recipient’s mail server and runs a lightweight test to see if the server will accept a message for that address. This is a proactive check—catching issues before they become bounces.

For example, a catch-all address may accept any email, but it’s often used for spam traps or low-quality leads. Greylisting can temporarily reject messages from new senders, causing soft bounces. Server-side blocks due to high volume or poor sender reputation won’t show up in syntax checks. An SMTP handshake reveals these real-world signals.

Using real-time SMTP verification cuts down on hard bounces and protects your sender reputation, a key factor in inbox placement. Email Explorer confirms that senders with strong deliverability consistently use verification tools that go beyond format checks.

If you’re managing lists at scale, don’t rely on guesswork. Test your addresses with a tool that performs a live SMTP handshake. See how it works: verify your list with MailTester—and ensure you’re sending only to accounts that actively receive mail.

How the SMTP Handshake Process Works – A Technical Walkthrough

You initiate an SMTP handshake to verify an email address by connecting to the recipient’s mail server on port 25 or 587, sending a greeting, identifying yourself with EHLO, and testing the mail transaction with MAIL FROM and RCPT TO commands. The server responds with codes: 250 for approval, 550 or 551 for rejection. This real-time test mimics how mail servers handle actual messages. It’s the most reliable signal for validity, catching bounces, role accounts, and disposable domains before you send. For deeper insight into how this works, see the official SMTP specification in RFC 5321.

Step-by-step SMTP Verification Process

1. Connect to the mail server on port 25 (standard) or 587 (authenticated). The recipient's server must be reachable. If the port is closed or blocked, the address is likely invalid.
2. Receive the server greeting with a code like 220 mx.example.com ESMTP. This confirms the server is active and ready to handle transactions.
3. Send EHLO or HELO to identify your client. HELO is older; EHLO enables modern extensions like STARTTLS and 8BITMIME. You must identify yourself correctly—some servers reject unidentifiable clients.
4. Review supported extensions in the server’s 250 reply. These include features like STARTTLS (encryption), DSN (delivery status notifications), and SIZE (message limits). Missing expected extensions may signal a weak or misconfigured server.
5. Initiate MAIL FROM command with a valid sender address. This isn’t the target email—it’s the origin of the message. The server checks if it accepts mail from that sender, often based on SPF or domain policy.
6. Wait for a 250 OK response to the MAIL FROM command. If you get a 5xx error, the sender domain is rejected—possibly due to poor reputation or misconfiguration.
7. Send RCPT TO with the target address. This is the key step: you’re testing if the recipient address is accepted by the server, not just the domain.
8. Get a response from the server. A 250 OK means the address exists and is accepted. A 550 (no such user) or 551 (user not local) means the address is invalid. A 553 (invalid mailbox name) may point to a typo or format issue.
9. Final decision on the message. If the server accepts both MAIL FROM and RCPT TO, it may accept the message. If it rejects either, the result is final: the address is not deliverable.
10. End the session with QUIT. The server closes the connection. Your verification session ends cleanly.

Why This Matters for Deliverability

Every step above tests real infrastructure. A catch-all address may survive steps 1-5 but fail at RCPT TO if it rejects specific users. Disposables and role accounts often trigger 5xx responses early. Greylisting may delay the handshake, so testing must allow for delays. The SMTP handshake is the single most accurate method to verify an address at scale—far better than regex or domain-only checks.

Tools like MailTester’s bulk verification automate this handshake across thousands of emails. You’re not just filtering out typos—you’re detecting real delivery failure points. This cuts bounce rates, protects sender reputation, and improves inbox placement. For developers, MailTester also provides a real-time verification API that integrates this process into your workflow.

What Does Each SMTP Response Code Mean in Email Verification?

Each SMTP response code tells you exactly what happened when your email verification service tried to deliver a message to a mailbox. A 250 means the address is valid and accepted. Codes starting with 5xx mean the address is permanently invalid—no retry. 4xx codes indicate temporary issues, like server overload, that may resolve later. Understanding these codes helps you clean lists accurately and improve deliverability.

Interpreting SMTP Response Codes in Real-Time Verification

When an email verification service sends a test message via SMTP, it doesn't rely on guesswork. It follows the same handshake process used by mail servers daily. The server’s responses are numeric and standardized. Knowing what each code means lets you filter invalid, risky, or temporary addresses before you send.

SMTP Response Codes at a Glance

For deeper insight into email protocols and their behavior, the Internet Engineering Task Force (IETF) provides authoritative definitions in RFC 5321, which governs SMTP. These codes are not arbitrary—they’re part of a system designed for reliability and scalability.

Real-time verification services like MailTester use these codes to deliver 98.9% accuracy. You don’t need to parse raw SMTP logs—you can rely on structured results that show exactly why an address passed or failed. The email checker gives instant feedback on a single address, while the bulk verification process applies the same logic to thousands of addresses with precision.

Why Real-Time SMTP Checks Are More Accurate Than Static Validation

Static validation only checks if an email looks right on paper—proper format, valid domain. It can’t tell if the address is actually active or blocked by the recipient’s server. Real-time SMTP checks go further: they connect directly to the mail server and simulate a real send attempt, revealing whether the mailbox accepts messages in real time. This live verification catches inactive addresses, catch-all traps, and policy-based blocks that syntax checks miss.

Static Checks Can’t See the Whole Picture

Just because an email address follows the format rules doesn’t mean it still works. Domains disable old accounts, block certain patterns, or use filters that reject messages from unfamiliar senders. Static validation tools can’t detect these server-side behaviors. They rely solely on rules like “must have an @ symbol and a domain” — a baseline, but not a guarantee of usability.

Even a well-formed address like [email protected] may have been deactivated, flagged as spam, or restricted to internal use. If it’s a role address like [email protected], it might still exist but never receive inbound mail. Static tools can’t know this. They treat every syntactically correct address as potentially valid, which leads to wasted sends and poor deliverability.

Real-Time SMTP Simulates Real Send Behavior

MailTester’s verification process uses live SMTP connections to actual mail servers. When you check an address, we don’t just look at its structure—we reach out, perform the handshake, and see if the server accepts the address as a valid recipient. This mimics what happens when you send an email from a real client.

During this exchange, the server can respond with a clear “yes” (valid), “no” (invalid), or even “temporary failure” (greylisting, delay). We analyze these responses with precision, including common patterns like “550” (email rejected) or “553” (domain doesn’t accept such addresses). This layer of active testing is what drives our 98.9% accuracy. It’s not just about checking if the address is correctly formatted — it’s about confirming that the mailbox still accepts messages.

This approach is an industry-standard practice for reliable email validation — not just a feature, but a fundamental requirement for any service that aims to reduce bounces and boost inbox placement. You can test single addresses live at our email checker, or verify large lists at scale with our bulk verification tool to see how many valid senders you’re actually reaching.

For teams using tools like Mailchimp, HubSpot, or SendGrid, integrating verification before sending helps maintain sender reputation and reduces time spent chasing dead leads. Real-time SMTP checks don’t just save money—they protect your deliverability over time.

How MailTester Implements the SMTP Handshake in Real-Time Verification

MailTester performs a real-time SMTP handshake by connecting directly to the recipient’s mail server using standard protocols. It sends only the minimal commands needed—EHLO, MAIL FROM, RCPT TO, and QUIT—without delivering a full message. Each step returns a server response code, which MailTester interprets instantly to assign a verdict: valid, invalid, catch-all, risky, or unknown.

Simulating the Full SMTP Flow for Precision

Let’s walk through the real-time process: First, MailTester sends EHLO to initiate the session. Then, it sends MAIL FROM with a fake sender address to test if the server accepts recipients. Next, it sends RCPT TO with the target address. If the server responds with a 250 code, it means the address is accepted—likely valid. A 550 or 551 response typically indicates a non-existent or rejected address. The whole process mimics a real email send but without the payload.

This full handshake is key. Many simpler tools stop after the initial connection or only check MX records. But MailTester follows the actual SMTP RFC standards—specifically RFC 5321, which defines the core protocol. This ensures accuracy, especially against servers that apply filtering or greylisting during the acceptance phase.

Because no actual message is sent, this method avoids triggering spam filters and stays within bounds of standard email validation practices. It also respects server rate limits and avoids abuse concerns. This is not a guess; it’s a direct, protocol-compliant test.

Verdicts Based on Real Server Feedback

Each response code is mapped to a specific result. A 250 means valid; a 550 (user unknown) means invalid. A 250 response to RCPT TO but a 250 or 251 response to MAIL FROM? That may indicate a catch-all setup. A 4xx code (temporary failure) often means the address is risky—possibly soft bounced or behind a greylist.

MailTester handles these nuances automatically. The result isn’t just “valid” or “invalid”—it’s a precise verdict based on how the server behaves in real time. This approach removes guesswork and works consistently across different domains, including those with aggressive filtering.

For teams that send email at scale, this level of accuracy matters. You’re not just clearing a list—you’re predicting where your messages will land. This is why MailTester offers both real-time verification via our API and bulk list verification to scan thousands of addresses in minutes.

What's the Difference Between Valid, Catch-All, Risky, and Invalid Verdicts?

When an email verification service checks an address, it doesn’t just say “yes” or “no.” It returns a verdict based on how the receiving server responds during the SMTP handshake. A Valid address means the server accepted it as real. A Catch-all means the server accepts all mail, even for non-existent users—high risk. A Risky result means the server gave a vague or incomplete response, often due to greylisting or rate limiting. An Invalid address was explicitly rejected (e.g., “550 No such user”). These labels help you decide whether to send, and when not to.

Understanding the Verdicts in Practice

Let’s break down what each verdict actually means in the real SMTP handshake process. These aren’t guesses—these are outcomes from actual server responses during a live connection attempt. You’re not just filtering bad addresses; you're understanding how mail flows at the protocol level.

These outcomes aren’t arbitrary. They reflect real email infrastructure behavior. For instance, catch-all domains violate RFC 5321's intent by allowing delivery to non-existent addresses—an open door for abuse. RFC 5321 defines the SMTP protocol, where servers should reject invalid recipients, not silently accept them. Many spam filters detect catch-all domains as a red flag.

How to Use MailTester’s Real-Time API for Bulk SMTP-Based Verification

You send a list of email addresses in a JSON payload to MailTester’s API endpoint, and it runs real-time SMTP handshakes in parallel across multiple connections—validating each address by simulating a full SMTP exchange. You get back precise verdicts: valid, invalid, catch-all, risky, or unknown—so you can clean your list and improve deliverability before sending. No guesswork, no fake checks.

Step-by-Step Process

1. Prepare your list: Gather the email addresses you want to verify. Keep the list clean and in a valid JSON format, with each address as a string in a list. This ensures the API processes it efficiently.
2. Send the request: Use the MailTester API endpoint with an HTTPS POST request. Include your API key in the headers and your email list in the body as a JSON array. The system accepts up to 100 emails per request, and larger lists can be split.
3. Run real-time SMTP handshakes: MailTester initiates parallel SMTP sessions with the destination domain's mail server. It performs each step of the handshake—HELO/EHLO, MAIL FROM, RCPT TO—as a real client would. This mimics actual send attempts and reveals true delivery status.
4. Receive verdicts instantly: Within seconds, you receive a JSON response with each address and its verdict. Valid means deliverable and active. Invalid means undeliverable (e.g., typo or non-existent). Catch-all means the domain accepts all addresses—use with caution. Risky means possible spam trap, role account, or temporary block. Unknown means no clear result.
5. Filter and act: Remove invalid, risky, and catch-all addresses from your list. Send only to valid, high-quality addresses. This reduces bounces, protects sender reputation, and improves inbox placement.

Why It Works

Unlike tools that rely on heuristic checks or outdated databases, MailTester’s approach uses actual SMTP connections. This is how major email providers like Gmail and Outlook validate addresses in real time. The process mirrors actual sending behavior as defined in RFC 5321, ensuring results are accurate and actionable.

Real-time verification across multiple connections avoids rate-limiting and reduces latency. MailTester’s system handles throttling and backpressure automatically. You get consistent results without needing to manage retries or connection pools yourself.

Use this process before sending marketing campaigns, onboarding flows, or transactional emails. It’s also integrated with Mailchimp, HubSpot, Klaviyo, and SendGrid via the integrations page. Start with 100 free verifications at MailTester.com.

What Limitations Should You Know About SMTP-Based Verification?

You can’t always trust an SMTP handshake to give a final verdict. Some servers ignore probes or delay responses intentionally, and even valid addresses may fail due to throttling or spam filters. These behaviors aren’t errors — they’re deliberate anti-abuse measures. MailTester accounts for this by combining real SMTP checks with heuristic modeling, reducing false negatives without overpromising accuracy.

Why SMTP Verification Isn't Always Final

• Some mail servers enforce greylisting — they reject the first connection attempt to filter out automated spammers, making a valid address appear invalid on a first try.
• Rate limiting can block verification attempts if too many checks come from the same IP, even for real email addresses.
• Spam filters may drop connections silently or return temporary errors (like 4xx codes) for valid addresses, especially if the sender IP has a poor reputation.
• Dynamic blocking by security providers like Spamhaus or Cloudflare can temporarily block known testing IPs, resulting in false negatives even with legitimate addresses.

How MailTester Handles the Limitations

• We use multiple retries and intelligent timing to work around greylisting and throttling. Our system respects server-side delays without breaking the connection.
• Our 98.9% accuracy includes pattern recognition and machine learning to predict validity when the SMTP handshake is inconclusive — like identifying known disposable domains or role-based addresses.
• Even with these techniques, no system can achieve 100% accuracy. Server privacy policies, encrypted mail systems, or dynamic blacklists mean some addresses remain undetectable from the outside.
• For context: the IETF’s RFC 5321 describes standard SMTP behavior, but doesn’t mandate servers to respond to verification probes. This is by design.

The goal isn’t perfection — it’s actionable insight. You need to know which addresses are likely deliverable, not just which ones fail a single test.

For example: if you're doing bulk verification before sending to customers, use our bulk verification tool to filter out high-risk addresses before your campaign runs.

Integrations That Make SMTP Verification Part of Your Workflow

You can embed real-time SMTP verification into your email stack—Mailchimp, HubSpot, Klaviyo, and SendGrid—all without manual work. Each integration checks addresses against the actual mail server behavior using the standard SMTP handshake process, ensuring only deliverable emails get sent, which lowers bounces and protects sender reputation. This isn’t just cleanup; it’s prevention built into your onboarding, campaigns, and automation flows.

Mailchimp: Clean Lists Before Every Campaign

When you connect MailTester to Mailchimp, every list import runs a full verification before your campaign launches. You’re not trusting guessed formats or outdated data—you’re sending only addresses that respond to real SMTP requests. This means lower bounce rates and better inbox placement. For marketing teams, this reduces wasted sends and protects domain reputation, especially when managing high-volume campaigns.

HubSpot: Verify Leads in Real Time During Onboarding

For sales and marketing teams using HubSpot, MailTester verifies lead email addresses the moment they fill out a form. If an address doesn’t respond to a live SMTP handshake—whether it’s misspelled, expired, or a role account—it’s flagged before it ever enters your CRM. This stops invalid data from polluting your database and reduces future deliverability issues. SMTP standards define how these checks work at the server level, and we follow them precisely.

Klaviyo & SendGrid: Pre-validate to Boost Inbox Placement

With Klaviyo and SendGrid, you can pre-validate your email lists using MailTester's API. This step happens before sending, so only verified addresses hit the pipeline. This reduces hard bounces, keeps your sender score healthy, and improves open rates. Studies from Return Path’s research show that lists cleaned regularly see better inbox placement—even when volume is high.

Each integration uses real SMTP handshakes, not just pattern matching. That means it detects catch-all domains, greylisted addresses, and temporary failures—issues that heuristic checks miss. You’re verifying against what truly happens when an email is sent. The result? Fewer bounces, fewer spam reports, cleaner data, and real deliverability improvements. See how MailTester integrates with your tools, or start with a quick email checker to confirm an address before sending.

Final Thoughts: The SMTP Handshake Is the Foundation of Trust in Email Delivery

Email verification isn’t about checking if an address follows a pattern. It’s about proving the mailbox exists and can receive messages.

The SMTP handshake is the only method that tests actual delivery capability. No proxy, no heuristic, no guesswork—just a real connection to the destination server.

Services like MailTester use authentic SMTP interactions, not simulations, to assess deliverability. This rigor ensures accuracy, reduces bounces, and protects sender reputation from the first send.

Sources

• Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

• Bounce codes and SMTP errors explained (complete guide)
• Fix 550 5.1.1 Errors: Email List Cleaning That Removes Local Part Spelling Mistakes
• Debugging SMTP Relay 550 5.7.1 Rejection Without Log Details
• Why Emails Bounce Due to From Field Invalid Character Encoding
• 550 5.7.1 SMTP Error with No Recipient or Sender Info

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does MailTester send actual emails during verification?

No. MailTester uses real SMTP handshake protocols, but never sends a full message. It stops at the RCPT TO stage to verify acceptance.

Why do some addresses come back as 'risky' when they seem valid?

Risky addresses include those that fail to respond, return ambiguous errors, or are behind greylist protection. They may still receive mail but are unreliable.

How does MailTester handle greylisting during SMTP checks?

Greylisting delays or blocks initial attempts. MailTester applies retry logic and monitors response patterns to distinguish temporary delays from real invalidity.

Can I verify 10,000 emails at once with MailTester?

Yes. MailTester supports bulk email verification with real-time API access. The system handles high-volume checks efficiently and respects server rate limits.

What’s the difference between catch-all and valid addresses?

A catch-all address accepts any email, even for non-existent users. A valid address only accepts messages for known users. Catch-alls are high-risk for deliverability.

How accurate is MailTester’s verification process?

MailTester achieves 98.9% accuracy by combining real-time SMTP handshake tests with heuristic analysis of server responses and domain reputation.

Do purchased credits ever expire?

No. Any credits you buy with MailTester never expire, so you can store them and use them when needed.

Can I test inbox placement with MailTester?

Yes. MailTester offers inbox-placement testing to evaluate how likely your emails are to land in the inbox, not spam.

Does MailTester check for disposable email domains?

Yes. The system includes disposable domain detection as part of its validation process to flag low-value or temporary addresses.

How do I get started with free verifications?

Start with 100 free verifications through the MailTester dashboard. No credit card required—just sign up and begin.