Why is your SMTP server rejecting connections with a 220 TLS error due to missing SNI?

You sent a test email. The connection starts, the server replies with a 220 greeting, and then it drops. No explanation. Just a TLS handshake failure. The logs say “220 TLS error because client doesn’t include SNI.” You’re not alone.

Modern SMTP infrastructure doesn’t just verify email content. It now checks the TLS handshake in depth. If your client doesn’t send Server Name Indication (SNI), the server assumes you’re trying to connect to a domain it doesn’t recognize — or worse, a man-in-the-middle target. The result? A rejection at the TLS layer, often without telling you why.

This isn’t a bug. It’s a security hardening measure. And it’s becoming standard in hosted platforms like SendGrid, Mailgun, and AWS SES. You might not know it’s happening until your bulk sends fail with no clear error.

Key takeaways

  • Modern SMTP servers require SNI in TLS handshakes to validate the intended certificate domain
  • Missing SNI causes 220 TLS handshake failures even when the server appears to accept the connection
  • Hosted email services (SendGrid, Mailgun, AWS SES) enforce SNI checks by default, often silently dropping connections without detailed error context

What is SNI, and why does it matter for SMTP connections?

When you connect to an SMTP server over TLS, the server needs to know which domain you're trying to reach—especially if it hosts multiple domains on the same IP. SNI (Server Name Indication) is the TLS extension that tells the server this during the handshake. Without it, the server can’t choose the correct certificate, leading to a 220 TLS error and connection rejection. This isn’t just a technical quirk—it’s a security necessity.

SNI: The Missing Piece in TLS Handshakes

Modern web and email servers often host hundreds of domains on one IP address. To secure these connections, they use TLS certificates, one per domain. But during a TLS handshake, the server doesn’t know which certificate to send unless told. That’s where SNI comes in.

When you initiate a connection, your client sends the SNI field in the ClientHello message, specifying the target hostname. The server uses this to pick the right certificate. If that field is missing—common in older or misconfigured clients—your connection fails with a clear TLS error: 220, indicating the server can’t proceed.

Without SNI, the server defaults to a single certificate, usually for a placeholder or default site. This causes certificate mismatches and triggers security alerts in modern mail clients and systems. It’s not just about compatibility—it’s about preventing attackers from intercepting traffic via certificate confusion.

Why This Matters for Email Deliverability

If your email infrastructure or verification tool doesn’t include SNI when connecting to an SMTP server, you'll face silent failures. These errors aren’t always obvious. You might see vague "connection refused" messages, while the real issue is a failed TLS handshake due to missing SNI.

Industry-wide, this problem is common in legacy systems, poorly configured libraries, or custom SMTP clients. Tools built for bulk sending or email list verification must handle SNI properly to ensure real-time testing and inbox placement validation are accurate. Otherwise, you waste time chasing false negatives and risk sending to invalid or non-reachable addresses.

For automated systems, this is non-negotiable. The RFC 6066 specification explicitly defines SNI as a standard part of TLS 1.0+, and its absence is considered a configuration flaw in modern environments. You can read the full technical definition in RFC 6066.

If you're verifying large email lists or validating SMTP routes, make sure your tools and infrastructure support SNI. Otherwise, you’ll miss deliverability signals, get false bounces, and degrade sender reputation. Consider using a trusted solution like bulk email verification with proper TLS handling to avoid these pitfalls.

How does SNI impact email delivery systems using custom SMTP or scripts?

When your custom SMTP client or script connects to a modern email server, it may fail with a 220 TLS error if it doesn’t send Server Name Indication (SNI). Many older or minimal SMTP libraries, like raw socket code or outdated PHP mail functions, omit SNI by default. As a result, connections to servers using shared TLS certificates—common in cloud environments—break silently in production despite working in test setups where SNI isn’t required.

Why SNI is ignored in practice

Tools like sendmail, curl with SMTP, or custom scripts often work in lab environments because those setups don’t enforce strict TLS checks. But today’s email infrastructure—especially with providers like Google, Microsoft, and AWS—requires SNI to route the TLS handshake correctly. Without it, the server can’t determine which certificate to present, leading to handshake failure and a 220 response indicating TLS is not available.

