SMTP 220 TLS Fails but 221 Disconnects

Why does SMTP 220 TLS negotiation fail but 221 disconnect still occur?

You send an email, the server greets you with a 220—ready to accept your message—but then the connection drops before encryption starts. You see a 221 reply, meaning the server closed the session. Why does this happen if the server confirmed it was ready?

This pattern isn't a random glitch. It reveals a breakdown in the TLS handshake—specifically, a mismatch in cryptographic protocols or a failed cipher negotiation. The 220 says “I'm here,” the 221 says “I'm leaving,” but the real issue sits in the middle: the encryption exchange never completed.

Understanding this sequence matters because it points directly to configuration problems. Ignoring it means you’re sending emails to servers that will reject you without explanation. Fixing it improves deliverability—especially when you're building or managing a high-volume email system.

Key takeaways

A 220 response confirms the SMTP server is ready, but TLS negotiation failing before encryption is established indicates a cryptographic mismatch.
The 221 response means the server terminated the session after the handshake failed—this is normal behavior, not an error in itself.
Common root causes include outdated TLS versions on the sender side, unsupported cipher suites, or strict security policies on the receiving server.

What happens during the SMTP 220–221 exchange with TLS failure?

When an SMTP server responds with 220, it confirms it’s ready for a new connection. If TLS negotiation fails—due to expired certs, unsupported ciphers, or network interference—the server rejects the encrypted handshake and responds with 221 to close the session. This sequence reveals that the server was reachable and operational, but the encryption layer failed before any message data could be sent.

Server sends 220: "Ready for new connection" The SMTP server confirms it’s listening and accepting new connections. This is a baseline indicator of service availability—not proof of deliverability or valid mailboxes, just that the server is up and responding.
Client initiates STARTTLS or implicit TLS The client signals its intent to encrypt the session. In explicit mode (STARTTLS), this is a command. In implicit mode (common on port 465), the client assumes encryption is required from the start. This step is essential for modern email security.
Server confirms and begins TLS handshake If the server supports TLS, it responds with 220 again (if explicit) or proceeds to begin the handshake. The server sends its certificate and starts negotiating cipher suites. This exchange is defined in RFC 3207, the standard for SMTP over TLS.
Negotiation fails due to configuration or network issues Common causes include expired or misconfigured server certificates, mismatched or disabled cipher suites, or interference from proxies, firewalls, or man-in-the-middle attacks. The failure occurs during the handshake, not after data transfer.
Server sends 221: "Closing connection" After TLS negotiation fails, the server terminates the session with a 221 reply. This is not a rejection of the email address—it means the secure channel couldn’t be established, and the connection is dropped before any mail data is exchanged.

Why this matters for deliverability

Seeing a 220–221 sequence with TLS failure doesn’t mean the email address is invalid. It means the mail server was reachable but couldn’t complete encryption. This doesn't block the message from being delivered later if the connection eventually succeeds—though in practice, many systems reject such attempts outright.

For email senders, this can point to infrastructure issues rather than list quality. A failing TLS handshake might appear in logs across multiple domains, indicating a misconfigured outbound relay. Or, it may signal that a recipient’s server is using outdated certificate practices.

Even if the SMTP server accepts the connection, a TLS failure prevents message transmission. It’s not an address problem—it’s a transport problem.

How to test and prevent this

Use inbox placement testing tools to simulate real-world delivery attempts from multiple regions and carriers. These tests catch TLS failure early, before campaigns launch. For list hygiene, tools like inbox placement testing can help assess whether domains in your list are consistently failing at the TLS handshake stage.

Common causes of failed TLS negotiation in SMTP

SMTP 220 TLS negotiation fails but 221 disconnect occurs because the sending system and receiving server can’t agree on a secure connection. Common root causes include outdated TLS versions, expired or misconfigured certificates, firewalls blocking the handshake, rejected weak cipher suites, or untrusted certificate chains. These issues break the TLS handshake before encryption begins, causing the server to close the connection after 221.

