SNI in SMTP Handshake Best Practices

Why Are 220 Errors Happening During Your SMTP Handshake?

You’re sending emails through a cloud-based SMTP relay. The connection starts, the server replies with 220 — it sounds like success. But your messages never land. Why?

The 220 code means the server is ready, not that it will accept your connection. Modern mail servers hosting multiple domains on one IP often require SNI (Server Name Indication) to identify which virtual host you’re targeting. If you skip it, the server may respond with 220 and then drop the handshake — silently, without explanation.

This is especially common with shared or cloud SMTP endpoints. You’re not doing anything wrong — your credentials are correct, your TLS config looks fine. But without SNI, you’re connecting to the wrong server. The result? Failed deliveries, no clear error, and a lot of confusion.

Ensuring SNI is sent in the SMTP client handshake is a quiet but critical step. It’s not glamorous, but it’s foundational. This guide explains how, at the TCP level, to fix this issue and stop losing messages before they even leave your server.

Key takeaways

220 responses do not guarantee a successful SMTP handshake — they only mean the server is listening.
Modern mail servers using virtual hosting may drop connections if SNI is missing during TLS negotiation.
Ensuring SNI is sent in the SMTP client's TLS handshake prevents silent failures on shared or cloud-based SMTP endpoints.

What Is SNI and Why Does It Matter for SMTP?

SNI (Server Name Indication) is a TLS extension that tells an SMTP server which domain you're trying to reach during the initial handshake. Without it, the server can't select the right certificate—especially when multiple domains share one IP. Modern providers like Google, Microsoft, and AWS require SNI; failing to send it often results in a 220 error and a dropped connection.

The Technical Why: How SNI Prevents Connection Failures

When you connect to an SMTP server over TLS, the server usually hosts multiple domains on a single IP address. Without SNI, the server doesn’t know which certificate to present. It might hand out a generic or incorrect one, causing the client to reject the connection. This triggers a 220 error—essentially, “I can't serve you”—before any actual email exchange begins.

Let’s say you're sending mail through a third-party service on a shared IP. If your client doesn’t send SNI, the server might respond with a certificate for a different domain, or no certificate at all. The TLS handshake fails, and the connection drops. This isn’t just theoretical: it's a documented behavior for mail servers that enforce SNI during TLS negotiation, as outlined in RFC 6066, the official specification for SNI.

Why This Hurts Deliverability and Sending Reliability

If your SMTP client or app fails to include SNI, you’re not just getting a 220 error—you’re also increasing the chances of your messages being rejected or delayed. The error is silent, so you might think your setup is fine until reports show high bounce rates or delivery failures.

This is especially common in self-hosted or custom mail systems that use outdated or misconfigured clients. You might not realize SNI is missing unless you’re monitoring the TLS handshake closely. Tools like email verification APIs can test connectivity and flag TLS setup issues, including SNI absence, before you scale sends.

Most modern mail servers—Google’s Gmail, Microsoft’s Outlook, AWS SES, and others—require SNI to proceed with a TLS handshake. Skipping it is no longer an option. If you're building a custom sender, ensure your client library supports SNI and that it's enabled by default.

Even if your setup works with some providers, it’s unreliable. A single missing SNI header can block delivery across entire networks. The fix is straightforward: make sure your TLS/SMTP client sends SNI. If you're using a library or framework, check its TLS configuration. If you're testing, tools that simulate real client behavior can help validate the handshake.

How Does SNI Impact Email Deliverability?

Without SNI, SMTP clients can’t identify the correct TLS certificate during the handshake, even if the server responds with a 220 welcome message. This causes TLS failures, abrupt disconnects, and delivery drops — especially on enterprise mail systems that enforce strict TLS policies. You might see a 220 response followed by a "handshake failed" error, which counts as a bounce, even if the IP is not blacklisted. Tools like MxToolbox or RFC 6066 highlight this as a critical layer in modern TLS communication.

Why SNI Matters on the Server Side

Modern SMTP servers, especially those used by large organizations, rely on SNI to route TLS handshakes to the correct virtual host. If your client doesn’t send SNI, even a responsive server will reject the handshake with a cryptic disconnect. The 220 response means the server is up and listening, but the lack of SNI prevents certificate negotiation. You’re not being blocked — you’re being silently ignored during encryption setup.

