Why does email get blocked before it even arrives?

You send a perfect email — clear subject line, on-brand content, relevant to the recipient. It still vanishes into the void. No bounce, no error. Just silence. That’s not bad content. It’s a failed handshake.

Deliverability starts long before the inbox. It begins with a technical exchange called SMTP. If that exchange stumbles, your message never gets a seat at the table. Even the cleanest content fails if the handshake breaks.

Most delivery failures aren’t about spam triggers. They’re about misconfigured SPF, mismatched DKIM, or unresolved DNS. These invisible errors cause the first step in email delivery to fail — silently — before anyone sees the message.

Key takeaways

  • SMTP is the foundation of email delivery — a technical handshake that must succeed for any email to be processed.
  • Even valid content will fail if the SMTP handshake fails due to DNS misconfigurations like SPF, DKIM, or MX records.
  • Many "bounces" are not hard bounces — they're invisible failures at the handshake stage, often caused by server-level issues or poor sender reputation.

What is the SMTP handshake, and why does it matter for deliverability?

When your email leaves your server, it begins a silent, step-by-step handshake with the recipient’s server—this is the SMTP handshake. It’s not just a formality; it’s how the receiving server checks your identity, verifies your legitimacy, and decides whether to accept the message. A failed handshake means your email gets rejected, delayed, or bounced—often without a clear reason, making troubleshooting a challenge. You can avoid most of these issues by verifying email addresses before sending, which lets you catch invalid or problematic addresses early.

The Step-by-Step SMTP Handshake: How It Works

Let’s walk through what happens during the SMTP handshake. It starts with the sender’s server connecting to the recipient’s mail server on port 25 or 587. The recipient server responds with a greeting, usually something like “220 mail.example.com ESMTP ready.”

Next, your server identifies itself using the HELO or EHLO command. The recipient server checks if the domain is valid and matches DNS records. If not, it may reject the connection outright.

Then, the sender declares the origin of the message using the MAIL FROM command. This is where SPF comes in—mail servers check if your domain’s SPF record allows the sending server to send on its behalf.

After that, the recipient server confirms the target email address using the RCPT TO command. If the address doesn’t exist, the server may reject it immediately—or, if it’s a catch-all, it may accept and later reject it after content is processed.

Finally, the server says “250 OK,” and the message transfer begins. If any step fails, the connection drops. The failure might be logged, but you won’t always see it unless you’re running advanced logging or using an inbox placement tool.

Why This Matters for Deliverability

Every failed handshake is a missed opportunity. Bounces due to handshake issues are often silent, meaning you assume your email delivered—but it didn’t. A poor sender reputation due to repeated handshake failures can land you on a blocklist or trigger throttling.

That’s why pre-sending validation is critical. You’re not just checking if an address exists—you’re validating whether it’s likely to be accepted at the server level. Tools like bulk email verification or real-time email verification API can catch invalid, catch-all, or high-risk addresses before they ever touch your sending infrastructure.

The SMTP handshake is the foundation of email trust. When your server fails it, the recipient server has no reason to accept your message. By catching problems early, you avoid wasting bandwidth, maintain sender reputation, and increase the odds your message lands in the inbox—where it belongs.

Step-by-Step: The Full SMTP Handshake from Start to Finish

You’re sending an email, and behind the scenes, your server is having a strict, automated conversation with the recipient’s mail server. It starts with a TCP connection on port 25, 587, or 465, then follows a clear sequence: handshake, identity check, sender validation, recipient verification, data transfer, and cleanup. Each step is a checkpoint. If any fails, your email gets rejected or delayed. Learn each move, and you’ll spot where deliverability breaks.

  1. Open TCP connection on port 25 (unencrypted), 587 (submission), or 465 (SMTPS). This is the digital doorbell. The recipient's server must be listening. If it’s blocked by firewall or misconfigured, the handshake never starts.
  2. Server responds with 220 — “I’m ready.” This signal confirms the mail server is online and accepting connections. If you get a 4xx or 5xx error, the server is down, too busy, or rejecting you.
  3. Introduce yourself with HELO or EHLO. You must announce your domain name. This is your ID card. Without a valid domain here, the receiving server can’t validate you later.
  4. Receive 250 if accepted. The server checks if your domain is recognized. If not, you get a 5xx error — likely due to a typo or unconfigured DNS.
  5. Declare sender with MAIL FROM. You specify your envelope sender (e.g., MAIL FROM:<[email protected]>). This is not the From header in the email body — it’s technical and used for bounce handling.
  6. Validation happens here. The receiving server checks SPF records. If your IP isn’t authorized in the sender’s DNS, you get a 550 or 554 rejection. This is why SPF misconfiguration kills delivery.
  7. Declare recipients with RCPT TO. You list each email address you’re sending to. The server checks it against its user list, domain policy, or spam filters. One bad address can break the whole batch.
  8. Accept or reject each address. A 250 means “I’ll take this.” A 550 means “I don’t have this user.” Catch-alls and role accounts often respond 250 but may not deliver.
  9. Send data with DATA command. This triggers the server to start reading your full message: headers, body, attachments. You must end the data block with a period on a line by itself.
  10. Server logs and confirms with 250. Once the full message is received, it’s stored and queued. You now know delivery succeeded — at least from the server’s perspective.
  11. Close the connection with QUIT. Both servers now disconnect. All data is committed. The email is in the recipient’s pipeline.

