What does '220 TLS negotiation status before 221 disconnect' mean in email verification?

You're running a verification API against a large list and see a strange log line: "220 TLS negotiation status before 221 disconnect". It looks like server gibberish. But this isn't noise—it’s a signal.

Behind the scenes, your API is talking to mail servers using SMTP. The 220 and 221 codes are real steps in that conversation. If you’re logging the TLS status during the 220 response, you're catching a critical moment: the server’s ready to start encryption, and the handshake outcome tells you whether the server supports secure connections.

This isn’t just technical trivia. If your verification process misses TLS handshake signals, you’re missing a clear indicator of server security posture—something that affects deliverability, reputation, and whether an address is truly usable.

Key takeaways

  • A 220 response means the mail server is ready to accept commands and may advertise TLS support.
  • A 221 response means the server is closing the connection, often after transaction completion or due to timeout.
  • Logging TLS status during the 220 phase lets you verify whether the server attempted a secure handshake before disconnecting.

Why does API-level logging of SMTP status codes matter for email verification accuracy?

You need to log SMTP status codes like 220 TLS negotiation status before 221 disconnect because they reveal whether a server attempted to establish a secure connection. A failure to negotiate TLS—even if the email appears valid—can indicate server-side enforcement, policy blocking, or infrastructure issues that would prevent delivery. Without this data, you miss early warnings about encryption refusal, which is a common reason modern email providers reject inbound traffic. These signals help separate temporary issues from permanent domain or server problems, improving the accuracy of your validation.

How SMTP status codes expose hidden delivery blockers

When your verification API connects to an email server, the server responds with status codes. Code 220 means the server is ready and offers TLS encryption. A 221 disconnect after 220 indicates the server completed the handshake and then dropped the connection—usually due to policy or configuration. But if TLS negotiation fails before 220, it often means the server either doesn’t support encryption or actively refuses it. That’s a red flag: major email providers like Gmail, Outlook, and Apple Mail require TLS and will reject messages that fail to negotiate it.

Many tools skip logging these low-level responses, assuming a reply means success. But if your API only records a “valid” status without tracking whether TLS was offered or refused, you’re missing key context. Some hosts accept inbound connections but refuse encrypted sessions—often for legacy systems or strict firewall policies. Ignoring 220 TLS status means you can't identify these hidden roadblocks.

For example, a server returning 220 followed by 221 might appear to respond normally, but the disconnect suggests instability or forced exit, possibly due to DMARC or SPF enforcement. If the API logs these codes, you can flag domains with inconsistent or weak TLS support. This level of detail is especially valuable in inbox placement testing: domains that fail TLS negotiation often have poor sender reputation or get filtered into spam.

Real-world enforcement of encryption is common. According to the IETF’s RFC 8314, modern email systems treat TLS as a requirement, not an option. A growing number of providers now reject messages that fail to complete TLS negotiation. That makes tracking 220 and 221 status codes essential—not just for accuracy, but for deliverability hygiene.

At Emaillistchecker.io’s verification API, we log every SMTP status code in real time, including the precise moment TLS negotiation occurs or fails. This allows us to detect not just whether an address is valid, but whether a server is setup to accept encrypted mail—meaningful context you won’t get with basic checks.

How does Emaillistchecker.io capture and use 220 TLS status before 221 disconnect in real-time verification?

Our API performs a full SMTP handshake with every email address, logging the server’s 220 greeting and whether TLS was offered in that response, then tracking whether the TLS negotiation completed before the 221 disconnect. This data helps detect domain-level anomalies—like misconfigured servers or inconsistent encryption—allowing us to refine our risk scoring and improve accuracy. The results feed into our 98.9% accurate model, which uses behavioral patterns in TLS failure to distinguish between temporary issues and invalid addresses.

The Real-Time SMTP Handshake

When you verify an email using our API, we don’t just send a request—we go through the full SMTP protocol sequence, just like an email client would. We read every response from the recipient server, including the 220 status that welcomes the connection and the 221 that closes it. This granular visibility lets us see whether a domain’s server supports TLS at all.

If the 220 response includes 220 ... STARTTLS, we attempt to negotiate encryption. If the handshake fails before the 221 disconnect, we flag that as a TLS anomaly. These signals are not isolated events—they form part of a larger pattern. For example, a domain that consistently offers TLS but fails negotiation on half its addresses may indicate a misconfigured server or a proxy layer interfering with the connection.

