Test SMTP TLS Handshake with openssl s_client

Why Test Your SMTP Server’s TLS Handshake?

You send an email. It fails. No bounce, no error message—just silence. The server logs say nothing. You’re left guessing: Was it spam? A misconfigured domain? Or did encryption fail before the message even began?

TLS handshake failures don’t show up in standard logs. They break delivery silently. A single misconfigured certificate, outdated cipher, or rejected negotiation can block your email at the first step—before it ever reaches an inbox. Many major providers now reject SMTP connections that can't complete a secure TLS handshake.

Testing your SMTP server’s TLS handshake in real time using openssl s_client terminal is the only way to see what’s actually happening during the connection. It’s like checking a door’s lock before handing over a package—except here, the lock is the encryption handshake.

Key takeaways

TLS handshake failures cause silent email delivery failures and damage sender reputation over time.
Modern email providers like Gmail and Outlook reject connections that fail to negotiate TLS encryption properly.
Using openssl s_client terminal gives direct access to server response data, including certificate chains and cipher negotiation results.

What Does the TLS Handshake Reveal?

Running openssl s_client against an SMTP server reveals whether TLS 1.2 or higher is supported, if the certificate is valid or has known issues like self-signing or expired dates, and whether the handshake fails early due to mismatched protocols or unsupported cipher suites. This command shows exactly what the server presents during the connection attempt, giving you direct visibility into security and compatibility.

TLS Version and Compatibility

You can immediately see if the server requires TLS 1.2 or higher—older versions like SSL 3.0 or TLS 1.0 are no longer considered secure and are commonly blocked by modern systems. If the handshake fails at the "Protocol" stage, it's likely due to a protocol mismatch. Tools like RFC 8996 outline current standards for secure email transport, and disabling outdated versions is an industry-standard practice.

Certificate and Error Diagnosis

The output shows the server’s certificate chain. If it’s self-signed, expired, or issued by an untrusted CA, you’ll see explicit errors—common signs of misconfiguration or phishing attempts. A valid certificate with proper chain validation means the server is likely legitimate. You’ll also see error codes like certificate verify failed or unknown CA, which point directly to trust issues. These are common in development setups or poorly maintained mail servers.

When the handshake terminates before completion, the reason is usually clear from the log. If it stops at "Cipher suite negotiation," it means the server and client can't agree on a cipher. This might happen with outdated configurations or strict TLS policies. A successful handshake ends with SSL handshake completed, showing both sides agree on a secure connection.

Let’s say you’re verifying an SMTP server for email deliverability. If it’s rejecting connections due to TLS issues, s_client helps isolate the problem. You can test your configuration before relying on it for outreach. For bulk email campaigns, catching these issues early prevents delivery failures and protects sender reputation.

How to Test an SMTP Server’s TLS Handshake Using openssl s_client

You can test an SMTP server’s TLS handshake by running openssl s_client -connect smtp.example.com:587 -starttls smtp in your terminal. If the connection succeeds, you’ll see the server’s certificate chain and a successful handshake, confirming TLS is properly configured. A failure means issues like a missing certificate, outdated cipher suite, or disabled STARTTLS are present—common causes of email delivery problems.

Step-by-step: Verify TLS with openssl s_client

Open your terminal or SSH into a Linux or macOS system with OpenSSL installed. Most modern systems include it by default; if not, install via brew install openssl (macOS) or your distro’s package manager.
Run this command: openssl s_client -connect smtp.example.com:587 -starttls smtp. Replace smtp.example.com with your actual SMTP server address. This connects to port 587 and requests a STARTTLS upgrade.
If the handshake completes, you’ll see the certificate chain, a line saying Verify return code: 0 (ok), and a prompt like 220 smtp.example.com ESMTP. This confirms the server supports TLS and presents a valid certificate.
If you see errors like SSL routines:tls_process_server_certificate:certificate verify failed, the certificate is invalid, self-signed, or the chain is broken. You may also see no peer certificate available—a sign of no TLS support altogether.
Use QUIT to exit the interactive session. This is a one-time test to catch configuration issues that prevent email delivery or trigger spam filtering.

What the results mean

A successful handshake means your server is likely correctly configured for encrypted SMTP. This is critical for deliverability—many email providers, including Gmail and Outlook, reject messages from unencrypted connections.

