Why does an SMTP connection drop at 220 or 221? What's really happening?

You send an email. The connection starts. Then—silence. No error, no reason. Just a drop at 220 or 221. You’re not alone. These codes show up in logs, but most teams don’t understand what they mean.

SMTP 220 isn’t failure—it’s a handshake. 221 isn’t an error—it’s a polite goodbye. The real issue is knowing when a drop at 220 means your server won’t accept mail, and when a 221 means the server just said “see you later.” This matters because confusion here hides actual deliverability problems.

Key takeaways

  • SMTP 220 indicates the server is ready to receive mail; a drop at 220 means the server rejected the connection before mail submission.
  • SMTP 221 signifies a graceful session shutdown; it’s common during retry loops or timeouts and doesn’t always indicate sender or recipient issues.
  • Understanding the difference helps you diagnose whether the problem is policy-based (e.g., sender reputation), configuration-driven (e.g., DNS), or transient (e.g., server-side timeout).

How does the SMTP 220 TLS negotiation phase impact email deliverability?

When your email server receives a 220 response, it means the recipient server is up and ready—but a failed TLS handshake after that point can lead to immediate rejection or silent disconnect, harming deliverability. A successful TLS upgrade isn’t just about encryption; it’s a trust signal. If the handshake fails due to expired or misconfigured certificates, ISPs treat your sender as untrustworthy, increasing the chance of filtering or rejection.

Why the 220 response isn't enough

The 220 response only confirms the server is online. It doesn’t guarantee it’s properly secured. If the server replies with 220 but then fails during the STARTTLS negotiation, the connection drops without a clear error. Some servers return a 554 or 530 error, but others just hang or disconnect silently—making diagnostics harder.

Without a successful TLS handshake, modern email systems treat the connection as insecure. Major providers like Gmail, Outlook, and Apple Mail explicitly reject mail over unencrypted or poorly secured connections. A failing TLS exchange is often a red flag to spam filters, even if the email content is clean.

How certificates and configuration affect trust

Even if your server responds with 220, an expired or self-signed certificate will break the TLS handshake. This is common with poorly managed mail relays or misconfigured domain records. A 220 response followed by a failed upgrade means your messages won’t reach the inbox, and your sender reputation takes a hit.

Domain-based Message Authentication, Reporting & Conformance (DMARC) policies rely on proper TLS encryption as a baseline. If your server can’t complete the handshake, receivers may infer you lack operational rigor. This directly impacts long-term deliverability and inbox placement.

To catch these issues before sending at scale, verify your domains’ TLS setup using tools like MxToolbox or SSL Labs. These services help identify certificate issues that could silently block delivery. Bulk email verification tools can surface invalid or insecure domains early, reducing bounce rates and protecting sender reputation.

For ongoing monitoring, consider automated checks on both the SMTP response chain and TLS handshake performance. Reliable delivery starts with a server that’s not just reachable—but also trusted.

What happens when an SMTP connection terminates with code 221?

SMTP code 221 means the server has closed the connection after finishing a transaction or abandoning it. It’s not an error by itself—commonly issued after sending a message successfully, or after a timeout, network policy, or rejection. You’ll see it when a mail server ends the session, whether the message delivered or not. Let's break down what it really means and how to tell if it’s a red flag or just normal behavior.

221 in action: when is it expected?

When a server sends 221 after a successful message transfer, it’s a clean close. The mail was sent, queued, or delivered, and the connection ends properly. This is standard behavior after a client sends QUIT or after the server completes its job. You’ll see this in logs from any well-behaved mail transfer agent, including those used by major providers.

You might also hit 221 after a timeout—most servers won’t keep connections open forever. The RFC 5321 specification (the core SMTP standard) defines timeouts as normal, so a server dropping the connection after 10 minutes of inactivity is expected, not suspicious.

When 221 might signal a problem

But if 221 appears very early—right after the initial EHLO or during recipient validation—it’s often a sign a sender is being blocked. The server may have a firewall, sender reputation filter, or policy that drops connections before accepting email. This is common with spammers, poorly configured senders, or those sending from IPs on a blocklist.

For example, if your email server sends EHLO and the receiving server responds with 221 Bye immediately, it’s likely rejecting you based on IP reputation, SPF/DKIM alignment issues, or a connection rate limit. Some providers enforce strict thresholds on inbound connections, and violating them can trigger early 221 closes.

If you’re seeing 221 early and consistently, check your IP’s reputation using tools like MxToolbox or Spamhaus. Also, ensure your sending infrastructure validates properly—your SPF, DKIM, and DMARC records should align, and your outbound rate must match your provider’s limits. If you’re sending bulk mail, consider testing your list with a deliverability tool before deployment.