Even OpenSSL’s s_client and telnet, commonly used for troubleshooting, do not send SNI unless you explicitly configure it. This is not a bug—it’s how TLS 1.2+ was designed. The IETF's RFC 6066 specifies SNI as an extension, but many legacy systems don’t enable it by default. You can confirm this behavior using tools like SSL Labs’ SSL Test, which shows how a connection fails when SNI is missing.

How to fix this with minimal code changes

If you’re building or maintaining an SMTP client, adding SNI is often as simple as setting the host name in the TLS context before initiating the connection. Most modern programming languages—Python, Ruby, Node.js—support this through standard library functions, but older or hand-written implementations may need manual updates.

For example, Python’s smtplib defaults to using SNI in recent versions, but older versions or bare socket clients might not include it. Similarly, PHP’s default mail() function does not support SNI, and sending via mail() without an external wrapper often results in production delivery failures with no clear error message. The issue is especially common with self-hosted delivery systems or email automation scripts that assume a basic SMTP connection will work universally.

Before pushing any code to production, test connections using tools like MXToolbox or inbox placement testing to verify if SNI is properly configured. If you're verifying large lists or testing deliverability, consider running an inbox-placement check through platforms like Emaillistchecker.io—many delivery issues go unnoticed because tools don’t detect subtle TLS failures early.

How to detect if your SMTP client is missing SNI in the TLS handshake

If your SMTP client is failing to connect with a 220 response followed by an immediate drop or a TLS alert 40, it’s likely not sending the Server Name Indication (SNI) extension during the TLS handshake. This is a common cause of connections being refused, especially on shared hosting or services with strict TLS enforcement. You can confirm this using OpenSSL’s s_client tool with the -servername flag, or by checking logs from your delivery tool for unresolved TLS handshake failures.

Test the handshake directly

  1. Run the OpenSSL s_client command with SNI: Use openssl s_client -connect example.com:587 -servername example.com, replacing example.com with your actual domain. This forces the client to include SNI in the handshake — mimicking what modern mail servers require.
  2. Observe the server’s response: If you see a 220 greeting followed by a connection drop or a TLS alert 40 (handshake failure), your client likely failed to include SNI. A successful handshake will proceed to the AUTH or STARTTLS phase.
  3. Compare with a test that omits SNI: Run the same command without the -servername flag. If the connection succeeds there but fails with it, that confirms SNI was the missing piece.

Check delivery logs and tool behavior

Many email delivery platforms now log TLS negotiation failures without exposing the underlying cause. Look in your tool’s logs for entries like “TLS handshake failed” or “connection closed unexpectedly” — these often hide SNI issues. Tools that don’t report the specific alert code (like 40) may still show this behavior when SNI is missing, especially with servers enforcing SNI via modern TLS standards.

SNI is not optional in modern email delivery. The IETF’s RFC 6066 defines SNI as an extension that enables servers to present the correct certificate for the requested domain. Modern MTAs (like Postfix or Exim) often require it, especially when hosting multiple domains on a single IP. Ignoring it leads to silent failures.

If you’re using a bulk email client or custom SMTP relay, ensure it supports SNI in TLS handshakes. Older libraries or poorly configured clients may skip it by default. This is where automated validation tools come in — they can detect misconfigurations before they impact deliverability.

If your client sends email through a third-party service, confirm it enables SNI support. Some legacy relays or scripts still use outdated or misconfigured TLS stacks that omit SNI entirely.

For teams running bulk campaigns or relying on reliable SMTP delivery, verifying your stack handles SNI correctly can prevent silent delivery failures. Tools with built-in TLS diagnostics or real-time inbox testing can surface these issues early. If you’re validating entire email lists or testing delivery reliability, bulk verification tools can help identify infrastructure-level problems affecting delivery.

Solutions for fixing the 220 TLS error caused by missing SNI