Why This Matters for Deliverability

Every step is a potential failure point. A missing SPF, a bad domain, or a greylist delay at the EHLO stage can cause an email to drop before it even lands in the inbox. Tools like bulk email verification help you catch invalid, catch-all, or role addresses before you even attempt the handshake.

Understanding the Real-World Impact

Spam filters and receivers don’t just examine content — they audit the entire SMTP exchange. An inconsistent or delayed handshake can signal automation, abuse, or poor infrastructure. The SMTP RFC outlines these steps precisely. When your infrastructure follows them, you pass the first test.

What happens when the SMTP handshake fails?

When the SMTP handshake fails, your email never reaches the inbox—and often, you don’t get a clear reason why. The receiving server may reject the connection outright with a 5xx error, delay delivery with a 4xx code, or silently queue the message without response. In timeout cases, no error is sent back at all, leading to silent bounces that make troubleshooting nearly impossible.

Why the handshake fails

Let’s be clear: a failed SMTP handshake isn’t always about the message content. It’s usually about infrastructure trust. Your sender domain might not be verified. Or the IP address sending the email could be blacklisted—especially if it’s been used for spam before. Missing or misconfigured SPF records are a common root cause, since they prevent the recipient server from validating your sender identity.

Greylisting also plays a role. It’s an anti-spam tactic where the receiving server temporarily rejects the first connection, expecting the sender to retry later. This works well for legitimate email servers but can cause delays if the sender isn’t configured to retry. It’s not a rejection—just a delay—but it’s a frequent source of confusion.

How failures manifest

You might get a hard bounce with a 550 error—“User unknown” or “Access denied”—which is clear. But less obvious is the 4xx error, like 451 (Temporary failure) or 421 (Too many connections), which can delay delivery for hours or days. Even worse: when the connection times out (after 30–60 seconds), you get nothing back. This is a silent bounce—one of the hardest types to detect and fix.

According to the RFC 5321 specification for SMTP (the foundation of email delivery), servers are allowed to reject or delay messages based on policy without sending a response. That means you might think your email shipped, but it never reached the inbox. This is why real-time verification tools like MailTester’s email checker are critical—they catch these issues before you send.

How to test SMTP handshake success in real time

You can test SMTP handshake success in real time using tools like MxToolbox or Telnet to manually simulate the connection process, or by integrating a real-time email verification API that performs active SMTP checks alongside syntax and reputation validation. This ensures you’re not just guessing whether an email is valid—but confirming the server will actually accept it.

Manual testing with Telnet or MxToolbox

Let’s say you want to verify whether a specific email address can receive mail. You can run a manual SMTP handshake using Telnet by connecting to the recipient’s mail server on port 25 or 587. The process involves sending a series of commands—HELO, MAIL FROM, RCPT TO—and observing the server’s response codes. If the server replies with a 250 or 550 code, you know it’s reachable and has a defined behavior for that address.

Tools like MxToolbox offer a streamlined version of this. They let you test SMTP connectivity to a domain, check for open relays, and analyze the full handshake sequence without writing a single line of code. This approach is useful for troubleshooting individual domains or diagnosing deliverability issues.

Automating verification with real-time APIs

For bulk sends or automated workflows, manual testing isn’t practical. That’s where real-time verification APIs come in. These tools don’t just validate email syntax—they initiate an actual SMTP handshake with the receiving server to check if the address is active and accepted.

MailTester’s API performs active SMTP handshake checks as part of its 98.9% accurate verification process. It goes beyond basic syntax checking by probing the server to determine if the mailbox exists and is willing to receive messages. This includes testing for catch-all configurations, greylisting, and role-based addresses—factors that impact deliverability long before a message is sent.