This is a common root cause of connection resets during SMTP handshakes. Many enterprises use shared IPs with multiple domains, so without SNI, the server cannot determine which certificate to present. The result? A failed handshake and a bounce marked as transient, even though the domain is valid and the IP is not on any blocklist.

Impact on Bounce Rates and Sender Reputation

When SNI is missing, deliverability drops — especially for bulk sends. Enterprise domains like Google Workspace, Microsoft 365, and custom corporate mail servers often log these failures as “handshake failed” or “connection reset.” Even a 0.5% failure rate across a large list can inflate bounce rates significantly, hurting sender reputation over time.

Some verification tools catch this before you send. For example, testing your SMTP infrastructure with real-world inbox placement checks can surface these issues early. You can validate how your mail setup behaves against real MTA behavior through tools like inbox placement testing, which simulates real client behavior — including SNI compliance.

What’s the Correct Way to Send SNI in an SMTP Client Handshake?

When connecting to an SMTP server over TLS, you must include the Server Name Indication (SNI) extension in the Client Hello with the exact domain name the server expects, like smtp.example.com. This domain must match the hostname used in the HELO or EHLO command. If they don’t match, the server may reject the connection with a 220 error or fail to serve the correct certificate, breaking the handshake.

Send SNI Correctly in the TLS Handshake

Include SNI in the TLS Client Hello. During the initial TLS handshake, your client must send the SNI extension with the intended server domain (e.g., smtp.yourcompany.com). This tells the server which certificate to provide. Without it, servers with multiple domains may default to a generic or incorrect certificate, causing TLS failure.
Align SNI with the HELO/EHLO hostname. The domain you send in SNI must exactly match the value used in the HELO or EHLO command. For example, if you send EHLO mail.example.com, your SNI must also be mail.example.com. Mismatches are a common cause of 220 errors or certificate validation failures.
Use a compliant client library with SNI support. Libraries like Python’s smtplib with ssl_context or Node.js’s tls.connect handle SNI automatically when configured properly. Ensure your code explicitly sets the server name via the server_hostname parameter (in Python) or servername option (in Node.js).

Verify Your Setup Works

Test your SMTP client with a tool like MXToolbox or run a manual TLS handshake using openssl s_client. For example:

openssl s_client -connect smtp.example.com:587 -starttls smtp -servername smtp.example.com

This command verifies whether SNI is sent and whether the server responds with the expected certificate. It’s an industry-standard method to diagnose handshake issues.

SNI is defined in RFC 6066. It’s not optional in modern TLS; servers expect it, especially when hosting multiple domains on the same IP. Ignoring it is a setup error that directly leads to 220 or TLS handshake failures.

Once your client sends SNI correctly, you can focus on other delivery aspects like sender reputation and DNS records. For bulk email validation, ensure your email list has no invalid or outdated addresses. You can check your list’s health with bulk verification to avoid sending to addresses that would fail at the handshake level.

How to Verify SNI Is Sent Using Real Tools

You can confirm SNI is sent during an SMTP TLS handshake by using OpenSSL to simulate a connection and inspect the handshake details. Run the command with the -servername flag set to the expected domain; if SNI is correctly sent, the certificate presented will match that domain. If SNI is omitted, you may see a generic or mismatched certificate, leading to connection failures or 220 errors from servers that enforce SNI validation.

Step-by-Step SNI Verification Process

Run the OpenSSL test command: Use openssl s_client -connect smtp.example.com:587 -starttls smtp -servername smtp.example.com. This forces the SMTP client to initiate a TLS handshake and sends the Server Name Indication (SNI) field.
Look for the SNI value in output: After the connection begins, check the log for a line that says Server name: smtp.example.com. This confirms your client sent SNI correctly.
Verify the server certificate domain: Find the Server certificate block. The certificate’s Common Name (CN) or Subject Alternative Name (SAN) should match your specified domain. A mismatch or a certificate for a different domain suggests SNI isn’t being sent or is misconfigured.
Compare with a failed case: Repeat the test without the -servername flag. If SNI is missing, the server may return a default or outdated certificate, or drop the connection silently — a key indicator of misconfiguration.
Check for 220 errors in logs: If the server returns a 220 code only when SNI is missing, it may be rejecting connections due to lack of SNI enforcement, which is common on modern email infrastructure.

When SNI Fails, What Happens?