The 5 steps described in “Step-by-step: Verify TLS with openssl s_client”, in order.

Failures often point to missing or misconfigured certificates, outdated TLS versions (like TLS 1.0), or firewalls blocking encrypted traffic. RFC 5246 (The TLS Protocol Version 1.2) defines the standard; ensure your server supports TLS 1.2 or higher.

For teams managing large email lists, testing TLS manually helps preempt issues before they impact sender reputation. While this method is excellent for diagnostics, automate verification at scale using tools designed for bulk testing.

Verify your entire list for deliverability risks—including TLS readiness, invalid domains, and role accounts—automatically and at scale.

Interpreting openssl s_client Output: What to Look For

You’re testing an SMTP server’s TLS handshake with openssl s_client, and the output tells the real story. Look for verify return code: 0 — that means the certificate is trusted. If it’s non-zero (like 20), the cert is self-signed, expired, or doesn’t match the hostname. Watch for SSL handshake failed, often from outdated TLS or disabled ciphers. After the handshake, confirm you see DONE and a prompt like 220 smtp.example.com ESMTP — that’s the server saying it’s ready to accept commands.

Key Indicators in the Output

verify return code: 0 — This is the green light. The certificate chain is valid, trusted, and properly signed by a recognized CA. No action needed.
verify return code: 20 (or similar non-zero) — This means the server’s certificate wasn’t trusted. Common causes: self-signed certs, expired certificates, or a name mismatch (e.g., certificate for mail.example.com but connecting to smtp.example.com).
SSL handshake failed — Indicates the negotiation failed. Likely due to TLS version incompatibility (e.g., server requires TLS 1.2+, you’re using 1.1), disabled cipher suites, or a certificate rejection.
Look for DONE in the output — it signals that the TLS handshake completed successfully and the connection is now encrypted.
Confirm you see a server response like 220 smtp.example.com ESMTP — this is the SMTP welcome banner. If you don’t, the server didn’t accept the connection, even after TLS.
If you see SSL routines:tls_process_server_certificate:certificate verify failed, that’s a clear sign of a trust issue. Check the cert chain or add it to your trusted store.

What This Means for Your Sending Setup

When your TLS handshake fails or returns a non-zero verify code, your email may not reach the inbox — or may be flagged as suspicious. Even if delivery seems to work, broken TLS weakens sender reputation and increases the risk of being blocked by modern filtering systems.

For organizations sending bulk email, validating SMTP settings isn’t optional. You need to catch these issues before they tank deliverability. Tools like bulk email verification include real-time SMTP checks to surface these issues at scale.

For deeper insight into secure SMTP communication, see the TLS 1.2 specification or the official TLS cipher suite registry — they define the exact standards your server must follow.

Common TLS Handshake Failures and Their Causes

When testing an SMTP server’s TLS handshake with openssl s_client, you’ll often hit failures due to outdated configurations, expired certificates, or misrouted traffic. The most common issues involve servers not supporting STARTTLS, using invalid or mismatched certificates, running on obsolete TLS versions, or being blocked by firewalls and load balancers that terminate TLS before it reaches the actual SMTP service.

Missing or Misconfigured STARTTLS Support

Modern email systems require STARTTLS to encrypt SMTP connections. If the server doesn’t advertise or respond to the STARTTLS command, the handshake fails. This is a hard stop for most compliant clients and usually means the server is either misconfigured or using legacy settings. You can test this by connecting to port 587 and sending the STARTTLS command manually—without a reply, encryption can’t begin.

Certificate Problems Are Widespread

Even if the handshake reaches the certificate phase, it can fail due to expiration, self-signing, or domain mismatches. A certificate issued for mail.example.com won’t validate if the server presents it under smtp.example.net. Browsers and email clients will reject such connections. The same applies to self-signed certs—the vast majority aren’t trusted by default. You can check validity using RFC 5280 standards on certificate path validation.

Another frequent issue is the use of outdated TLS versions like TLS 1.0 or 1.1. These are now disabled by default in most email clients and security policies because they’re known to be vulnerable to attack. If your server only supports these versions, it will reject modern connections. The best practice is to support TLS 1.2 or higher.