It’s not just about catching typos. An address might pass syntax checks but still bounce due to greylisting, server-side filtering, or non-existent mailboxes. By testing the handshake in real time, you catch these issues before they damage your sender reputation.

For teams using platforms like Mailchimp, HubSpot, Klaviyo, or SendGrid, MailTester integrates directly to validate lists before every send. You can start with 100 free verifications at bulk email list verification or add real-time checks to your workflow via the verification API.

Understanding the SMTP handshake step by step isn’t just theoretical—it’s a practical step you can take today to improve inbox placement and save time. The protocol has been standardized in RFC 5321, and modern tools use it to predict real-world deliverability outcomes.

The role of DNS, SPF, DKIM, and DMARC in the SMTP handshake

During the SMTP handshake, DNS records like SPF, DKIM, and DMARC act as digital identity checks. SPF verifies the sender’s IP is authorized, DKIM confirms the message wasn’t altered, and DMARC tells receiving servers what to do if either check fails. If any of these are missing or misconfigured, your email can be rejected, marked as spam, or blocked entirely—often without a clear bounce. You can catch these issues early with a real-time email verification tool.

SPF: Authorizing the sending source

SPF (Sender Policy Framework) lives in your DNS and lists which IP addresses are allowed to send emails from your domain. When the receiving server sees your MAIL FROM address, it checks this record during the SMTP handshake. If the sending IP isn’t in the SPF list, the server may reject the email immediately.

Let’s say you send from a service like SendGrid. If SendGrid’s IP isn’t listed in your SPF record, the server flags it as unauthorized. That’s why SPF records must include all your sending sources—otherwise, even valid emails get blocked.

DKIM: Proving message integrity

DKIM adds a cryptographic signature to your email headers before sending. The receiving server verifies this signature after the SMTP handshake, using your domain’s public key stored in DNS. If the signature doesn’t match, the email failed integrity checks.

This step doesn’t affect the handshake itself but is checked right after. A missing or outdated DKIM key—often due to expired or improperly configured keys—means your emails are suspect, even if they pass SPF.

DMARC: Enforcing policy and reputation

DMARC ties SPF and DKIM together. It tells receivers what to do if either check fails—like quarantining or rejecting the message. You set DMARC policies in DNS, and receivers use them to decide whether to deliver your email.

DMARC isn’t checked during the handshake, but it influences the final decision. If a server sees multiple DMARC failures over time, it may start flagging your domain as low-reputation—leading to higher spam scores and worse inbox placement.

Together, SPF, DKIM, and DMARC form a layered defense. Missing any piece weakens your sender reputation. A single misconfigured record can break delivery across thousands of emails.

Before sending to a large list, verify that your sending setup aligns with these standards. You can test your full setup using a real delivery simulator like MailTester’s inbox placement tool, which checks not just syntax but real-world delivery behavior across major inboxes.

As the IETF’s RFC 7072 notes, proper authentication is essential for email system integrity. These records are not optional—they’re the foundation of deliverability.

MailTester’s role in preventing SMTP handshake failures

You can prevent SMTP handshake failures before they hurt deliverability by validating email addresses with real-time, active checks. MailTester’s API doesn’t just check syntax — it simulates the full handshake with the recipient’s mail server, detecting issues like greylisting, blacklisted IPs, or temporary failures that would otherwise cause bounces. When it returns “valid,” you know the address is not just structured correctly but that the server is open, responsive, and willing to accept messages.

How active SMTP checks catch what passive tools miss

Most email verification tools only validate syntax or check if an address resolves to a domain. MailTester goes further by performing a real-time SMTP handshake. It connects to the receiving mail server, sends the necessary commands (HELO, MAIL FROM, RCPT TO), and reads the response code. This catches problems that static checks can’t — like temporary rejections due to greylisting or rate-limiting, which often look like valid addresses until you try to send.

For example, if a server replies with a 4xx status code like 451 (temporary failure), MailTester flags it as “risky.” If the server blocks your IP due to reputation issues (common with shared hosting IPs), you’ll see it immediately. This prevents you from sending to addresses that appear valid on paper but won't receive your email — a major cause of poor inbox placement and degraded sender reputation.

What “valid” really means in deliverability terms

When MailTester confirms an email as “valid,” it means the server is open, the address exists, and it’s receptive. The SMTP process isn’t just passed — it’s completed cleanly with a 250 response. This isn’t just about syntax; it’s about actual receptivity. The server acknowledged the address, and the connection was not interrupted by a temporary block or policy.