Many email servers today require SNI to properly validate the connection. Without it, a server may return a generic certificate — one issued to a different site, sometimes even a CA test certificate. This leads to TLS errors or connection drops before any SMTP commands are sent. According to the IETF RFC 6066, SNI is a standard extension to TLS that enables accurate certificate matching during handshakes, and its absence is increasingly treated as a protocol misstep.

The 5 steps described in “Step-by-Step SNI Verification Process”, in order.

For developers and operations teams, verifying SNI is a critical step in diagnosing SMTP delivery issues. Tools like OpenSSL are freely available and widely used in production environments for such low-level debugging. If automation is needed, consider integrating SNI verification into your email delivery pipeline. You can test your list’s domain integrity at scale with bulk verification tools that help catch delivery risks before you send.

Common Causes of Missing SNI in SMTP Clients

Missing SNI during SMTP handshake often results in 220 errors because servers reject TLS connections without a hostname. This happens when clients use outdated libraries, skip DNS resolution, or when third-party gateways drop SNI during relay. Let’s break down the real culprits you need to check.

Outdated or minimal SMTP libraries

You’re using an SMTP library from 2015 or earlier that doesn’t expose TLS SNI configuration. These libraries often default to sending no SNI, causing TLS handshake failures on modern mail servers.
Libraries like older versions of OpenSSL or minimal SMTP clients (e.g., some basic Python smtplib wrappers) don’t allow SNI override, leaving TLS negotiation to fail when the server requires it to validate the connection.
Upgrade to modern, actively maintained libraries—such as Python’s aiosmtpd or Go’s net/smtp—that support SNI during the TLS handshake. This is a necessary step for reliable delivery.

Hardcoded or misordered connection logic

Code that skips DNS resolution before initiating TLS forces the library to connect by IP alone, which means no hostname is available to pass as SNI.
It’s common to see this in hard-coded connection strings or in tools that directly use server IPs without resolving the host first. This bypasses the SNI field entirely.
Always resolve the domain name before calling STARTTLS. Use gethostbyname or equivalent to ensure the target host is known before TLS negotiation begins, as outlined in RFC 5246, Section 7.4.1.2.

Third-party SMTP gateways dropping SNI

When using services like Amazon SES, SendGrid, or Mailgun, some relay configurations don't pass the SNI value through from the original client to the final mail server.
This usually occurs in multi-hop setups where the gateway terminates TLS locally and reconnects using its own IP, effectively stripping the SNI field.
Check your gateway’s logging or documentation—some support SNI forwarding; others don’t. If you're sending in bulk, test with a tool like inbox placement testing to confirm the full delivery path maintains SNI integrity.

You can avoid 220 errors caused by missing or misconfigured SNI in SMTP handshakes by validating email addresses and domains before sending. Email verification services like Emaillistchecker.io check for TLS readiness and flag domains that reject connections due to SNI mismatches, preventing delivery failures before they happen.

Bulk Verification Flags Problematic Domains Early

When you send mail to a large list, a single domain with an SNI-ignored server can trigger multiple 220 errors and hurt your sender reputation. Emaillistchecker.io’s bulk verification service proactively identifies domains with known TLS handshake quirks, including those that require or reject SNI. This lets you prune invalid or unreliable addresses before you send, reducing bounce rates and improving inbox placement.

Domains hosted on older or misconfigured mail servers often reject SMTP connections if the SNI value doesn’t match the target hostname. These issues aren’t always visible in a simple syntax check—they only surface during actual TLS negotiation. Emaillistchecker.io detects these edge cases by simulating real SMTP handshakes during verification.

Real-Time API Checks Server Readiness

For automated workflows, the real-time API at Emaillistchecker.io’s API validates individual email addresses and tests domain-level reachability, including basic TLS handshake readiness. This includes confirming whether the server responds correctly to a connection request with proper SNI support.

While SNI is mandatory for modern TLS handshakes (as defined in RFC 6066), not all servers enforce it correctly. Some reject connections where SNI is missing or mismatched—leading to 220 or 421 errors. By using the API, you test for these conditions in real time, catching failures before they impact deliverability.

When a domain fails a handshake during verification, the service returns a clear “risky” or “invalid” status. This allows you to flag or remove addresses hosted on sensitive systems that might break the connection even if the email address is syntactically valid.