Finally, infrastructure like firewalls, load balancers, or reverse proxies can terminate TLS before it reaches the SMTP server. This leads to handshake errors even if the server is properly configured. In these cases, you might see a valid certificate response—but only from the proxy, not the real mail server. You’ll need to inspect the network path from outside your infrastructure to trace where encryption is being broken.

For teams building or monitoring email systems, testing TLS early and often is essential. Tools like openssl s_client help isolate issues, but they require a clear understanding of how TLS, STARTTLS, and certificate chains work in practice. If you’re verifying lists at scale and want to ensure deliverability, use a service that validates both syntax and connectivity—like bulk email verification with real-time SMTP checks.

Why Use openssl s_client in Production Checks?

You can test an SMTP server's TLS handshake directly, reliably, and without dependencies using openssl s_client in a terminal. It's built into Linux and macOS systems by default, requires no API keys, and gives you unfiltered visibility into the TLS negotiation process—critical for diagnosing encryption issues in production.

It’s Free, Portable, and Everywhere You Need It

OpenSSL is open-source, included with every major Linux distribution and macOS, so you can run this check on any server without installing additional tools. No setup, no licensing, no hidden costs—just a terminal command and a clear view of the handshake.

Raw Access to TLS Negotiation Is Unmatched

Unlike third-party services or GUI tools, openssl s_client shows you the full TLS handshake step-by-step: the cipher suites offered, certificate chain, TLS version, and any errors. This granularity is what security and operations teams rely on during incident response or configuration audits.

For example, when investigating why an email server rejects connections, you can see if the server offers outdated TLS versions (like TLS 1.0), refuses certain certificates, or if there’s a certificate chain failure. This level of detail is often missing from automated email verification tools—even those advertised as "comprehensive."

Security teams around the world use openssl s_client as a trusted diagnostic instrument. It’s referenced in RFC 5246 (the TLS 1.2 specification) and widely documented in operational security guides from organizations like the SANS Institute and the NSA’s Cybersecurity Information Sheet.

While tools like bulk email verification services validate deliverability after the fact, openssl s_client lets you test the underlying infrastructure before sending. It’s not about verifying addresses—it’s about verifying whether your mail server can securely connect at all.

There’s no abstraction layer. No black-box API response. You see exactly what the server sends and receives. That’s why it remains a foundational tool in modern DevOps and email operations workflows.

How This Relates to Email Deliverability and Sender Reputation

When your SMTP server fails a TLS handshake, spam filters often reject your messages outright—especially if the failure is consistent. This isn’t just a technical hiccup; it sends red flags to major email providers, damaging your sender reputation and lowering inbox placement. DMARC policies can require TLS encryption, particularly when enforcing alignment, making handshake success a non-negotiable baseline.

TLS Failures Signal Weak Infrastructure

If your server fails the TLS handshake, it’s not just a one-off glitch—it’s a sign your infrastructure isn’t hardened against common threats. Email providers like Gmail and Outlook track connection reliability and security compliance. Repeated failures indicate instability, making your domain a candidate for filtering or blocklisting.

Let’s be clear: you can’t warm up a new domain or sender while TLS handshakes are failing. A poorly configured server undermines every deliverability effort. Even if your content is on-brand and your list is clean, the technical foundation is broken. Fixing this is the first step, not an optional afterthought.

DMARC, Alignment, and Enforced Security

Modern DMARC policies increasingly require transport-layer security. When a policy includes the sp=quarantine or sp=reject directive, and a domain enforces tls-require, unencrypted or improperly secured connections get blocked—even if the email itself is legitimate.

Alignment between the From header and the domain used in the encryption chain adds another layer. A failed handshake breaks this chain early, which can trigger DMARC failure reports. These reports don’t just log issues—they feed into reputation systems used by sending providers and receiving platforms alike.

A study by Return Path (now Validity) found that domains with poor security alignment had up to 30% lower inbox placement, especially in competitive sectors like e-commerce and SaaS. The data isn’t about volume alone—reputation is built on consistency, including encryption readiness.

That’s why testing the TLS handshake with openssl s_client isn’t just for troubleshooting—it’s part of ongoing reputation hygiene. Regular checks catch misconfigurations before they escalate.

If you're managing large lists or running automated campaigns, verifying the technical health of your email stack is non-negotiable. Tools like the bulk email verification feature can help you identify invalid or misconfigured addresses before they cause delivery issues—ensuring your sending infrastructure remains stable and trusted.

