Diagnose SMTP TLS Issues | Emaillistchecker.io

Why Your Emails Aren't Connecting: Understanding SMTP TLS Failures

You sent an email. It didn’t bounce. But it also didn’t arrive. No delivery error, no notification—just silence. This is a common symptom of an underlying SMTP TLS failure. The connection between your server and the recipient’s mail server failed during encryption handshake, even though the email address and routing were correct.

Think of TLS as a secure handshake: both sides must agree on encryption method, trust the certificate, and complete the exchange in time. If either side fails—due to expired certs, outdated cipher suites, or mismatched TLS versions—the handshake collapses. No handshake, no delivery. The server simply refuses to process the message.

Diagnosing SMTP TLS issues using openssl s_client server check gives you direct visibility into what’s failing. You don’t need to guess. This article walks through the exact steps to uncover SSL/TLS misconfigurations, identify the root cause, and fix them before they hurt deliverability.

Key takeaways

SMTP TLS failures occur when the encryption handshake between sending and receiving mail servers fails due to expired certificates, unsupported cipher suites, or TLS version mismatches.
Using openssl s_client to test a server’s TLS configuration reveals real-time handshake results, including certificate validity, supported protocols, and cipher suite negotiation.
Even a single unresolved TLS issue can prevent message delivery or trigger spam filters—making diagnosis essential for consistent inbox placement.

How to Diagnose SMTP TLS Issues Using OpenSSL s_client Server Check

You can diagnose SMTP TLS issues by running openssl s_client directly on your server or a test machine. Target the SMTP port (587 for STARTTLS, 465 for SSL), use -starttls smtp when testing port 587, and inspect the handshake, certificate chain, and any error messages in the output to pinpoint failures like expired certs, misconfigured TLS versions, or rejected connections.

Run the Command with Proper Flags

Open a terminal on your server or a machine with OpenSSL installed. Run openssl s_client -connect mail.example.com:587 -starttls smtp to test STARTTLS on port 587. If testing SSL (port 465), omit -starttls smtp and just use -connect.
For debugging SSL/TLS handshake issues, add -debug to see detailed protocol negotiation steps. This helps identify where the connection fails—whether during certificate exchange, cipher negotiation, or server response.
Check the output for lines like SSL connect OK or Verification: OK. A successful handshake means the server accepts your connection and presents a valid certificate chain.
Look for explicit errors like SSL routines:tls_process_server_certificate:certificate verify failed or no certificate returned. These indicate issues with server certificate trust, configuration, or a missing certificate.
If you see unknown protocol or server sent fatal alert: handshake failure, the server may reject your TLS version (e.g., TLS 1.0/1.1) or a specific cipher suite. Use -ciphers to test specific TLS combinations.

Validate Certificates and Identify Common Misconfigurations

After a handshake attempt, scroll through the certificate details printed in the output. Ensure the subject CN matches your intended server domain. If it doesn’t, you may be connecting to a misconfigured server or a man-in-the-middle.

The 5 steps described in “Run the Command with Proper Flags”, in order.

Use RFC 5246 as a reference for TLS 1.2 and later requirements. Many ISPs and email services now require at minimum TLS 1.2.

If you’re testing a mail relay or third-party email service, check MxToolbox for public SMTP diagnostics. It can confirm whether a server’s TLS configuration is known to be problematic.

For email list validation, use bulk email verification to catch invalid or non-responsive addresses before sending. This reduces failed delivery attempts due to misconfigured or inactive mail servers.

Interpreting OpenSSL s_client Output: What Each Line Means

You can diagnose SMTP TLS issues by checking the output of openssl s_client — a failed certificate verification means the server’s certificate is self-signed or untrusted, a handshake failure usually points to a TLS version mismatch, and a connection closed without a handshake suggests a firewall or configuration block. The line-by-line output reveals the root cause, not just a generic error.

Certificate Verification Failures

If you see “verify error” or “certificate verification failed,” the server’s SSL certificate isn’t trusted by your system’s certificate store. This happens with self-signed certs, expired certificates, or misconfigured domains. It’s not always a problem — internal or staging servers often use self-signed certs. But for production email delivery, this is a red flag. You can force verification bypass for testing (not for production), but always confirm the cert’s issuer and validity using tools like crt.sh to inspect certificate chains.

Handshake or Connection Errors