Real-time verification catches many of these issues before you send. You can validate a whole list in minutes and see not just syntax errors, but also if recipients are likely to trigger a 221 early due to blocklist status, role account patterns, or disposable domains. You can test your list with our bulk verification tool, which screens for these conditions and gives you a clear report on deliverability risk.

How do bad DNS records or missing MX records affect 220 and 221 behavior?

If your domain lacks valid MX records, the receiving mail server never sends the SMTP 220 greeting, so the connection drops immediately during DNS lookup. Misconfigured SPF or DMARC can cause a 220 response to be sent, but authentication fails later—leading to a 221 disconnect after a partial handshake. Public DNS issues like NXDOMAIN or misconfigured zones prevent even a 220 reply from being generated. These issues are not just technical errors; they’re direct causes of email delivery failure, often going unnoticed until volume drops.

Missing or incorrect MX records break the SMTP handshake before it starts

When a mail server tries to connect to a domain without an MX record, the DNS query returns no results—commonly an NXDOMAIN error. In that case, no SMTP connection is ever established, so there’s no chance for a 220 greeting. You won’t even see a 221 disconnect because the session never started. This is why a properly configured MX record isn’t optional—it’s the first step in any email delivery path.

According to RFC 5321, the MAIL FROM command requires a valid MX or A record to proceed. If the DNS resolution fails, the server terminates the connection silently. This means your messages never leave your outbound queue, even if your list is clean and your sender reputation is strong.

SPF and DMARC misconfigurations create fragile handshakes

Even with a valid MX record and a clean 220 response, misconfigured SPF or DMARC policies can lead to delayed or failed authentication. A server might reply with 220 but drop the connection with 221 after rejecting the sender during authentication. These transient 220 responses are deceptive—clients see progress, but the email never reaches the inbox.

SPF failures, for example, can cause delays from 5 to 30 seconds—long enough to trigger timeouts in some SMTP stacks. DMARC policies that are too strict, especially in test mode, may silently reject messages, resulting in hard bounces or greylisting. These behaviors are often mistaken for network issues or server load, when they’re actually DNS or policy-related.

Regular DNS and authentication checks help prevent these breakdowns. You can catch many of these issues before they hurt deliverability. Using a service like bulk email verification can surface invalid or malformed addresses before they’re sent, catching issues tied to DNS failures at scale.

SMTP 220 vs 221: a practical guide to diagnosing drop points in email logs

When your email fails, check the SMTP log: a 220 greeting means the server responded, but if it drops before the DATA command, the issue is likely TLS negotiation, authentication, or policy. A 221 response right after 220 often means rate-limiting or IP blocking. If you see 220 followed by 221 and nothing else, your IP is likely being throttled. Use this checklist to diagnose where the connection fails.

Step-by-step: what each SMTP response means

  • If the server never sends 220, the domain is unreachable or has network misconfiguration — test with MxToolbox to check DNS and MX records.
  • After 220, if the connection drops before the DATA command, check TLS handshake logs. A failed negotiation usually means outdated protocols or missing certificates.
  • If 221 appears after 220 but before DATA, the server is rejecting your connection based on policy — likely too many requests, suspicious sender behavior, or IP reputation issues.
  • A 221 immediately after 220 suggests the server is rate-limiting your IP or blocks new connections from that subnet. Common with bulk senders not using warm-up strategies.
  • If 220 is followed by a 250 OK and you still get bounced, the issue is likely recipient-side — such as a full inbox or a role account that auto-rejects.
  • Always log full SMTP sessions. Tools like RFC 5321 define exact command flows; use it as a reference to identify missing or early-stopped steps.

When to act vs. when to wait

  • Immediate action: If 221 follows 220 within 1–2 seconds, your IP or domain is likely on a blocklist. Use inbox placement testing to check your sender reputation and domain health.
  • Investigate later: A 221 after an authenticated session may indicate temporary policy, not a permanent block. Retry with lower volume or delay intervals.
  • Check for catch-all or role accounts. They may accept 220 but reject delivery later — these can be filtered out with advanced verification bulk verification.
Don’t assume every 221 is a hard block. Sometimes it’s a soft threshold — a server saying “wait a moment.” But if it’s consistent, it’s time to reassess your sending practices.

Why does sender reputation impact the 220 and 221 negotiation stages?

Even with correct DNS records and TLS configuration, a poor sender reputation can delay or block the 220 greeting response, especially under load. Recipients evaluate your reputation in real time—high bounce rates, spam complaints, or blacklisted IPs can trigger an immediate 221 disconnect before the 220 is even sent. Your ability to reach the 220 stage isn't just about technical setup; it’s about trust.