You’re seeing a 220 TLS error because your SMTP client isn’t sending the Server Name Indication (SNI) extension during the TLS handshake. This is common when connecting to modern TLS-protected mail servers that host multiple domains on a single IP. To fix it, update your SMTP library, configure SNI in your connection settings, or ensure your server configuration includes SNI in the TLS block.

Update your SMTP library or client

  • Use a modern SMTP library that includes SNI support by default—such as PHPMailer version 6.0+, or Python’s smtplib with SNI enabled via the context parameter.
  • Older versions of libraries (especially pre-2017) often lack SNI, causing TLS handshakes to fail when the server requires it. Check your library’s changelog for SNI-related updates.
  • For example, Python’s ssl.SSLContext explicitly supports SNI via the sni_hostname argument.

Configure SNI in your application or service

  • When calling TLS functions, explicitly set the SNI hostname using the -servername parameter in command-line tools, or pass it via function arguments in code.
  • If using OpenSSL directly, pass the server name via SSL_set_tlsext_hostname() or equivalent.
  • For third-party email APIs like SendGrid or Mailgun, review their TLS setup. Ensure the client you use sets SNI when connecting to their endpoints—some API clients handle this automatically; others don’t.
  • For self-hosted mail relays like Exim or Postfix, include the SNI domain in your TLS server configuration. In Exim, use tls_sni_names; in Postfix, use smtpd_tls_sni_maps and ensure it maps your domain correctly.

Missing SNI is a common but preventable cause of TLS handshake failures in modern email delivery. You can avoid these errors by ensuring your client or server explicitly advertises the intended hostname during the TLS handshake. Always verify your configuration using tools like MxToolbox or SSL Labs to test the full TLS handshake process.

For teams managing large email lists, verifying list health early—before sending—can prevent many delivery issues, including TLS-related failures. Use our bulk verification tool to identify invalid, risky, or unverified addresses before they impact deliverability.

Common tools that fail to send SNI by default

You’re likely hitting a 220 TLS error because your sending tool doesn’t include Server Name Indication (SNI) when establishing an SMTP connection. Many older or basic tools skip SNI by default, even though modern email servers require it to validate the intended TLS endpoint. Without SNI, the server may deny the connection or return a 220 error during the TLS handshake. This is especially common with legacy scripts and tools that haven’t been updated for current email security standards.

Outdated or minimal SMTP implementations

Older versions of PHP’s mail() function often lack TLS SNI support entirely, especially when used with systems that rely on the default mail implementation instead of modern mailers like PHPMailer or SwiftMailer. Let’s be clear: if you're still using raw mail() calls in PHP 5.x environments, you’re probably sending without SNI — and that’s why some providers reject your connection.

Similarly, raw socket code built without TLS SNI awareness (such as simple PHP or Python telnet-style scripts) won’t include SNI in the TLS ClientHello. These tools assume a connection goes through without specifying the server name during TLS negotiation — a practice that no longer works with properly configured mail servers.

Default settings in common CLI tools

CURL, when used with SMTP via the -u or --mail-from options, defaults to not sending SNI unless explicitly told to. You’ll need to add the -servername flag to point to the actual hostname being connected to — otherwise, OpenSSL may skip SNI entirely. This is a common oversight when automating email via CLI, especially in cron jobs or testing scripts.

Custom scripts using minimal SMTP clients — often written for internal tools or quick prototypes — frequently hardcode lower-layer communication without considering SNI. These scripts might work with older servers but fail on modern ones, especially with providers like Gmail, Office 365, or AWS SES that enforce SNI as a hard requirement.

For reference, the practice of requiring SNI in TLS is defined in RFC 6066, which outlines SNI as an extension for TLS 1.0 and higher. Industry reports from organizations like Spamhaus highlight that SNI is now a baseline for validating legitimate email infrastructure, not just a security bonus.

If you’re building or maintaining an email-sending system, it’s worth verifying that every tool in your pipeline includes SNI during TLS setup — or consider using a service like bulk verification to test delivery success before going live.