This level of inspection aligns with best practices outlined in RFC 5321, the standard for SMTP communication. A real handshake validates behavior, not just formatting. Tools that skip this step miss critical signs of deliverability risk. You’re not just cleaning a list — you’re validating that the server will respond the same way when you send a real message.

Use the real-time API to integrate this validation directly into your sending workflow. Or check individual addresses with the email checker before adding them to campaigns. With a 98.9% accuracy rate, MailTester gives you confidence that the addresses you send to are not just valid — they’re ready to receive.

When you send to verified, active addresses with a confirmed SMTP handshake, your sender reputation stays clean, your bounce rate stays low, and your inbox placement improves — all because you checked the actual behavior of the mail server, not just the address syntax.

How to use MailTester to pre-verify your email list for SMTP readiness

You can pre-verify your email list for SMTP readiness by using MailTester’s bulk verification to catch invalid, catch-all, or disconnected addresses before sending. This identifies addresses that will fail the SMTP handshake—common causes of bounces, spam complaints, or sender reputation damage. Clean your list early, and avoid wasting resources on addresses that won’t reach inboxes. Let’s walk through how.

Bulk verification: find handshake failures at scale

  • Upload your email list to MailTester’s bulk verifier to check thousands of addresses at once.
  • The tool checks for valid syntax, active domains, and real mailbox presence—filtering out addresses that will fail the SMTP handshake during delivery.
  • After processing, you’ll see clear verdicts: valid, invalid, catch-all, risky, or temporary failure. Focus on invalid and risky addresses.
  • Use the downloadable report to sort by handshake failure or non-responsive MX to target the highest-risk addresses.

Real-time API integration: pre-verify during workflows

  • Integrate the MailTester API into onboarding, campaign prep, or list hygiene tools to validate addresses instantly.
  • For every new subscriber, run a real-time check—this stops invalid or temporary addresses from even entering your send queue.
  • Use the API response codes to distinguish between soft errors (like greylisting) and hard errors (like non-existent mailboxes).
  • Automate your workflow: reject or flag high-risk addresses before they impact your sender reputation.

SMTP handshake failures often stem from non-existent mailboxes, misconfigured servers, or catch-all domains—each signal a delivery risk. According to RFC 5321, the SMTP handshake is a strict sequence: HELO, MAIL FROM, RCPT TO, DATA. Any deviation can cause immediate rejection. Address hygiene prevents this.

Lists with high handshake failure rates correlate strongly with low inbox placement and increased blocklist triggers. Use MailTester to clean lists before sending—this reduces bounce rates and protects your sender reputation. The fewer failed handshakes, the better your long-term deliverability.

Start with 100 free verifications at MailTester’s pricing page. Credits never expire. Test your next list today.

Why list hygiene matters—before the handshake even begins

You can’t complete an SMTP handshake if the email address doesn’t exist, is a catch-all trap, or comes from a disposable domain. These issues trigger failures before your message even reaches the recipient’s server, wasting bandwidth, harming sender reputation, and increasing bounce rates. Clean lists aren’t just about delivery—they’re about starting on the right foot.

Invalid addresses break the handshake from the start

If an email address doesn’t exist—or was mistyped, outdated, or abandoned—the receiving server will reject it immediately during the RCPT TO phase. This isn’t a soft bounce. It’s a hard failure, logged in the SMTP session, and it counts against your sender reputation. Every invalid address you send to adds measurable risk.

Think of it like sending a letter to an apartment that doesn’t exist. The post office doesn’t open the envelope. It returns it as undeliverable. The same happens over SMTP: no handshake, no chance.

Catch-alls and disposable domains create silent risks

Catch-all addresses accept any incoming mail, even if no mailbox matches. They’re often used as spam traps, especially in old or poorly maintained lists. Accepting mail doesn’t mean it’s welcome. In fact, sending to a catch-all can mark you as a spammer, particularly if you’re not on a recipient’s whitelist.

Disposable email domains (like mailinator.com or temp-mail.org) are designed to reject incoming mail or block verification attempts entirely. They often reject SMTP connections outright as a security measure. This leads to silent bounces: no bounce message, no feedback, just a failed handshake. You never know the email didn’t arrive—and your sender reputation gets hit.

These issues aren’t about technical handshake mechanics. They’re about the foundation: your list. If the email is wrong to begin with, the handshake can’t succeed.

Let’s be honest—no amount of perfect SPF, DKIM, or DMARC will fix a list full of dead or dangerous addresses. That’s why you need verification before sending. Tools like bulk verification catch invalid, catch-all, and disposable addresses early. You’re not just checking syntax—you’re preventing failures at the first handshake step.