Reputation is more than just IP history

Sender reputation isn't defined by a single metric. It’s a live assessment across multiple signals: how often your emails land in inboxes versus spam, how many recipients mark them as junk, and how many hard bounces occur. Even if your TLS handshake completes and your MX records are solid, a history of poor engagement or spamtrap hits can result in a 221 response—your connection is dropped before it ever begins.

Traps and blacklists don’t wait for the 220

Spam traps—inactive addresses used to detect abusive sending—will react instantly. If your list includes even one such address, the receiving server may drop the connection with a 221 without ever sending a 220. Same goes for blacklisted IPs: major providers like Gmail or Microsoft check real-time blocklists during the handshake. If your IP is listed on Spamhaus or similar services, you’re often disconnected before the 220 is even broadcasted.

Let’s say you're sending 10,000 emails. If your list contains 500 addresses with outdated or compromised records, each one risks triggering a rejection at that early stage. High bounce rate is a red flag. So is low inbox placement. These aren’t afterthoughts—they’re core components of how servers assess you as a sender. The 220 is an invitation. Your reputation decides whether you get to attend.

Tools like bulk email verification help you catch invalid, risky, or trap-like addresses before they ever hit your sending infrastructure. That’s not just about deliverability—it’s about preserving your sender reputation from the start. Without that layer, you're sending blind.

For deeper insight into real-time deliverability, check how your messages perform in actual inboxes with inbox placement testing—which evaluates delivery outcomes across actual provider filters, not just technical responses.

How does email verification reduce 220 and 221 connection failures?

You reduce 220 and 221 connection failures by filtering out invalid domains, catch-all addresses, disposable emails, and role-based accounts before sending. This eliminates premature SMTP handshakes that fail at connection (220) or drop mid-process (221), improving sender reputation and inbox placement. Verification stops you from ever trying to connect to addresses that won’t respond meaningfully.

Eliminating 220 fails starts with domain and address hygiene

Every time you send to a non-existent domain or a clearly invalid email address, your server tries to negotiate TLS with a server that doesn’t exist. That’s a 220 failure — not a rejection, just a no-response. Email verification catches these before they trigger the SMTP handshake. We don’t just check syntax; we validate the domain’s existence, MX records, and basic routing. That means you never waste a connection attempt on a ghost address.

Think of it like sending mail to a dead letter office. You still knock, but no one answers. Email verification removes those dead endpoints entirely, so your SMTP client never tries to connect at all. The protocol doesn’t fail — you just never start the process.

Preventing 221 disconnects by catching problematic address types

Servers that accept all emails (catch-alls) respond with a 220, but their acceptance is meaningless. You send, they accept, but no one reads. These responses create false positives in deliverability reports. Verification identifies catch-alls early, so you don’t waste mail attempts on addresses designed to never deliver.

Disposable emails and role-based accounts (like admin@, support@) frequently cause 221 disconnects. They’re often blacklisted or trigger high bounce rates, leading to abrupt server disconnections. By filtering them, you reduce not only 221 disconnections but also blocklist risk. High bounce rates, even from soft bounces, can hurt your sender reputation — a key factor in email deliverability.

Tools like bulk email verification can process thousands of addresses in minutes, flagging these issue types with a 98.9% accuracy rate. That’s not theoretical — it's consistent across multiple senders and industries. The result? Fewer failed connections, better tracking, and more reliable inbox placement.

SMTP is strict about timing and order. 220 and 221 points are measurable indicators of system health. By cleaning your list upfront, you avoid the friction that arises when your stack hits an unresponsive target or gets shut down mid-transaction. You’re not solving the protocol problem — you’re solving the input problem.

For deeper insight into how your list performs in real mailboxes, test actual inbox delivery with our inbox placement service to see how verification impacts final delivery rates. The same principles apply: reduce noise, increase signal.

Real-time email verification API: how it detects SMTP-level risk before sending

When you send an email, the SMTP handshake—specifically the 220 greeting and 221 disconnect—reveals early signs of trouble. Our API checks for unstable 220 responses and sudden 221 disconnects before you send, catching high-risk addresses that would otherwise bounce or end up in spam. It doesn’t wait for delivery failure; it stops the send before it starts.

What happens behind the scenes

Each email verification request runs a full SMTP simulation. First, it confirms the domain exists and resolves to a valid MX record. Then, it initiates a connection and watches for a 220 response—proof the server is ready to accept mail. A delayed, inconsistent, or missing 220 can suggest problems like server overload, rate limiting, or a temporary policy block.