A “handshake failure” means the client and server couldn’t agree on a secure connection. The most common cause is a TLS version mismatch — your client supports TLS 1.2 or higher, but the server only offers TLS 1.0 or 1.1, which are deprecated. The RFC 8996 standard explicitly deprecates older versions, so ensuring both ends support modern protocols like TLS 1.2 or 1.3 is essential for reliable communication.

If the connection closes immediately with no handshake, the issue is likely network-level. A firewall might be dropping the request, or the SMTP server may be misconfigured to reject incoming TLS negotiation. Unlike a certificate error, this shows no communication from the server, meaning the problem is not in the certificate but in the network path or server setup. Use a tool like MxToolbox to check if the server is publicly reachable and responding on port 587 or 465.

When troubleshooting, start by testing the command from multiple locations — your local machine, a cloud server, or a different network. That helps determine if the issue is local or server-side. You can also check the server’s configuration using standard tools like IANA’s port registry to confirm expected SMTP behavior.

For teams managing large email lists or automating deliveries, validating TLS readiness at scale is critical. Misconfigurations here directly impact deliverability. Tools like the bulk verification feature in EmailListChecker.io help catch issues before they affect campaigns, ensuring only properly configured, deliverable addresses are sent to.

Common TLS Problems Detected by s_client and How to Fix Them

You can diagnose SMTP TLS issues with openssl s_client by connecting to the mail server’s port (587 or 465), inspecting the certificate chain, and verifying supported protocols and ciphers. Common issues include expired certs, incomplete chains, outdated protocols, or misconfigured ciphers. Fixing them requires adjusting server configuration, not just guessing.

Checklist: Diagnose and Resolve TLS Issues

Check for expired certificates using openssl s_client -connect mail.example.com:587 -servername example.com. If the output shows verify return:10 with certificate has expired, renew the certificate at the server level.
Ensure the full certificate chain is sent. If intermediate certificates are missing, users get unable to get local issuer certificate. Upload all intermediates from root to end-entity, ordered correctly (leaf → intermediate → root).
Disable outdated protocols. TLS 1.0 and 1.1 are deprecated. Configure your server to reject them—only allow TLS 1.2 or 1.3. Use RFC 8996 as a reference for current best practices.
Verify supported cipher suites. If your server lists weak or outdated ciphers, they may be rejected. Use testssl.sh (available at testssl.sh) to test and align supported ciphers on both server and client.
Test your SMTP setup after changes. Use s_client again to confirm the certificate chain is complete, protocols are enforced, and the handshake completes without warnings.
Monitor for mixed content or redirect issues. Some mail servers redirect from port 25 to 587 or 465—ensure your client follows redirects and retries with the correct port.

Verifying the Certificate Chain and Trust Path

When diagnosing SMTP TLS issues with openssl s_client, examine the full certificate chain from the server to a trusted root CA. If the chain ends before reaching a known root, the server is missing one or more intermediate certificates, which breaks trust and causes TLS failures. Use tools like testssl.sh to validate the complete trust path and detect any missing links.

How OpenSSL s_client Reveals Chain Gaps

You’ll see the chain in the output when you run openssl s_client -connect smtp.example.com:587 -servername example.com. The server sends its certificate, followed by any intermediate certificates up to the root. If it stops short — say, at an intermediate — trust can’t be established.

Let’s say your output ends with a certificate from DigiCert, but no root. That signals a missing intermediate. Some hosts skip intermediates intentionally, or misconfigure their cert bundles. This isn’t just a warning — it’s a hard failure in most clients, including mail servers.

Validating the Full Trust Path with Real Tools

OpenSSL shows the raw chain, but tools like testssl.sh (by Frank Wueest) automate chain validation and highlight gaps. It checks not just presence, but validity, expiration, and chain completeness — all visible in a single report.

Some services still accept mail from misconfigured servers, but many modern MTAs reject connections if the chain is incomplete. This leads to hard bounces and poor inbox placement. Fixing the certificate chain is a standard step in securing SMTP delivery.

Even if your SMTP server appears to connect, a broken trust path means mail could be flagged as potentially forged. This affects sender reputation and deliverability. You can verify your setup with public testing tools or, if you're managing a large list, use bulk verification to assess email reliability at scale.

Testing TLS on Multiple Ports: 25, 587, and 465