For a deeper look at how real-world email validation works, the SMTP RFC 5321 details the exact handshake procedure. But even with perfect compliance, flawed addresses will still fail. Clean your list first, then optimize the rest.

How MailTester’s 98.9% accuracy helps catch delivery risks early

MailTester catches delivery risks before they harm your sender reputation by combining syntax checks, domain validation, and real-time SMTP simulation. It flags invalid, catch-all, and risky addresses with 98.9% accuracy—so you’re not sending to dead ends, disposable domains, or role accounts that trigger filters. Only 1.1% of verified addresses are misclassified, meaning your list is cleaner than most tools allow.

SMTP simulation that mimics real delivery attempts

Let’s be clear: many tools check syntax or just query a DNS record. MailTester goes further. It runs an active SMTP handshake—exactly as a real email server would—by connecting to the recipient’s mail server and testing whether the address accepts mail. This isn’t a guess. It’s a live, step-by-step simulation of what happens when you send an email.

This process confirms whether an address is actually deliverable. It spots when a server accepts mail but won’t deliver it (a common sign of a catch-all setup), or when a server rejects an address outright after a real handshake. You’re not relying on heuristics or cached data. You’re seeing what happens in real email infrastructure.

Real-world precision in classifying address risk

MailTester doesn’t just say "valid" or "invalid." It distinguishes between four verdicts: valid (delivers), invalid (undeliverable), catch-all (accepts all), and risky (likely blocked or filtered). This granularity matters. Catch-alls don’t harm deliverability directly—but they inflate your bounce rate and hurt reputation if used for bulk sends. Risky addresses may be role-based (e.g., admin@), frequently monitored, or associated with disposable domains.

Because only 1.1% of addresses are misclassified (a rate lower than most industry benchmarks), you avoid the false positives and false negatives that plague lesser tools. RFC 5321 defines SMTP behavior; MailTester follows that standard, not arbitrary rules. Unlike tools that rely on outdated data or guesswork, MailTester validates in real time using actual server responses.

You can check individual addresses before sending at our email checker, verify large lists with bulk verification, or integrate delivery risk checks via our real-time verification API. Each step keeps your sender reputation intact. And since you pay in credits that never expire, you’re not wasting money on expired checks—just on accurate ones.

Final takeaway: Deliverability starts the moment the handshake begins

Most email delivery issues aren't caused by subject lines or call-to-action buttons. They stem from failures in basic protocol behavior, starting with the SMTP handshake.

A clean, properly executed SMTP handshake confirms your sender identity and infrastructure legitimacy. It’s not just a technical formality — it’s the first signal to inbox providers that your messages are trustworthy.

Prevent bounces, blocklists, and poor inbox placement by validating email addresses in real time, using active SMTP checks that confirm deliverability before you send a single message.

Sources

Keep reading

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

Frequently asked questions

What is the purpose of the SMTP handshake?

It authenticates the sender, confirms server availability, and validates the domain before message transfer.

Can an email pass spam filters but fail the SMTP handshake?

Yes. A message can pass content filters but be rejected during the SMTP handshake due to authentication or DNS issues.

Does SMTP handshake failure always cause a hard bounce?

Not necessarily. Failures may result in soft bounces, greylisting, or silent drops—especially with poorly configured servers.

How does MailTester test SMTP handshake?

It simulates the full SMTP process, including HELO, MAIL FROM, RCPT TO, and DATA commands, to validate server responsiveness.

Why does MailTester offer a 100-free-verification starter plan?

To let users test the accuracy of SMTP and validation checks without upfront cost or commitment.

Can MailTester detect if a domain uses greylisting?

Yes, its real-time verification identifies greylisted domains by observing temporary rejections during simulation.

What does 'catch-all' mean in MailTester’s results?

It means any email address on that domain will be accepted—it’s risky, often used for spam traps or abuse.

How often should I verify my email list for SMTP readiness?

At least before any major campaign or during list onboarding; monthly or quarterly hygiene checks are recommended.

Do disposable email domains pass the SMTP handshake?

Most do not. Disposable domains often reject incoming SMTP connections to prevent abuse.

Why are my emails bouncing even though the addresses look valid?

Syntax may be correct, but the server may reject the connection due to SPF, DNS, or greylisting failures—verify with active SMTP checks.

Can I integrate MailTester with SendGrid or Mailchimp?

Yes. MailTester integrates directly with SendGrid, Mailchimp, Klaviyo, and HubSpot to verify lists before sending.

Do purchased verification credits ever expire in MailTester?

No. Once purchased, credits never expire—giving you time to use them across campaigns and workflows.