Outdated or unsupported TLS versions

Older systems still using TLS 1.0 or 1.1 will fail with modern servers that require TLS 1.2 or higher. The IETF deprecated TLS 1.0 and 1.1 in 2021, and most email providers now reject connections using them RFC 8996.
Check your mail server’s configuration to ensure it supports only TLS 1.2 or newer. Many older email clients or scripts still default to outdated protocols unless explicitly updated.

Certificate or chain issues

Expired or self-signed certificates trigger TLS handshake failure. Even if the certificate is valid, a broken chain (missing intermediate CA) can result in a rejected connection.
Firewalls, proxies, or load balancers in corporate environments can interfere with the TLS handshake, especially if they perform SSL interception without proper trust setup.
Some servers block connections using weak cipher suites (like RC4 or 3DES). Ensure your server uses modern, secure cipher suites like ECDHE-RSA-AES256-GCM-SHA512.
Untrusted or mismatched certificate chains — where the server presents a certificate not issued by a widely recognized CA — lead to connection rejection before the 221 disconnect.

These failures are often silent from the sender’s perspective, showing only a 220 greeting followed by a 221 close. To detect them early, validate your email list’s endpoints with real-time verification tools that simulate the full SMTP and TLS handshake. Use our verification API to test deliverability readiness and catch TLS misconfigurations before sending to real users.

How do TLS failures impact email deliverability?

Failed TLS negotiations drop the connection before email transmission can start, often causing soft bounces. Repeated TLS handshake failures signal unreliable infrastructure to recipients like Gmail or Microsoft 365, which may reduce sender reputation or trigger automatic blocking. You can’t deliver if the handshake fails — even if your email content is perfect.

Immediate impact: soft bounces and dropped delivery

When a mail server responds with 220 (ready) but then refuses the TLS upgrade with a 221 disconnect, the receiving server has technically completed the initial handshake but refuses to proceed with encryption. This usually results in a soft bounce — temporary delivery failure, not permanent. The sender may not get a clear error code, making troubleshooting difficult.

Even if the message eventually reaches the inbox, repeated connection drops signal instability. Some providers track session anomalies over time. If a sending IP shows frequent TLS negotiation failures, they may interpret this as a sign of poor infrastructure or potential compromise, leading to reduced deliverability.

Reputation systems react to repeated anomalies

Systems like Barracuda’s Reputation Service or Return Path’s monitoring tools look beyond spam scoring. They analyze connection behavior: handshake success rates, session duration, retry frequency. Consistently failing TLS handshakes across multiple domains are flagged as suspicious — like a misconfigured server, DDoS probe, or misused infrastructure.

Repeated TLS failures, especially across multiple sending sessions, can degrade sender reputation. Major providers such as Gmail and Microsoft 365 use these signals in combination with sender history, feedback loops, and spam reports. Over time, a sender with persistent handshake issues may be rate-limited, delayed, or outright blocked, especially if the issue spans many recipients.

Let’s say your list has just a few addresses that trigger TLS 220 → 221 drops — if your system ignores these, they’ll grow over time. That’s why verifying email addresses before sending is critical. Bulk email verification can catch invalid, disposable, or misconfigured domains early — reducing connection failures and improving overall deliverability.

For more context, the RFC 5246 (TLS 1.2) defines the handshake process and requirements, ensuring both parties agree on encryption parameters. If a server doesn’t support modern TLS versions or misconfigures certificates, the handshake will fail. Always test your setup using tools such as MXToolbox or DigiCert’s SSL checker to ensure your server aligns with current standards.

Why does SMTP 220 appear even after TLS failure?

The 220 greeting code means the SMTP server is ready and accepting connections—it doesn’t mean TLS encryption was successful. The server responds with 220 at the start of the session, then waits for the client to explicitly request encryption using the STARTTLS command. If the client sends STARTTLS but the server can’t negotiate TLS (due to misconfigured certificates, outdated protocols, or network issues), the connection fails after the 220, not before. This behavior is normal and expected in SMTP design. The 220 only confirms the server is online, not that encryption will succeed.