Use openssl s_client to diagnose SMTP TLS issues by testing each port with the correct flag: port 25 with no extra flag (but check if TLS is enforced), port 587 with -starttls smtp, and port 465 with direct connection—no STARTTLS. This reveals handshake failures, cipher mismatches, or expired certificates.

Port 25: Relay Mode, Often TLS-Required

Connect with openssl s_client -connect mail.example.com:25—no TLS flag needed.
Observe the server’s initial response. If it offers STARTTLS, the connection is negotiable.
If the connection drops immediately or rejects the connection, the server may require TLS or block plain-text relay entirely—common for modern mail providers.
Check RFC 5321 for standard SMTP behaviors and port 25 usage in modern environments.

Port 587: Submission with STARTTLS

Use openssl s_client -connect mail.example.com:587 -starttls smtp to test TLS negotiation.
Verify the server responds with 220 and then upgrades to TLS using the STARTTLS command.
If the handshake fails or you get a bad certificate error, check if the certificate is valid, trusted, or missing from the client trust store.
Many ISPs and cloud services (like AWS SES, SendGrid) enforce encryption on port 587—but may reject unencrypted or misconfigured requests.

Port 465: Implicit SSL (Legacy, Rare)

Test with openssl s_client -connect mail.example.com:465—no -starttls flag.
Port 465 uses implicit TLS, meaning the TLS handshake begins immediately.
Failure here often means the server doesn't support the required cipher suite or has an incomplete certificate chain.
While defined in RFC 3207, support for port 465 is declining in favor of STARTTLS on port 587.

Real-world SMTP delivery fails fast when TLS isn’t properly negotiated—check all three ports to isolate where the issue lies.

Real-World Example: A Failed TLS Handshake in Action

When testing an SMTP server on port 587 with openssl s_client, you get an error: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure. This means the TLS handshake failed, usually due to a cipher suite mismatch or outdated TLS version support. Let’s walk through how to diagnose and fix it using OpenSSL’s diagnostic tools.

Identifying the Root Cause

When a TLS handshake fails, the first step is to isolate whether the issue is version-based or cipher-related. The error code alone doesn’t tell you much — you need deeper inspection. Running openssl s_client -connect example.com:587 -starttls smtp without further flags shows the failure but not why. This is where the -ciphers flag becomes crucial.

Testing Cipher Suite Compatibility

Run the same command with -ciphers 'HIGH'. If the server now connects successfully, it confirms that the original failure was due to weak or unsupported cipher suites. In practice, this often means the server only supports legacy ciphers like DES-CBC3-SHA or RC4-SHA — algorithms known to be insecure and deprecated in modern security standards.

Check the server’s supported ciphers using openssl s_client -connect example.com:587 -starttls smtp -ciphers "DEFAULT". The output will show the exact list the server is willing to negotiate. If it's dominated by DES, RC4, or MD5-based ciphers, you’ve found the problem: the server refuses modern, secure handshake options.

According to the NIST SP 800-131A, these older algorithms should no longer be used in new systems. A server that doesn’t support TLS 1.2 or 1.3 with modern authenticated encryption (like ECDHE-RSA-AES256-GCM-SHA512) is not just outdated — it’s a security risk.

Resolving the Issue

Fix the server configuration by updating its TLS settings. For example, in Postfix or Exim, adjust the smtpd_tls_ciphers or tls_ciphers directive to include only secure, modern ciphers. A safe baseline is ECDHE-RSA-AES256-GCM-SHA512 or DEFAULT@SECLEVEL=2 (which disables weak ciphers by default).

After applying the update, retest with openssl s_client to verify the handshake now completes cleanly with a modern cipher. You can also use tools like SSL Labs’ SSL Test to monitor progress and ensure no vulnerabilities remain.

For teams managing large email lists or sending workflows, verifying TLS health isn’t just about security — it’s about deliverability. A misconfigured server can lead to rejections, poor inbox placement, or inclusion on blocklists. At Emaillistchecker.io’s inbox placement tool, we test deliverability across providers, where encryption compatibility is a key success factor.

Using Emaillistchecker.io’s Deliverability Testing to Spot TLS Weaknesses

You can diagnose SMTP TLS issues using openssl s_client, but real-world delivery failures often stem from how your server responds in live exchange scenarios. Emaillistchecker.io’s inbox-placement testing runs actual SMTP handshakes across multiple recipient domains to identify TLS rejection, weak cipher suites, or handshake timeouts that standard OpenSSL checks might miss. It shows you not just if TLS is supported—but how reliably it is enforced in practice.