Why TLS Status Matters for Accuracy

Not all server responses are equal. A 220 response that signals support for TLS but then fails to complete the handshake is different from one that doesn’t offer it at all. We track both—offering TLS vs. not offering it—and use that distinction to assess risk. These signals are especially useful when identifying catch-all domains, disposable email providers, or domains with poor deliverability hygiene.

Take the IETF’s specification on STARTTLS—servers should advertise it when available. When a server advertises TLS in the 220 response but fails to complete the handshake, it often points to a misconfiguration, not an invalid address. This nuanced behavior is baked into our model as a known signal. It helps us reduce false positives when rejecting valid addresses simply because the first TLS attempt failed.

Our system aggregates these signals across millions of verifications, allowing us to detect patterns—like domains that only respond to TLS from certain IPs or regions. This real-time behavioral analysis improves verdict accuracy, especially for edge cases where standard checks fall short. The result is a more reliable verification engine, built on actual SMTP behavior, not assumptions.

If you’re testing email deliverability at scale, you can integrate this behavior into your workflow using our email verification API, which returns the full SMTP sequence and TLS handshake status for each address.

What’s the difference between a 220 TLS offer and a successful TLS handshake?

SMTP’s 220 response signals a server is ready and may support TLS, but it doesn’t mean the connection will actually encrypt. A successful TLS handshake requires the client to initiate the negotiation, exchange certificates, and complete the handshake within a set timeout—without rejection. If the server advertises TLS via STARTTLS or EHLO but fails the handshake, it often drops the connection with a 221 code, even though the address is technically valid.

What 220 truly means

The 220 response is a standard greeting: “I’m ready to accept mail.” It can include a TLS-capable advertisement, like STARTTLS or a TLS flag in EHLO. But that’s just an offer, not a commitment. Think of it like a restaurant saying, “We have wine,” but not guaranteeing it’s available or that the server can pour it.

According to RFC 3207, STARTTLS is optional and must be implemented on both ends. A server can advertise support without actually processing the handshake, especially if misconfigured or enforcing outdated policies. You can’t assume encryption just because the server says it’s available.

Why handshake failure matters

A failed handshake—due to expired certificates, unsupported cipher suites, or network timeouts—results in an immediate 221 disconnect. This breaks the connection before any email data is sent. The address might pass syntax checks, but the mail won't arrive.

When a server offers TLS via 220 but doesn’t complete the handshake, it's a red flag. It indicates either a security misconfiguration, an outdated system, or a service that won’t deliver mail reliably. These are the exact kinds of issues that a real-time email verification API can catch before you send.

Our email verification API goes beyond syntax checks. We validate not just if an address exists, but if it’s capable of receiving encrypted mail—using real SMTP handshake analysis, not just surface-level tests. It helps you identify dead-end addresses before they hurt your sender reputation.

When do TLS negotiation failures in 220-to-221 flow indicate a real email deliverability risk?

Repeated TLS negotiation failures between SMTP 220 greeting and 221 disconnect often signal deeper issues beyond a single bad email: they point to infrastructure problems like outdated mail transfer agents (MTAs), misconfigured firewalls, or domains with strict security policies. If multiple domains or IPs show the same pattern, it’s usually a sign of systemic risk — not isolated invalid addresses.

When failures are widespread, it’s not just an address — it’s a network issue

If your email verification API logs show consistent 220-to-221 TLS handshake drops across many domains, especially from the same IP range or provider, that’s a red flag for network-level problems. Outdated MTAs or overly aggressive firewalls may reject connections before encryption can begin. This isn't about the user@domain format — it’s about the server infrastructure behind it. Monitoring this pattern helps catch domains known for poor deliverability due to weak or misaligned security setup.

When one domain refuses encrypted connections, it may be by design

But if one domain consistently rejects TLS negotiations even when you're using a modern, compliant setup, it might not be broken — it could be enforcing strict policies. Some organizations block all unencrypted mail, forcing TLS only. If your connection tries to start without encryption, they drop it with a 221 disconnect after 220. In these cases, the issue isn't the email address; it's the mail delivery setup at the receiving end. This is common in financial, government, or high-security domains.

What matters is how these signals interact with other validation results. If TLS negotiation fails, and DNS records are missing, no SPF/DKIM check succeeds, and no mailbox response is received — the system flags the address as risky or invalid. It’s not just one failure; it’s a convergence of signals. Services like email verification APIs use this behavior to assess risk when traditional checks can't confirm legitimacy.