SMTP 220 is a service readiness signal, not a security guarantee

When you connect to an SMTP server, the first message you receive—usually 220—is the server saying, “I’m listening.” This is purely a status indicator, not a security handshake. It appears regardless of whether the server supports TLS, or how well it implements it. The actual encryption phase begins only when the client sends STARTTLS, after which the server must respond with 220 again, or an error if it can’t proceed.

Let’s say your email client tries to connect and the server returns 220, but then the TLS negotiation fails. The 220 was valid at the time—it just doesn’t reflect what happens after. The server is still up. It’s just that the handshake failed because the client and server couldn’t agree on a cipher suite, a certificate wasn’t trusted, or the connection was dropped mid-transaction. This is why you see 220 followed by 221 (a server-side disconnect) after TLS fails.

Why this behavior is standard in SMTP architecture

SMTP was designed with backward compatibility in mind. Servers don’t enforce TLS unless the client asks. This allows older clients to connect without requiring encryption. The RFC 3207 specification for STARTTLS explicitly describes this two-stage flow: the server advertises support for TLS after accepting the connection, but doesn’t require it until it’s requested.

This design has trade-offs. It means a server can accept a connection and later reject the encryption request—common during misconfigurations or when a certificate is expired or self-signed. But it also means the 220 code isn’t tied to encryption success. You should never assume a 220 means your connection is secure. It means the server is reachable and responding.

If you're troubleshooting email deliverability, understanding this sequence helps isolate problems. A 220 followed by a 221 disconnect with TLS failure means the server is online but can't fulfill the encryption request—possibly due to a certificate issue. You can use tools like bulk email verification to test lists and catch malformed or non-responsive domains before sending. This reduces the risk of sending to servers that will drop the connection after 220, without ever completing the secure handshake.

How to detect and diagnose SMTP TLS handshake issues in production

You’ll catch SMTP 220 TLS negotiation fails followed by 221 disconnects by enabling detailed SMTP debug logs, capturing the exact server response sequence, and verifying the TLS handshake with manual tests using Telnet or OpenSSL. Once you have the raw data, check certificate validity and cipher suite compatibility using tools like ssllabs.com or OpenSSL, and monitor for repeated disconnections from specific IPs or domains over time to pinpoint misconfigurations or network issues.

Step-by-step diagnostic checklist

Enable full SMTP debug logging on your mail server or sending infrastructure to capture the exact 220 and 221 responses in sequence during transmission.
Use Telnet to manually connect to the target SMTP server and manually issue the STARTTLS command—watch the response: if the server replies with 220 but promptly sends 221 afterward, TLS negotiation failed, and the connection dropped.
Verify certificate validity and chain integrity using openssl s_client -connect example.com:587 -starttls smtp or test via SSL Labs’ SSL Test—a mismatched or expired certificate will break handshake attempts.
Check cipher suite compatibility: older or restrictive servers may not support modern TLS 1.2 or 1.3 suites—use OpenSSL to list supported ciphers and align with your sender’s TLS configuration.
Monitor your email delivery logs over time and flag repeated 221 disconnects from the same remote IP or domain—this often indicates a misconfigured or rate-limited receiver server.
Correlate with receiver-side logs (if accessible) to distinguish between sender-side issues and recipient server behavior—some servers drop SMTP connections immediately upon TLS failure for security reasons.

When to suspect deliverability or infrastructure problems

If the same 220–221 pattern repeats across multiple domains or with consistent timeouts, your sending IP may be blocked or rate-limited by the receiving server’s reputation system. Check your IP's reputation via Spamhaus or MXToolbox's blocklist lookup tool.

For large-scale sending operations, use real-time verification tools to preemptively catch invalid or problematic email addresses that may trigger repeated connection failures. You can test entire lists using bulk verification tools that screen for deliverability risks—including SMTP handshake readiness:

Run a bulk verification check to surface risky or misconfigured domains before sending.

What are the most common TLS configurations that fail?

SMTP 220 TLS negotiation fails but 221 disconnect occurs most often due to outdated protocols, invalid certificates, or broken trust chains. TLS 1.0 and 1.1 are deprecated and blocked by modern email providers. Self-signed or expired certificates cause immediate rejection. Weak cipher suites like RC4 or DES are now considered insecure and rejected. Missing intermediate certificates prevent trust validation, even if the root is valid. These issues appear as handshake failures during the initial connection phase, leading to connection drop.

TLS 1.0 and 1.1 are no longer acceptable

Despite being phased out since 2020, some legacy systems still try to negotiate with TLS 1.0 or 1.1. Major email providers and security standards like PCI DSS and NIST no longer allow these versions. You're not being strict — you're complying with industry norms. If your system or service defaults to them, it’s a security risk and will fail in real-world email delivery. Check your SMTP setup to ensure it only supports TLS 1.2 or higher, as defined in RFC 8996.

Certificate chain issues prevent trust

Even a valid certificate fails if the chain is incomplete. A missing intermediate certificate breaks the chain of trust, which email servers verify rigorously. You might have a valid root and leaf certificate, but without the proper intermediates in the handshake, the server assumes you’re malicious or misconfigured. This leads to the 220 TLS handshake failing while still accepting a 221 disconnect. Tools like bulk email verification can help detect these issues across large recipient lists before they impact deliverability.

Similarly, self-signed certificates are never trusted by default. Even if they’re technically valid, mail servers will reject the connection during TLS negotiation because they’re not issued by a public Certificate Authority (CA). Same for expired certificates — no matter how well-configured, a certificate past its validity window is ignored.

Finally, cipher suites that were once common — like RC4 or DES — are now considered insecure and are disabled by default in modern TLS stacks. If your server only allows those ciphers, the negotiation will fail. Use strong, modern cipher suites like ECDHE-RSA-AES256-GCM-SHA512. You don’t need to memorize them — just ensure your stack disables all known weak options.

These configuration issues aren’t rare. They’re foundational to email security. Fixing them early — before sending — avoids bounce rates, inbox placement failures, and reputational damage. A well-configured server with valid, up-to-date certificates and supported ciphers should pass the 220 TLS handshake and proceed to authentication.

How can you fix SMTP TLS negotiation issues before they hurt deliverability?

SMTP 220 TLS negotiation fails but 221 disconnect occurs? The root cause is usually outdated encryption, invalid or missing certificates, chain validation failures, or network devices interfering with TLS handshakes. Fixing these ensures your messages reach inboxes, not rejections. Let’s walk through the key steps to address them directly.

Verify and upgrade your TLS configuration

Enforce TLS 1.2 or higher on your sending infrastructure. Older protocols like TLS 1.0 or 1.1 are deprecated and often blocked by modern mail providers. Use your email service’s settings or SMTP server config to disable older versions. According to IANA’s TLS registry, TLS 1.2 is now the minimum standard for secure communication.
Use a valid SSL certificate from a trusted Certificate Authority. Self-signed or expired certificates trigger handshake failures. Purchase and install one from a recognized CA like Let's Encrypt, DigiCert, or Sectigo. This is not optional if you want consistent inbox placement.
Ensure full certificate chain validation is enabled. Missing intermediate certificates break trust chains. Test this with OpenSSL: openssl s_client -connect example.com:587 -starttls smtp. A successful connection confirms the chain is intact and trusted.

Inspect your network path for interference

Check for misconfigured load balancers, proxies, or firewalls. These can strip SSL/TLS headers, modify traffic, or drop encrypted sessions. Use tools like MXToolbox to test your server’s connectivity from multiple global points.
Verify no middleboxes enforce outdated policies. Some security appliances still block TLS renegotiation or misinterpret certificate expiry. Review logs from your network stack to identify unexpected session terminations or handshake resets.
Test your SMTP server from multiple locations. A failure in one region might indicate local network interference—test via third-party services like Letter to the Net to confirm global consistency.