It’s not just about syntax. A valid address on a server that doesn’t handle SNI properly will still fail to deliver. Verification services that go beyond basic format checking—like Emaillistchecker.io—help you catch these issues before they hurt your sender score, blocklist status, or engagement metrics.

How to Test Sendability and TLS Readiness Before Scaling Send Volume

You can’t trust a 220 response alone—many servers advertise TLS readiness but fail the actual handshake. Use inbox-placement testing with real SMTP interactions to verify that your outbound emails complete the full TLS handshake, including SNI, and land in the inbox, not the spam filter. This exposes hidden issues like missing SNI that standard SMTP checks miss.

Simulate Real Delivery Conditions to Catch Hidden Failures

Testing your email setup with a service like inbox-placement testing gives you visibility into how your messages behave under real-world conditions. It doesn’t just confirm a 220 greeting—it runs the full SMTP transaction, including TLS negotiation, to detect whether SNI is sent and properly handled.

Many servers respond to a 220 without enforcing SNI, but fail the connection if the client doesn’t include it. This causes delivery to silently drop—especially with cloud-based mail gateways—without an error message. Inbox-placement testing exposes these failures before they impact your deliverability or reputation.

Spot Issues That Static Tools Miss

Even if your IP is not on a blocklist, SNI misconfiguration can prevent delivery. This is common with misconfigured or outdated mail relays. Using bulk verification with inbox-placement testing lets you validate the entire flow—authentication, TLS negotiation, SNI, and final inbox delivery—across a real-world sample of domains.

For example, a server may not return a 5xx error when SNI is missing, but it will drop the connection after the TLS handshake fails. This is why passive checks aren’t enough. The SNI extension is defined in RFC 6066, but not all clients and servers fully implement it correctly. Testing ensures your SMTP client follows all expected behaviors, not just the minimal handshake.

Let’s say your campaign lands in spam or fails outright in some regions. A static SMTP checker might still say “everything is OK,” but inbox-placement testing shows exactly where the handshake breaks—especially if the server requires SNI and your client doesn’t send it.

What to Do When You Suspect SNI is the Root Cause of 220 Errors

If your SMTP client receives a 220 greeting but then fails during the TLS handshake with errors like “handshake failed” or “no certificate provided,” SNI (Server Name Indication) is likely not being sent or is mismatched. The server responds with a 220 code but rejects the connection when it expects a valid SNI extension. This commonly happens when the client uses a generic hostname or sends the wrong domain in the TLS Client Hello.

Verify and Validate SNI Behavior in Your Connection

Check your SMTP server logs for explicit failure messages like “handshake failed” or “no certificate provided” occurring right after the 220 response — this is a strong indicator of a missing or incorrect SNI.
Use tools like SSL Labs’ SSL Test to inspect how your connection behaves from the outside: it will show whether SNI is sent and whether the server responds correctly.
Ensure the hostname you send in the EHLO or HELO command matches exactly the domain name in the TLS Client Hello’s SNI field — mismatches trigger rejection even if the certificate is valid.
Use RFC 6066 as a reference: SNI is a required extension when connecting to servers hosting multiple domains on one IP, and its absence can break TLS negotiation.

Reconfigure Your Client to Send SNI Correctly

Update your client library (e.g., Python’s smtplib, Node.js’s tls module) to explicitly enable and set the SNI extension using the correct target domain — not a placeholder like “localhost” or a default IP.
In Python, for example, use the context.set_servername_callback() or ensure the hostname parameter is passed to ssl.create_default_context().
Test the change with a real SMTP endpoint using tools like OpenSSL: openssl s_client -connect smtp.example.com:587 -servername smtp.example.com — verify it shows the server’s certificate and proceeds past the handshake.
If you're building or maintaining an email delivery system, validate SNI behavior across all endpoints and deployment environments — misconfigurations are common in containerized or load-balanced setups.

Fixing SNI issues isn’t just about code change — it’s about aligning client behavior with how modern mail servers expect connections. For teams managing large lists or automated sends, proactive validation helps avoid undeliverable messages and reduces the risk of being marked as unreliable. If you’re checking the health of your sender infrastructure, bulk email verification can help identify invalid or misrouted addresses that may also contribute to delivery failures.

Best Practices for Maintaining a Reliable SMTP Client