For those building or maintaining sending lists, tracking these patterns helps identify recipients more likely to bounce, be flagged, or land in spam. It’s not just about syntax — it’s about infrastructure integrity. The RFC 5321 specification defines SMTP transaction phases, and TLS negotiation sits at a critical point in that flow; when the handshake fails at 220-to-221, it’s often a sign that something downstream can’t or won’t accept your connection.

Can you detect catch-all domains using 220 TLS status and 221 disconnect behavior?

Yes, you can detect catch-all domains by analyzing SMTP behavior: a 220 greeting followed by a quick 221 disconnect after the MAIL or RCPT command often signals a catch-all setup. These domains accept connections and TLS negotiations (220 response) but may reject individual addresses without a clear error, especially when the recipient is invalid.

How 220 and 221 signals work in practice

When an SMTP server responds with 220, it means the connection is established and TLS negotiation can begin. A catch-all domain typically replies with 220, allowing the handshake to complete, but may send a 221 (closing service) immediately after receiving a MAIL FROM or RCPT TO command for an invalid address. This quick disconnect — before the mail transaction finishes — is a key tell.

But a 220 alone doesn’t confirm a catch-all. Many valid domains also send 220. The pattern matters: if the server accepts TLS and the connection, then closes abruptly after receiving an RCPT command with an invalid address, it’s more likely a catch-all.

Combining SMTP signals for higher accuracy

Single indicators like TLS status or 221 disconnects can generate false positives. For example, some domains use 221 for graceful shutdowns even when not catch-all. But when paired with other signals — like accepting RCPT without rejecting or failing silently — the pattern becomes clearer.

That’s where layered verification comes in. Emaillistchecker.io uses this behavior — along with other SMTP telemetry — to flag domains with higher precision. Instead of relying on a single code, it evaluates the sequence: 220, TLS handshake, RCPT accepted, then 221 disconnect. This combination reduces false positives compared to tools that only check the final response.

While RFC 5321 defines standard SMTP commands and responses, real-world behavior varies. Some servers intentionally delay or omit responses, making detection harder. Still, consistent patterns like these short-lived connections after invalid RCPT attempts remain a reliable signal among well-known delivery behaviors. You can see how this works in practice with our bulk verification system, which applies the same rules at scale.

How does real-time verification with API logging improve inbox placement?

Real-time email verification with detailed API logging helps you identify and remove addresses that fail TLS handshakes (like 220 to 221 disconnects) before sending. This reduces your risk of being flagged as an insecure sender, improves sender reputation, and increases the chance your messages land in inboxes instead of spam folders. Mail providers like Gmail and Outlook track encryption success, so consistently failing TLS negotiations harms deliverability.

Why TLS handshake status matters for inbox placement

Sending emails requires more than just a valid address — it requires a secure connection. Modern mail providers use protocols such as SMTP with STARTTLS to encrypt traffic. A 220 status means the receiving server is ready, but a 221 disconnect after that indicates a failed TLS negotiation. Repeated failures signal poor infrastructure or insecure practices, which can harm your sender reputation over time.

Mail providers monitor these signals to assess sender trustworthiness. If your sending patterns show many failed TLS handshakes, systems may assume you’re either using compromised infrastructure or targeting vulnerable endpoints. That behavior correlates with spam patterns. According to the IETF’s RFC 5248, encryption failures are one of several red flags considered in deliverability scoring.

How API logging catches and prevents risky sends

With real-time verification, every email address is tested for technical health — including whether the receiving server supports and completes TLS. Logging 220-to-221 disconnects lets you flag and remove addresses that consistently fail encryption handshakes.

Let’s say your list includes 10,000 addresses. A few failed connections might be normal, but if 1% consistently show TLS negotiation issues, that’s a warning sign. Filtering those out during verification prevents your server from even initiating a connection with unreliable endpoints. This reduces bounce rates, protects your sending domain’s reputation, and aligns your sending practices with industry standards.

Tools like email verification via API allow you to integrate this checking directly into your workflow — testing addresses at scale and logging every detail, including connection status codes. You’re not just validating syntax and format; you’re validating trustworthiness.

What do you gain by logging 220 TLS and 221 disconnect in your email verification pipeline?

Logging the 220 TLS negotiation status and 221 disconnect in your email verification pipeline gives you direct visibility into whether a mail server enforces encrypted connections. This lets you catch domains that reject unencrypted SMTP traffic—even if the email syntax and domain are perfectly valid—before you send. As a result, you reduce transport-level bounces and improve inbox placement by filtering out risky or misconfigured addresses upfront.