These steps prevent SMTP 220/221 errors that harm sender reputation. Messages that fail TLS handshake are often rejected without a bounce. Regular testing, especially before sending campaigns, protects deliverability. Use a real-time verification tool like our API to clean your list and validate domain infrastructure at scale before mass sending.

Can a real-time email verification tool help prevent SMTP 220/TLS failure issues?

Yes — but not by fixing TLS negotiation itself. Email verification tools like EmailListChecker.io don’t test SMTP handshakes or TLS sessions. Instead, they filter out invalid, non-existent, or inactive addresses before you send. By ensuring only valid email addresses remain in your list, you avoid pointless connection attempts altogether, reducing the chances of encountering a 220/TLS failure due to a bad target.

What verification tools actually do — and don’t do

When your server receives a 220 response, it means the SMTP server is listening, but that doesn’t guarantee the address is valid. A 221 disconnect afterward often signals the target doesn’t exist or rejects connections. Email verification tools don’t simulate full SMTP sessions. They don’t check TLS handshake success, server certificates, or encryption protocols. Tools like EmailListChecker.io instead analyze patterns, domain health, and mailbox existence using a combination of real-time checks and historical data.

What they do reliably is identify addresses that are permanently invalid, catch-all domains, role-based accounts (like admin@ or sales@), or disposable email addresses. These are common sources of connection-level failures. If you’re sending to a non-existent address, no amount of TLS negotiation will help — the server will just hang or drop the connection after the 220 greeting.

How clean lists reduce SMTP connection issues

Let’s say you send 10,000 emails. If 500 are invalid, your system will still attempt to establish an SMTP session with each — even if only 10% of those are on servers with poor TLS configurations. That’s 500 wasted attempts. Verification tools prevent that by pruning those addresses ahead of time. Less traffic to bad targets means fewer failed sessions, less risk of IP reputation damage, and lower chances of hitting rate limits or trigger anti-spam protections.

Our accuracy rate is 98.9%. That means for every 1,000 addresses you verify, only about 11 are incorrectly flagged. The vast majority of invalid addresses are caught. You’re not solving TLS issues directly, but you’re removing the noise that makes them harder to diagnose — and that reduces your overall SMTP failure rate.

For teams using tools like SendGrid, Mailchimp, or Klaviyo, this becomes especially valuable. Integrating verification at scale helps clean your list before every campaign. You can verify your entire list in bulk (try bulk verification) or add real-time checks via our API. It’s about quality, not just delivery.

In short: verification tools don’t fix TLS negotiation, but they prevent you from reaching the point where it even matters — by removing the dead ends before you send.

How does EmailListChecker.io improve deliverability in practice?

By catching invalid, role-based, and disposable emails before you send, EmailListChecker.io reduces bounce rates, improves sender reputation, and boosts inbox placement. You avoid SMTP 220 TLS negotiation fails and 221 disconnects by ensuring only real, deliverable addresses ever enter your campaign stack. It’s not about avoiding errors—it’s about preventing them at the source.

Bulk Verification: Clean Your List Before It Leaves the Door

Use bulk verification to scan thousands of email addresses at once, catching invalid, role-based, and disposable addresses before they ever hit your ESP.
Role accounts like admin@, support@, or marketing@ are flagged as high-risk: they often bounce or get flagged as spam, harming your sender reputation.
Disposable emails (like @mailinator.com or @10minutemail.com) are removed—these are nearly impossible to deliver to and commonly used for fraud.
With 98.9% accuracy, EmailListChecker.io uses real-time SMTP checks and DNS lookups to verify each address against actual mail server behavior.

Real-Time Validation & Delivery Monitoring