What Tools Can Help Beyond openssl s_client?

You can use SMTP tester tools and email-verification SaaS platforms to simplify checking TLS handshakes and delivery readiness without running terminal commands. Tools like Mail-Tester or MxToolbox provide visual dashboards that simulate message delivery and flag handshake failures, while services like Emaillistchecker.io go further with inbox-placement testing and real-time deliverability reports. These tools don’t replace OpenSSL for debugging deep issues, but they make proactive monitoring, team collaboration, and long-term trend tracking much easier.

SMTP Testing Tools: Simpler for Quick Checks

Tools such as MxToolbox or Mail-Tester let you test SMTP connections via a web interface. They show whether the TLS handshake completes and highlight common issues—like expired certificates, unsupported ciphers, or misconfigured TLS versions—without needing command-line access. This is useful for non-technical users or for quick sanity checks before sending.

Deliverability and Verification Platforms: From Tests to Fixes

For teams focused on inbox placement and sender reputation, platforms like Emaillistchecker.io offer more than just handshake testing. Their inbox-placement testing simulates real-world delivery across major providers—Gmail, Yahoo, Outlook—and reports whether your email lands in the inbox, spam, or is blocked. This is powered by sending test messages with real headers, DKIM, SPF, and TLS configuration, not just testing the connection layer. You can also verify large email lists or integrate with Mailchimp or Klaviyo via their API integrations for ongoing validation and risk reduction.

Monitoring services can track TLS handshake failures over time, detecting dips when infrastructure changes or certificate renewals fail. Unlike one-off OpenSSL calls, these tools provide historical context—something that’s critical for maintaining long-term deliverability. But when you need to see exactly where a handshake breaks down—whether the server drops the connection during the TLS handshake, or rejects an unsupported cipher—nothing beats direct openssl s_client inspection. It’s the atomic-level view. Use tools for scale, automation, and team visibility. Use OpenSSL when you need certainty.

How Emaillistchecker.io Supports SMTP and Deliverability Testing

You can test SMTP server TLS handshake behavior using openssl s_client in the terminal, but Emaillistchecker.io automates and expands on that process by validating email addresses in real-world conditions—checking for SMTP responsiveness, TLS negotiation, catch-all accounts, and deliverability risk across multiple inboxes, all without requiring command-line tools.

Simulating Real-World Delivery Conditions

When you send an email, the server doesn’t just check if an address exists—it negotiates TLS, responds to SMTP commands, and respects inbox rules. Our inbox-placement testing replicates actual delivery chains, including the TLS handshake phase, to catch failures before you send. Unlike basic syntax checks, this reveals whether your messages will be rejected due to encryption mismatches or server timeouts.

We test against known mail provider behaviors, including those documented in RFC 5248, which outlines secure SMTP practices. This ensures your list isn’t just valid—it’s accepted.

API and Bulk Verification with Real-World Context

Our real-time verification API doesn't just return "valid" or "invalid." It checks if the receiving mail server responds at all, whether it supports TLS, and how quickly it replies. This means you catch domains that may technically accept mail but fail in production due to configuration issues—like outdated TLS versions or greylisting.

We flag risky domains, catch-all addresses, and role accounts (like admin@ or support@), which often don’t handle TLS or authentication the same way as personal inboxes. These are common sources of bounce and spam filtering, and our system identifies them preemptively.

You can test deliverability across multiple mailbox providers—Gmail, Outlook, Yahoo, and more—from a single dashboard. This gives you visibility into how your message appears in real user inboxes, not just server logs.

For teams managing large lists, bulk verification at scale—complete with TLS and SMTP validation—is available at https://www.emaillistchecker.io/bulk-verification. The same verification logic powers our API for real-time checks, found at https://www.emaillistchecker.io/api. Both integrate with platforms like Mailchimp, HubSpot, and SendGrid via our integrations page: https://www.emaillistchecker.io/integrations.

Test, Validate, and Stay Secure: A Final Checklist

You can verify your SMTP server’s TLS handshake in real time using openssl s_client with the correct flags: -connect to the server and port, and -starttls smtp. This confirms TLS negotiation, certificate validity, and session completion—critical for secure email delivery. Use it before sending to ensure your infrastructure meets current security standards, especially when setting up or debugging outbound email systems.