Simulating Real Delivery Conditions

Unlike local OpenSSL tests, which only verify one endpoint, Emaillistchecker.io conducts full delivery simulations across major email providers. It connects to actual mail servers—like Gmail, Outlook, and Yahoo—and performs the full SMTP handshake, including the STARTTLS negotiation. This reveals whether your server is being blocked due to outdated TLS versions, unsupported ciphers, or misconfigured certificate chains.

For example, a server might pass openssl s_client -connect example.com:587 -starttls smtp locally but fail in practice because the receiving server rejects TLS 1.0 or enforces certificate validation stricter than the test suite allows. Emaillistchecker.io surfaces these discrepancies with explicit error messages, such as “TLS version unsupported” or “certificate chain incomplete.”

What This Reveals That OpenSSL Alone Cannot

OpenSSL s_client is great for verifying local server behavior, but it doesn’t reflect how your server is perceived by real-world mail providers. Many receivers use reputation-based filtering, which means misconfigured TLS—even if technically functional—can still flag your outbound mail as risky. Emaillistchecker.io’s testing detects not just technical flaws, but also signs of instability that lead to delivery drops or inbox placement issues.

It’s also useful for validating changes. After updating your TLS config, you can run a new inbox placement test to see if recipients now accept your messages without rejection. This builds confidence faster than relying solely on local OpenSSL tests, which can’t confirm whether a change improves deliverability in real inboxes.

For teams managing large email campaigns or transactional flows, this kind of testing fills a critical gap. It goes beyond syntax checks to assess performance under live conditions—an industry-standard practice recognized by email infrastructure providers. Tools like RFC 5321 (SMTP) and RFC 6066 (TLS extension) define the behaviors you’re testing, and real-world verification ensures compliance goes beyond theory.

When you need a full picture of SMTP handshake behavior and TLS health, Emaillistchecker.io’s inbox-placement test is the only tool that combines technical validation with real-world delivery simulation. It’s the next step after OpenSSL—you’re not just checking if TLS works. You’re confirming whether it works well enough to get into inboxes.

A Note on SMTP Server Security: Best Practices Beyond OpenSSL

Using openssl s_client is a solid first step to diagnose SMTP TLS issues, but it’s only part of the story. You also need to ensure your server uses valid, current certificates from trusted CAs, regularly checks TLS configuration via automated tools, and enforces encryption on all outbound messages to prevent data leaks and ensure compliance. Don’t treat diagnostics as a one-time fix—build ongoing security hygiene.

Secure Your SMTP Server with Proactive Practices