Why 220 and 221 matter beyond syntax checks

Many email providers now enforce TLS encryption by default. A server responding with 220 during the handshake confirms it’s ready to negotiate encryption. If the connection drops before that, or fails to proceed to 221 (the disconnect message), something went wrong—often due to policy enforcement. Tracking this tells you more than a domain check ever could. You’re not just verifying the address; you’re validating the server’s security posture.

Enterprises and internal mail systems often block unencrypted connections entirely. You might have a perfectly valid email like [email protected], but if the server requires TLS and shuts down the session before 221, that address will never deliver. Logging 220 and 221 helps you flag these cases early—something syntax or domain checks can’t do.

Real impact on deliverability and list hygiene

Sending to addresses that fail TLS negotiation leads to immediate transport rejection, usually flagged as a permanent failure. These aren’t soft bounces; they’re hard stops. Without logging these status codes, you’ll see a high bounce rate on lists that look clean on paper. But with the data, you can filter out domains that reject encrypted channels, even if the domain appears legitimate.

For example, many internal email systems—especially in regulated industries—only accept TLS-secured connections. If your sending infrastructure doesn’t support TLS or skip the negotiation, you’ll hit a wall. By logging the 220 and 221 responses, you detect these issues during verification, not during delivery. This improves your sender reputation and reduces the risk of being blacklisted.

SMTP standards, like RFC 5923, emphasize the importance of encryption in modern email delivery. A connection that fails to negotiate TLS isn’t just inefficient—it’s a signal of misconfiguration or policy. Monitoring these exchanges ensures your lists stay clean for both deliverability and compliance.

Tools that track TLS handshake status during verification give you an edge. If you’re serious about reducing bounces and maintaining sender health, you need more than syntax and domain checks. You need to see the actual handshake behavior. Try real-time verification with full SMTP transparency at our verification API, where every connection’s status—including TLS negotiation—is logged for analysis.

How Emaillistchecker.io uses SMTP logging to improve verification accuracy

Every email verification we perform captures the full SMTP transaction log, including the 220 (service ready) greeting and 221 (goodbye) disconnect codes, along with TLS negotiation status. We analyze handshake completions, timing delays, and server behavior to build profiles that predict deliverability risk—this deep inspection is why our accuracy reaches 98.9%, far beyond basic syntax or DNS checks.

Tracking the full SMTP journey

When you send an email address for verification, we don’t just check if the domain exists—we simulate a real SMTP session. We log each status code, starting with the 220 response that confirms the receiving server is accepting connections, and end with the 221 disconnect message that signals graceful closure. These messages are critical: a 220 response means the server is online and listening. A missing or delayed 220 may indicate poor infrastructure or spam filtering.

We also monitor TLS negotiation. If the server advertises support but fails to complete the handshake, that’s a red flag. Servers that drop connections after TLS negotiation may be rate-limiting, greylisting, or blocking suspicious traffic. We record these patterns—timing, retries, and handshake failures—to identify behavioral quirks that simple tools miss.

Beyond the code: learning from the real email world

Every log is a data point. Over time, we feed these logs into a machine learning model trained on real-world deliverability outcomes. Patterns like consistent 220 responses followed by 221 disconnects within 5 seconds suggest a high-volume, transient server—common with disposable email providers. Persistent 220 responses with no 221 suggest a server that doesn’t properly close sessions, often a sign of poor configuration or abuse.

These insights aren’t just historical—we use them to refine live verdicts. A single address classified as “risky” today might be flagged based on TLS behavior observed in 10,000 prior verifications. This continuous feedback loop is what drives our 98.9% accuracy. Unlike tools that rely on static DNS lookups or blacklists, we see the actual conversation the mail server would have had—if it hadn't been blocked, throttled, or misconfigured.

For developers and marketers, this level of inspection starts with the email verification API, which exposes full SMTP logs for each request. You can see exactly what happened during a verification attempt, including the sequence of status codes and TLS state, directly from your integration.

For deeper understanding, the RFC 5321 specification describes SMTP’s transaction model—how servers should respond at each stage, including status codes like 220 and 221. While not all servers comply, the specification sets a baseline for expected behavior. IETF RFC 5321 remains a foundational reference for how email should work in theory—and how we detect when it doesn’t, in practice.