Test with the Actual SMTP Endpoint

Always connect to the real SMTP server address and port—commonly 587 for STARTTLS or 465 for implicit TLS—never a test or mock endpoint.
Use the exact domain and port configuration from your mail provider (e.g., smtp.gmail.com:587).
Never assume encryption is enabled just because the port suggests it—validate it through the TLS handshake.

Verify TLS and Certificate Integrity

Run openssl s_client -connect smtp.example.com:587 -starttls smtp to initiate a real handshake and observe the TLS version.
Confirm the certificate is issued by a trusted CA and matches the server domain—no certificate errors or warnings.
Ensure the server supports at least TLS 1.2; avoid older versions like TLS 1.0 or 1.1, which are deprecated and insecure.
Check your server logs after the test to confirm the session completed with a successful 220 response and proper TLS negotiation.
Use tools like SSL Labs’ SSL Test to validate your server’s TLS configuration at scale, including cipher suite strength.

Even if your server passes the OpenSSL test, real-world email delivery depends on more than just TLS. Misconfigured SPF, DKIM, or DMARC records can still cause rejection—even if the handshake succeeds. Use inbox placement testing to verify end-to-end deliverability, including spam filter alignment, sender reputation, and inbox placement. You can’t trust a secure handshake if your message is marked as spam.

Conclusion: Keep Your Email Infrastructure Reliable

Testing the TLS handshake is not optional—it’s a baseline requirement for ensuring your email infrastructure remains secure and deliverable. Ignoring it invites risks from misconfigured servers, expired certificates, or encryption gaps.

Using openssl s_client in the terminal provides the most reliable manual verification method, giving you direct insight into handshake behavior without abstraction. It’s the gold standard for diagnosing TLS-level issues in real time.

Pair this manual check with automated list verification through tools like Emaillistchecker.io. Clean lists combined with secure connections reduce bounces, avoid blocklists, and protect sender reputation. Fixing handshake errors early prevents delivery failures and long-term reputational damage.

Sources

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)
By early 2026, 937,931 of 1.8 million analyzed domains had valid DMARC records — up 79% in three years — but about 56% of them still sit at monitoring-only p=none. — DMARC Report (EasyDMARC 2026 data) (2026)

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 'SSL handshake failed' mean in openssl s_client?

It means the client and server could not negotiate a secure connection. Common causes include unsupported TLS version, expired certificate, or misconfigured server.

Can I test TLS on port 25 with openssl s_client?

Yes, but only if the server supports STARTTLS on port 25. Most modern servers now require port 587 for TLS-protected connections.

How do I know if my SMTP server supports TLS 1.2?

Use openssl s_client with -starttls smtp. If the handshake completes with a valid certificate, TLS 1.2 or higher is supported.

Why does my email not send even if the TLS handshake passes?

A successful handshake only confirms encryption. Other issues — like authentication failure, blocked sender IP, or spam filtering — can still prevent delivery.

Do I need to install anything to run openssl s_client?

No — it’s preinstalled on most Linux and macOS systems. On Windows, use WSL or install via package managers like Chocolatey.

Can I script openssl s_client for regular checks?

Yes. Wrap the command in a shell script to automate testing across multiple domains or servers.

Does Emaillistchecker.io test SMTP TLS handshakes?

Not directly in the terminal, but our inbox-placement and deliverability tests simulate real-world TLS-protected sending conditions.

What’s the difference between STARTTLS and implicit TLS?

STARTTLS upgrades an existing unencrypted connection to encrypted. Implicit TLS uses encryption from the start — common on port 465.

Why does openssl s_client show 'verify return code: 20'?

Code 20 means the certificate is self-signed. It’s not trusted by default. Use a valid CA-signed cert for production use.

Can a catch-all email domain pass a TLS handshake test?

Yes — the handshake is server-level, not address-level. A catch-all domain can still establish TLS, but the delivery may fail at the address level.

How often should I test my SMTP server’s TLS readiness?

Test after configuration changes, before launching a campaign, or when deploying to new infrastructure. Quarterly checks are a minimum for stability.

Is it safe to run openssl s_client on production mail servers?

Yes, if you’re not sending mail or overloading the server. It’s a diagnostic tool that doesn’t modify state — use during low-traffic periods for best results.