Integrate the real-time verification API during sign-up to validate emails on-the-fly, preventing invalid entries from ever entering your database.
Run inbox placement testing with inbox placement reports to see predicted delivery rates across Gmail, Outlook, Yahoo, and others—before sending.
Test how your email content and sender reputation affect deliverability, using data from actual inbox folders (not just spam score algorithms).
Connect directly to Mailchimp, HubSpot, Klaviyo, or SendGrid via pre-built integrations to auto-clean, validate, and update your lists in real time.

Deliverability isn’t about sending more—it’s about sending only to addresses that can actually receive your message.

SMTP 220 TLS negotiation fails often stem from sending to non-existent or misconfigured domains. By validating and cleaning your list first, you avoid the server-level handshake issues entirely. The same applies to 221 disconnects—many are silent failures from unreachable emails that never respond. Preventing those sends entirely is the best defense.

It’s an industry-standard practice to verify email addresses before sending. The RFC 5321 specification defines how mail servers communicate, but doesn’t guarantee delivery—your list’s validity is what determines whether a message gets past the first handshake. Use tools that mirror real-world behavior, not just syntax checks.

The bottom line on SMTP 220 TLS issues: prevention over reaction

TLS handshake failures during SMTP 220 responses are rarely due to external policy blocks. They stem from misconfigured certificates, outdated ciphers, or incomplete TLS support — all preventable with proper setup.

Fixing these issues at the infrastructure level reduces bounce rates, prevents sender reputation damage, and minimizes connection timeouts during delivery attempts.

Before sending to a large list, use email verification to filter out domains with known TLS issues, catch-alls, or invalid addresses. This reduces unnecessary SMTP stress and keeps your sending reputation strong.

Sources

Validity's analysis of 22+ million domains found 84% of domains used in email From addresses have no published DMARC record at all. — Validity (2024)
DMARC adoption among the world's top 1.8 million domains jumped from 27.2% in 2023 to 47.7% in 2025 — a 75% surge driven by Google and Yahoo's sender rules. — EasyDMARC DMARC Adoption Report 2025 (2025)

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 during TLS negotiation?

SMTP 220 means the server is ready for a new connection. It does not guarantee successful TLS; it only confirms the server accepts incoming sessions.

Why does the server send 221 after TLS negotiation fails?

The 221 response indicates the server is closing the session after a failed handshake. It doesn't retry — it terminates the connection.

Is a 220 TLS failure a sign of spam filtering?

Not directly. It indicates a technical issue with encryption setup, not spam filtering. However, repeated failures may harm sender reputation.

Can outdated software cause SMTP 220 TLS issues?

Yes. Older email clients or servers may default to unsupported TLS versions or weak ciphers, causing handshake failures on modern mail servers.

How do I test if my mail server supports TLS 1.2?

Use OpenSSL: <code>openssl s_client -connect your-mail-server:587 -starttls smtp</code>. Check for protocol version and valid certificate chain.

Does a failed TLS handshake affect email delivery rates?

Yes — failed connections result in bounces or undelivered messages, increasing bounce rates and damaging sender reputation over time.

Are disposable email addresses likely to cause TLS issues?

Not directly. Disposable domains are usually hosted on mail servers that accept TLS connections. Issues are more common with self-hosted or misconfigured systems.

Can EmailListChecker.io prevent SMTP errors like this one?

It doesn't test SMTP session behavior. But by filtering out invalid addresses, it reduces the number of failed connection attempts.

What certificate types should I avoid for outgoing mail?

Self-signed, expired, or non-trusted CA certificates. Always use a publicly trusted certificate issued by a recognized authority.

Why does my email still send despite a 221 disconnect?

If the server closes the connection after a failed TLS handshake, the email usually doesn’t get delivered. This results in a hard or soft bounce depending on the server's policy.

Is TLS 1.1 still acceptable in 2024?

No. TLS 1.1 is deprecated and not supported by most modern email providers. Use TLS 1.2 or higher.

Can firewall rules block TLS negotiation without dropping the connection?

Yes. Some firewalls inspect or alter encrypted traffic, leading to handshake timeouts or failures. This is common in enterprise or shared hosting environments.