Always use up-to-date SSL/TLS certificates issued by trusted Certificate Authorities like Let’s Encrypt or DigiCert. Expired or self-signed certs break client trust and cause delivery failures.
Regularly audit your server’s TLS configuration using tools like Qualys SSL Labs (https://www.ssllabs.com/ssltest/)—they provide detailed reports on cipher suites, protocol versions, and potential weaknesses.
Never send email in plaintext. Enforce TLS encryption for all outbound SMTP connections by default—this applies to both internal mail relays and third-party senders.
Disable outdated cryptographic protocols such as SSLv3, TLS 1.0, and TLS 1.1. Only support TLS 1.2 or higher to prevent interception risks.
Monitor certificate expiry dates proactively. A single expired certificate can trigger widespread delivery failures, especially with strict email gateways.
Verify that your SPF, DKIM, and DMARC records are correctly published and aligned. These don’t cover TLS, but they’re part of the same delivery trust stack.

Automate and Verify Real-World Deliverability

OpenSSL checks help diagnose connection-level TLS issues, but real-world inbox placement depends on more than just encrypted handshakes. Your sender reputation, list hygiene, and content quality matter too.

For example, sending to a high volume of invalid, role-based, or disposable email addresses will trigger spam filters—even with perfect TLS. Clean lists help avoid these traps. Use a verified email list to ensure your messages reach real inboxes.

Consider testing your deliverability in real conditions with inbox placement tools. These simulate real customer inboxes and reveal whether your messages are landing in the main folder, spam, or being throttled.

You can test and verify your email list quality using a reliable bulk verification tool like bulk email verification—which checks for invalid, role-based, and disposable addresses—so your campaigns start from a clean, trusted base.

When to Use OpenSSL vs. Tools Like Emaillistchecker.io

You should use openssl s_client when you need real-time, granular insight into a single SMTP TLS handshake—like when debugging a specific connection failure. For ongoing list health, deliverability trends, or large-scale TLS status across domains, Emaillistchecker.io automates the process with bulk verification and inbox-placement testing, saving time and reducing human error.

OpenSSL: Precision for Debugging Individual Connections

Let’s say your email server consistently fails to deliver to one domain. Running openssl s_client -connect domain.com:587 -starttls smtp gives you a full view of the TLS handshake: certificate chain, cipher suite used, hostname verification, and any error messages that appear during negotiation. This low-level visibility is essential when diagnosing issues like expired certs, mismatched hostnames, or misconfigured cipher policies.

The TLS 1.2 specification defines the handshake flow—OpenSSL shows you if that flow is disrupted at any step. While powerful, it requires manual work per domain and doesn’t scale well for large lists or long-term monitoring.

Emaillistchecker.io: Automation at Scale

Once you’ve pinpointed the issue with OpenSSL, shift to Emaillistchecker.io for ongoing assurance. It runs comprehensive checks across thousands of email addresses using real-time deliverability data and historical sender reputation trends. The bulk verification feature checks TLS status, deliverability signals, and risk flags across your entire list in minutes.

It’s not just about TLS. Emaillistchecker.io also flags catch-all domains, disposable emails, and role accounts—common causes of poor inbox placement. For teams sending regularly, this automation replaces repetitive manual checks and integrates with platforms like Mailchimp, HubSpot, and SendGrid to keep your list clean.

Think of OpenSSL as your diagnostic tool—ideal for a single fault. Emaillistchecker.io is your monitoring system—built for sustained performance and real-world deliverability outcomes.

Conclusion: Proactively Diagnose and Fix SMTP TLS Configurations

SMTP TLS issues are a primary cause of email delivery failure. Misconfigured handshakes, expired certificates, or unsupported cipher suites can block messages before they reach the inbox.

OpenSSL s_client provides the most direct, unmediated access to diagnose TLS handshake problems. By inspecting the server’s response in real time, you can identify failures with precision — no assumptions, no black boxes.

For sustained deliverability, combine low-level diagnostics with regular inbox-placement testing. Use tools like Emaillistchecker.io to validate your email list, monitor sender reputation, and ensure your messages consistently arrive in the inbox.

Sources

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)
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)

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 'handshake failure' mean in OpenSSL s_client output?

It means the client and server could not agree on encryption settings. This is often due to incompatible TLS versions or cipher suites.

Can I test TLS without access to the server?

Yes, you can test from your client machine using s_client against the public mail server address, but only if the server allows external connections.

Why does my email get blocked even with TLS enabled?

TLS is required, but not sufficient. Issues like outdated ciphers, self-signed certs, or poor sender reputation can still block delivery.

Does Emaillistchecker.io test TLS encryption?

Yes. Its deliverability tests evaluate TLS handshake success and certificate validity during simulated outbound sends.

What ports should I test for SMTP TLS?

Test port 587 (via STARTTLS) and port 465 (SSL). Port 25 is legacy and often blocked or encrypted-only.

How do I fix a certificate verification error?

Ensure the server sends a full chain to a trusted CA. Replace self-signed certs with properly issued ones.

Is OpenSSL s_client free and safe to use?

Yes. OpenSSL is open-source, widely trusted, and runs locally—no external data is sent during testing.

Can I automate s_client checks across multiple domains?

Yes, with shell scripts or custom tools. Emaillistchecker.io offers automated bulk delivery checks without scripting.

What's the difference between STARTTLS and SSL?

STARTTLS upgrades an unencrypted connection to TLS. SSL starts with encryption. STARTTLS uses port 587; SSL uses port 465.

How often should I test my SMTP TLS setup?

Test after any configuration change, and periodically (e.g., monthly) to catch drifting or expired certificates.

Can a valid TLS handshake still result in rejected emails?

Yes. Even with TLS, messages may be rejected due to spam filtering, bad sender reputation, or blacklisting.

Is using Emaillistchecker.io better than manual s_client checks?

It complements them. s_client provides deep diagnostics. Emaillistchecker.io scales testing across domains for deliverability accuracy.