Integrating real-time verification with 220-221 logging into your email workflow

You can integrate our email verification API directly into your sign-up or data entry flow to validate addresses in real time. Each request returns detailed TLS handshake logs—specifically the 220 SMTP greeting and 221 disconnect status—enabling you to filter out domains that fail TLS negotiation or drop connections prematurely. Use this data to block risky or unsupported domains before they harm your sender reputation or trigger bounces.

How it fits into your workflow

  • Embed the email verification API at the point of entry—during account creation, checkout, or lead capture—to validate every new address instantly.
  • Enable 220-221 logging in your API calls to capture SMTP session behavior, including successful greetings (220) and clean disconnections (221), which indicate a compliant, TLS-capable server.
  • Flag domains that return 220 but no 221—these often indicate misconfigured or non-responsive mail servers, increasing the risk of permanent delivery failure.
  • Build custom filters to reject domains showing repeated 220-only responses or failure to complete the TLS handshake, reducing the chance of sending to non-existent or non-receiving accounts.
  • Only send to addresses verified as both valid and capable of secure TLS connections—this protects your sender reputation and reduces the likelihood of your messages being flagged or throttled.
  • Use verified data to maintain clean lists: fewer hard bounces, improved sender score, and higher inbox placement rates across major providers like Gmail and Outlook.

Why it matters for deliverability

SMTP handshakes reveal more than just address validity—they expose the underlying health of the receiving mail server. A 220 without a 221 suggests incomplete or unstable connectivity, which correlates with poor deliverability signals tracked by services like Spamhaus and MxToolbox. Ignoring these anomalies increases the chances of domain-level or IP-level reputation damage.

By filtering based on 220-221 patterns, you eliminate a class of low-quality, high-risk addresses before they enter your campaign queue. This proactive cleanup reduces infrastructure load, minimizes deliverability blacklists, and aligns your sending behavior with RFC 5321 standards for SMTP communication.

Final take: Logging 220 TLS before 221 disconnect is not just technical — it’s essential

SMTP-level logging captures signals that syntax checks, domain lookups, or role account detection miss. A 220 greeting with successful TLS negotiation before 221 disconnect reveals whether a server is actively accepting mail — a signal no other method provides.

TLS negotiation outcomes aren’t just about encryption; they reflect real server policies. A failed negotiation or abrupt 221 disconnect often means the server is filtering outbound mail, limiting deliverability before any content is sent.

Ignoring these signals means sending to recipients who will never receive your email — and risking sender reputation. Tools that expose this layer give you honest feedback, not guesses. You’ll avoid wasted sends and improve inbox placement by knowing which servers are truly open.

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

What does SMTP status 220 mean during email verification?

It means the mail server is ready to accept commands. If it includes 'TLS' or 'STARTTLS', it advertises secure connection support.

Why does a 221 disconnect matter after a 220 response?

It confirms the server closed the connection after the handshake. A premature 221 after 220 may signal TLS failure or rejection.

Can TLS negotiation failure mean an email is invalid?

Not necessarily. But repeated failures across domains or addresses signal delivery risks worth flagging.

Does Emaillistchecker.io log all SMTP responses during verification?

Yes. Our API captures full transaction logs, including 220, 221, and TLS status for each address.

How does 220 TLS logging reduce bounce rates?

It helps identify domains that reject encrypted connections, preventing deliveries to servers that will outright block the message.

Are TLS handshake failures always a sign of a bad domain?

No. Some domains enforce strict security policies. But consistent failures across multiple addresses indicate risk.

Can catch-all domains be detected using 220 and 221?

Indirectly. A domain that accepts SMTP connection (220) and disconnects quickly (221) after RCPT may be catch-all.

Why not just verify syntax and DNS?

Syntax and DNS don't detect server-side TLS policies or connection-level rejections that cause delivery failure.

How can I test if my domain supports TLS handshake?

Use command-line tools like openssl s_client -connect yourdomain.com:25 or SMTP test services with full log access.

Does Emaillistchecker.io use this data for its accuracy score?

Yes. The full SMTP transaction logs, including 220 and 221, contribute to our 98.9% accuracy.

Are 220-to-221 logs available in the API response?

Yes. We return detailed SMTP logs, including status codes and TLS negotiation behavior, with each verification.

Why is this important for enterprise email workflows?

Enterprises often enforce TLS-only policies. Sending to systems that reject encrypted traffic harms sender reputation.