When your SMTP server refuses a connection with a 220 TLS error due to missing SNI, it's often because the recipient's mail server requires the server name indication for TLS handshakes—and your sending system isn’t including it. Email verification services like Emaillistchecker.io catch this before you send by testing the full SMTP handshake in real time, including TLS negotiation with SNI, so you avoid delivery failures before they happen.

Simulating the real delivery path

Let’s be clear: most email validation tools only check if an address is syntactically valid or if the domain exists. But real delivery fails often happen long after that—when the server refuses the connection over TLS. Emaillistchecker.io doesn’t stop at syntax. Our system simulates the entire SMTP handshake, including the TLS negotiation phase, which includes checking whether SNI is sent correctly.

During verification, we connect to the destination mail server just as your sending platform would. We test whether the server responds properly to a TLS handshake that includes the SNI extension, which is now required by many modern mail providers. This prevents you from using a list that includes addresses from servers with strict TLS policies that reject connections lacking SNI.

What this means for your sends

By catching TLS failures early—especially those caused by missing SNI—you reduce hard bounces, prevent your IP from being flagged for suspicious connection attempts, and protect your sender reputation. A single failed connection due to TLS misconfiguration can trigger blacklisting if repeated at scale.

Our 98.9% accuracy rating isn’t just about catching invalid addresses. It includes validating the actual connection logic, including TLS settings and the presence of SNI during handshake. This level of detail is rare in email verification tools.

For high-volume senders who rely on deliverability, running your list through bulk verification before sending is the simplest way to eliminate the risk of SMTP-level issues. You also get detailed feedback on each address—flagging those with server-side TLS problems or catch-all configurations that make delivery unreliable.

For developers, the real-time API lets you verify addresses at scale while catching TLS issues during sign-up or onboarding. This keeps your list clean before it ever hits your mail server.

For more context on how TLS and SNI work, you can refer to the official specification in RFC 6066, which defines the Server Name Indication extension for TLS. This isn’t just technical trivia—it’s a practical requirement for modern email delivery.

Why verifying your list before sending improves overall delivery reliability

When you send emails to a list with invalid or malformed addresses, your SMTP server often attempts a TLS handshake with every recipient. If that address doesn’t support SNI or handles the connection poorly—especially on catch-all or role-based accounts—you’ll see a 220 TLS error, even if the server is technically online. This isn’t a problem with your configuration; it’s a red flag that your list contains fragile or non-responsive endpoints. Cleaning your list beforehand avoids these failed connections, reduces strain on your sending infrastructure, and protects your sender reputation.

Invalid addresses increase handshake failure rates

Malformed or non-existent email addresses don’t respond to SMTP commands in a predictable way. During a TLS handshake, some servers return a 220 response but don’t include SNI support. In bulk sends, this creates the illusion of a failed connection, even though the server is up. The more invalid addresses in your list, the higher your rate of these TLS handshake failures—especially when you're sending to domains that enforce strict TLS policies.

Catch-all and role accounts behave unpredictably

Domains with catch-all email handlers accept all incoming messages, but often don’t support modern TLS extensions like SNI. This leads to handshake errors even if the address looks valid. Role accounts—like admin@, support@, or sales@—frequently have non-standard mail server configurations, or may silently drop connections when faced with a TLS negotiation that doesn’t match their expected behavior. These accounts don’t trigger bounce messages, so your sending infrastructure assumes delivery succeeded, when it didn’t. These silent failures degrade inbox placement over time.

That’s why sending to a clean list matters. When you use bulk email verification, you remove invalid, malformed, catch-all, and role-based addresses before they ever hit your SMTP server. This reduces the number of failed TLS handshakes, lowers your overall bounce rate, and helps maintain a healthy sender reputation. According to RFC 5246, SNI is a mandatory extension for modern TLS implementations—meaning if your list includes addresses that don't support it, the handshake will fail by design. Pre-emptive verification prevents this issue at scale.

Best practices for maintaining SMTP connection reliability