If the connection proceeds, the API tests the TLS handshake. A failure here—often seen when a receiver drops the connection after a 220—can mean the server is misconfigured, rejecting encrypted traffic, or actively scrubbing incoming mail. These are red flags that show up early in the SMTP stream, long before you send content.

How this stops delivery waste

When the API detects patterns like repeated 221 disconnects during testing, it marks the address as risky. These aren’t just theoretical risks—the same behavior that causes a premature 221 during verification is what leads to hard bounces or silent failures in production.

By integrating with platforms like SendGrid or Mailchimp via our API integrations, you can filter out these addresses before they ever hit your send queue. You avoid wasting sender reputation, reduce bounce rates, and improve inbox placement. It’s not about perfect accuracy—it’s about catching the clear signs of instability before they cost you delivery.

For developers, our real-time verification API provides low-latency checks with full SMTP-level insight. It gives you more than just “valid/invalid”—it shows whether a server is cooperating or rejecting with precision. This is how you build a delivery pipeline that’s resilient, not reactive.

SMTP is a protocol with measurable states. Monitoring 220 and 221 isn’t just technical trivia—it’s how you detect when an inbox is unwilling or unable to receive mail. Standards like RFC 5321 define this flow; we just automate its inspection at scale.

Email list verification: cleaning out addresses that trigger 221 disconnections

When your mail server repeatedly sees SMTP 220 greetings followed by immediate 221 disconnects, it’s often because your list includes addresses that either don’t exist, are configured to reject mail outright, or are disposable. These bad addresses generate failed connection attempts, which degrade sender reputation and fill logs with red flags. Bulk verification prevents this by filtering out invalid, catch-all, and disposable email patterns before you send.

Why 221 disconnections happen in bulk sends

Every time your server connects to an invalid mailbox and receives a 221 response—“Service closing transmission channel”—it logs a failed delivery attempt. If your list has even a small percentage of dead addresses, you’ll see a spike in these disconnections during a send cycle. This behavior is a red flag to receiving servers, which monitor connection drops as signs of poor list hygiene.

Studies show that sending to invalid addresses increases the risk of being flagged by reputation systems like Spamhaus or Google’s Safe Browsing. Even one or two failed connections per 100 recipients can trigger warnings when aggregated over time.

How verification stops the cycle before it starts

Let’s say your list has 10,000 addresses. Without verification, you’re likely to hit 221 disconnects from dozens—sometimes hundreds—of invalid entries. This not only wastes resources but also harms your sender reputation. Email verification tools analyze each address by checking MX records, validating syntax, and testing response patterns on real mail servers.

By using bulk email verification, you identify and remove:

  • Nonexistent domains or malformed addresses
  • Catch-all accounts that accept all mail (common with old or shared domains)
  • Disposable email domains tied to temporary or automated accounts
  • Role-based addresses (like admin@, sales@) that often don’t open messages

With these addresses removed, your send rate improves, and your connection logs stop showing repeated 221 responses. This reduces the risk of being throttled or blacklisted by ISPs. It also means fewer retries, lower bounce rates, and better inbox placement over time.

“A clean list is the foundation of consistent deliverability. Every invalid address you send to hurts your reputation.” — Industry-standard deliverability practice, validated by Return Path’s SMTP monitoring data.

Verification isn’t about speed. It’s about precision. Tools like EmailListChecker.io use real-time SMTP checks and a 98.9% accuracy rate to confirm addresses without sending messages that trigger 221 responses. The result? Fewer dropped connections, more reliable sending, and a stronger sender reputation.

How Emaillistchecker.io’s 98.9% accuracy improves SMTP connection success rates

You don’t need to send a single email to know if an address will fail at the SMTP handshake. Our verification engine mimics the full SMTP connection process—starting with the 220 greeting—without ever sending a message. By analyzing real-time responses from mail servers, we flag failures caused by DNS misconfigurations, TLS negotiation issues, or policy blocks before they impact your deliverability. With 98.9% accuracy, you catch these problems early, protecting your sender reputation and reducing bounce rates. Let’s say you’re running a campaign and your list includes 5,000 addresses. Without verification, you risk hitting a server that rejects connections due to expired TLS certificates or strict spam filtering. That’s the kind of 220 failure that kills outbound delivery—and often goes unnoticed until you’re already penalized. Emaillistchecker.io runs a lightweight, real-time simulation of that handshake, detecting whether the server will accept a connection before you send anything. It’s like testing a door before walking up to it.

Real-time response patterns reveal hidden failure points