You must send SNI during every TLS handshake, even if older systems accept connections without it. Using domain-specific hostnames in EHLO/HELO (not localhost) prevents rejection by modern mail servers. Regularly test your SMTP endpoints with tools that validate TLS in real-world conditions to catch issues before they break deliveries. This combination reduces 220 errors and ensures alignment with current email infrastructure standards.

Core Checklist for SMTP Client Reliability

Always include SNI in the TLS ClientHello handshake—this isn't optional for modern security, and many receiving servers now enforce it regardless of protocol version.
Use a fully qualified domain name (FQDN) in EHLO/HELO, like mail.yourcompany.com, not generic values such as localhost or smtp.example.com—this helps receivers verify your identity and reduces filtering risk.
Validate your server’s TLS configuration with real-world testing tools like Qualys SSL Labs or MXToolbox, which simulate how actual mail servers evaluate connections and certificates.
Monitor and replace outdated or misconfigured certificates—expired, self-signed, or mismatched certs are common causes of 220-level connection failures.
Ensure your client doesn’t fall back to unencrypted connections when TLS fails; enforce TLS for all outbound traffic to avoid downgrade attacks and rejected deliveries.

Testing and Monitoring in Practice

Let’s say you've fixed your SNI and EHLO setup. The next step is testing under realistic conditions. Use services that perform end-to-end SMTP checks with modern TLS validation—don’t rely solely on local debugging. Tools that simulate real-world email routing can detect misconfigurations you're unlikely to catch in development.

For teams managing large email lists, automated verification helps catch invalid or poorly configured domains early. You can validate your entire list for correctness, deliverability risk, and common SMTP missteps before sending. Bulk verification gives you a clear picture of what’s working and what’s not—no guesswork.

Conclusion: Fixing 220 Errors Starts With SNI

220 errors indicate a failure after the server’s initial welcome message, not during it. They often point to a TLS handshake issue, not a misconfigured server.

The most common cause is missing SNI in the client’s TLS handshake, especially when connecting to mail servers with strict security policies. Without SNI, servers cannot determine which certificate to present, causing the connection to fail.

Prevent these issues by ensuring your SMTP client includes SNI in the handshake and validating domain reachability in advance. Tools like Emaillistchecker.io help confirm email validity and server readiness before sending.

Keep reading

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

Frequently asked questions

What does SMTP 220 mean when sending an email?

A 220 response means the server is ready to accept a connection. However, it does not guarantee the handshake will succeed — especially if SNI is missing during TLS negotiation.

Why does my SMTP server return 220 but then drop the connection?

This often occurs when SNI is not sent during the TLS handshake. Modern servers reject connections if the hostname isn’t provided, leading to a silent disconnect after 220.

Can I send SMTP without SNI?

Technically yes, but only if the server doesn’t use virtual hosting or TLS with multiple certificates. Most production mail servers today require SNI.

How do I test if SNI is being sent correctly?

Use OpenSSL with the -servername flag: `openssl s_client -connect domain:port -servername domain`. Check for SNI value in output and certificate match.

Yes — its inbox-placement tests simulate real delivery and surface issues like TLS handshake failures, including those caused by missing SNI.

What’s the difference between SNI and TLS?

TLS secures the connection. SNI is a TLS extension that tells the server which certificate to present during the handshake. SNI is required when multiple domains share one IP.

Do all email sending services handle SNI automatically?

No — some services or libraries skip SNI if not explicitly configured. Always verify SNI is sent, especially when sending to enterprise or cloud-hosted domains.

How can I fix a missing SNI in my Python SMTP client?

Use `ssl_context = ssl.create_default_context()` and pass the server name to `starttls()` or `connect()` to ensure SNI is included.

Are 220 errors a sign of a blacklisted IP?

No — a 220 response indicates the server is reachable. Blacklisted IPs typically return a 4xx or 5xx error or block connection entirely.

Can I rely on DNS queries to avoid 220 issues?

No — DNS only resolves addresses. It doesn’t verify TLS behavior. You must test the actual SMTP/TLS handshake with tools or verification services.

What are common SMTP libraries that support SNI?

Python’s smtplib with SSL context, Node.js tls.connect, and Go’s net/smtp with custom tls.Config all support SNI configuration.

How often should I test my SMTP setup for SNI issues?

Test every time you update your SMTP stack, add a new domain, or encounter high bounce rates. Use Emaillistchecker.io to run periodic inbox-placement checks.