SMTP servers reject connections with a 220 TLS error when clients fail to send SNI — a critical part of modern TLS negotiation. This happens because servers now enforce SNI to prevent misrouting and ensure correct certificate matching. To avoid this, always ensure your client software includes SNI during TLS handshake setup, especially when connecting to cloud mail providers. Use tools that verify real-world TLS behavior, not just basic connectivity. A single missing SNI header can break delivery. Let’s cover how to fix and prevent it.

Test TLS behavior with real-world simulators

  • Use tools like MXToolbox or SSL Labs’ SSL Test to validate how your SMTP client behaves under actual TLS conditions.
  • Simulate connections from public IPs and common client setups — many TLS errors appear only in production environments, not in local testing.

Ensure your code uses compliant, maintained libraries

  • Drop outdated or minimal TLS libraries — especially those lacking SNI support — and use modern, actively maintained ones like OpenSSL 1.1.1+, Golang’s net/smtp, or Python’s smtplib with proper TLS configuration.
  • Validate that every email-sending stack includes SNI by default. For example, some older versions of Java’s SSLContext don’t send SNI unless explicitly configured.
  • Check your server’s TLS handshake logs. Errors like "missing SNI" or "no certificate found" confirm the client isn’t sending it.
  • Monitor logs for repeated 220 responses followed by handshake failures — these often signal client-side TLS misconfiguration, not server issues.

Pre-send validation prevents connection failures

  • Verify email addresses before sending. Use a service that performs real SMTP and TLS validation, simulating the exact path your messages will take.
  • Try bulk email verification to catch invalid, catch-all, or risky addresses before launch. This stops delivery attempts that would otherwise fail due to TLS handshake issues or blocked domains.

Summary: SNI is not optional in modern SMTP — fixing it avoids 220 TLS errors

Missing SNI during TLS handshake is a frequent reason for SMTP servers to reject connections with a 220 response indicating TLS failure. Modern servers require SNI to route the TLS handshake correctly, especially when hosting multiple domains on a single IP.

Fixing this involves ensuring your SMTP client or library supports and enables SNI—often a simple configuration update or library upgrade. Using up-to-date, well-maintained clients avoids this issue entirely.

Prior verification of email lists and testing SMTP behavior in staging environments prevent these errors before they impact delivery. Tools like Emaillistchecker.io can detect SNI and TLS compatibility issues early, reducing bounce rates and improving sender reputation.

Sources

Keep reading

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

Frequently asked questions

Does every SMTP server require SNI?

Not all, but the vast majority of modern email providers require SNI during the TLS handshake to validate the correct certificate.

Can I disable SNI to avoid issues?

No — disabling SNI reduces security, blocks connections with compliant servers, and is not recommended.

Which email services enforce SNI?

SendGrid, Amazon SES, Mailgun, Postmark, and other modern providers enforce SNI on port 587 or 465.

How can I test my SMTP client’s SNI support?

Use OpenSSL’s s_client with the -servername flag to verify the handshake completes with a valid certificate.

Can a verified email still cause SNI errors?

Yes — if the delivery system uses a misconfigured library or outdated client, verified addresses may still fail due to SNI issues.

Does Emaillistchecker.io test for SNI during verification?

Yes — our verification process includes TLS and SMTP handshake simulation, detecting connection issues including missing SNI.

Invalid or role accounts often trigger TLS failures during delivery — verifying the list first reduces such issues.

Are SNI errors the same as MX or SPF failures?

No — SNI errors are connection-level TLS issues, while MX and SPF problems affect domain routing and authentication.

Do all email clients need SNI?

No — only the sender’s SMTP client needs to send SNI to connect to the server. Recipients do not.

Can I use a proxy or relay to fix SNI issues?

A well-configured relay can handle SNI if it forwards the correct SNI name — but the source client must still support it.

Why does my script work locally but fail in production?

Local test environments often lack strict TLS enforcement — production servers enforce SNI, which may be missing in unconfigured clients.

What happens if I ignore the SNI error?

Your messages will not be delivered — the server rejects the connection before any email data is sent.