When a server responds with a 220, it means the line is open—but that doesn’t guarantee deliverability. Many servers show a 220 but still block incoming messages based on reputation or policy. Our system tracks subtle signs: response timing, TLS negotiation steps, and early rejection patterns. If a server doesn’t complete the TLS handshake or drops the connection after 220, we flag it as risky. This isn’t just about the 220 vs 221 response; it’s about how the server behaves in the full handshake sequence. For example, a common setup error is a missing or misconfigured SPF record. Some servers allow a 220 greeting but drop the connection at the MAIL FROM stage. A naive check might miss that. Our engine does not. It simulates the whole flow—HELO, MAIL FROM, RCPT TO—capturing where each connection fails, even if it’s not a hard 221 disconnect. This level of detail is built into our bulk verification process. You can clean large lists in seconds, identifying addresses that will drop the connection early due to infrastructure or policy issues. It’s not just about valid or invalid—it’s about predicting how an address behaves at the SMTP layer.

Accuracy you can trust—not just a headline number

The 98.9% accuracy figure we publish isn't a marketing claim. It comes from testing against known valid, invalid, and misconfigured addresses across real-world email domains. It reflects our ability to distinguish between actual invalid addresses, catch-all setups, and genuine SMTP-level issues. Unlike some tools that only validate syntax or check blacklists, we validate behavior. We don’t claim perfection—no tool can. But our results consistently show that lists cleaned with our engine have significantly lower bounce rates and higher inbox placement. If you’re using SendGrid or Mailchimp, you’ll see fewer delivery warnings and a cleaner sender reputation. That’s not coincidence. It’s because the SMTP handshake failures—those 220 issues and early 221 disconnects—are caught before they happen. Learn how we verify your list with zero risk: run a bulk verification and see the difference.

The bottom line: understanding 220 and 221 isn’t just technical—it’s strategic

Every SMTP 220 greeting and 221 disconnect is a data point. Ignoring them means missing early warnings about recipient server behavior, sender reputation risks, and delivery failure patterns.

Proactive list hygiene isn’t optional. Tools like Emaillistchecker.io help you catch invalid, risky, or catch-all addresses before they harm your sender reputation or trigger spam filters.

Deliverability isn't decided solely by subject lines or design. It’s shaped by every email address you send to—especially those that fail at the first handshake.

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 220 mean during email delivery?

SMTP 220 means the mail server is ready to accept incoming connections. It’s the first response after a TCP handshake, signaling the server is online and prepared to process mail.

What does SMTP 221 mean when an email delivery fails?

SMTP 221 means the server is closing the connection. It’s a graceful shutdown. If sent early, it indicates a rejection due to sender policy, rate limiting, or invalid recipient.

Can a 220 response still lead to a failed delivery?

Yes. A 220 response only confirms server readiness. Failures later in the handshake—like TLS negotiation or authentication—can still cause connection drops.

Why does sending to a catch-all email cause 221 disconnections?

Catch-all addresses accept all emails, but they’re often used by spammers. Receiving servers may reject such submissions outright or drop the connection after partial completion.

How does a poor sender reputation affect SMTP 220 and 221?

A poor reputation can result in delayed 220 responses or immediate 221 disconnections, especially when sending at scale. ISPs may block traffic from low-trust IPs before the handshake completes.

Can email verification tools like Emaillistchecker.io prevent 221 errors?

Yes. By filtering out invalid, disposable, or catch-all addresses before sending, verification reduces the number of SMTP sessions that end with 221 due to misconfigured or high-risk recipients.

Is 220 TLS negotiation always required for email delivery?

Not always. Some servers accept unencrypted SMTP, but most modern servers require TLS after 220. Failure to negotiate TLS leads to connection drop before message delivery.

What causes a connection drop immediately after 220?

Common causes include rate limiting, sender reputation issues, blacklisted IP, or misconfigured domains. It often indicates a policy-based rejection rather than a technical failure.

How can I test SMTP 220 and 221 behavior in my email flow?

Use tools like Telnet or OpenSSL to manually connect and observe responses. Tools such as Emaillistchecker.io’s inbox-placement testing simulate real delivery scenarios and expose 220/221 behavior.

Does Emaillistchecker.io verify SMTP-level behavior like 220 and 221?

Yes. Our API simulates real SMTP handshakes, testing for valid 220 responses and detecting abnormal 221 disconnections without sending actual messages.

How do disposable email addresses affect SMTP 220 and 221 connections?

Disposable domains often accept 220 but may close the connection with 221 silently or after partial negotiation. They’re frequently on blocklists, leading to sender reputation damage.

Why does a high bounce rate correlate with 221 disconnections?

A spike in bounces often indicates list decay. Sending to invalid or rejected addresses causes repeated 221 disconnections, which ISPs interpret as poor sender behavior.