Debug SMTP TLS with OpenSSL s_client

Why Is SMTP TLS Certificate Debugging Essential for Email Deliverability?

You send an email, and 12 hours later, it’s still in the queue. No bounce, no error—just silence. It’s not spam. It’s not blocked. It’s just… stuck. The problem? A broken TLS handshake between your server and the recipient’s SMTP endpoint.

TLS certificates are the handshake behind secure email delivery. When they’re expired, misconfigured, or mismatched, the connection fails. And when that happens, your email doesn’t just get delayed—it can be silently dropped, eroding your sender reputation and inbox placement over time.

This guide walks you through debugging SMTP TLS certificate issues using openssl s_client, one of the most reliable tools for diagnosing connection-level failures. You’ll learn how to identify handshake errors, validate certificate chains, and catch issues before they impact deliverability.

Key takeaways

TLS handshake failures are a leading cause of silent email delivery failures, especially with third-party SMTP services.
Expired, self-signed, or mismatched certificates commonly trigger SMTP connection drops without clear error messages.
Proactively testing TLS configurations with openssl s_client prevents sender reputation damage and maintains inbox placement.

What Does 'Debugging SMTP TLS Certificates' Actually Mean?

Debugging SMTP TLS certificates means verifying that a mail server’s SSL/TLS certificate is valid, trusted, and correctly presented during the SMTP handshake. You’re testing whether the certificate chains properly, hasn’t expired, matches the server’s domain, and allows a successful encryption handshake — all without sending an email. Tools like OpenSSL’s s_client let you simulate this process exactly as an email client would.

The Core Checks in SMTP TLS Verification

When you debug a certificate, you’re not just checking for a green padlock. You’re looking for a working chain of trust: the server’s certificate must be signed by a CA (Certificate Authority) in your trust store. If the chain is broken, TLS fails. You’ll see errors like "self-signed" or "unable to verify certificate." A certificate that’s expired or doesn’t match the hostname (e.g. mail.example.com vs. example.com) also triggers rejection.

Encryption success is another checkpoint. The handshake must complete with a cipher suite that both client and server support. This is where OpenSSL s_client shines — it mimics a real SMTP client without requiring a mail server, showing you the TLS negotiation step by step.

Why This Matters for Email Deliverability

Even if your message content is perfect, a broken TLS handshake can result in your email being silently rejected or flagged as suspicious by receiving servers. The absence of valid TLS — especially for modern, security-focused inboxes — reduces sender reputation and harms inbox placement.

While you can use tools like OpenSSL directly for debugging — and it’s still the most reliable method — the process is manual and requires interpreting output. For teams managing large-volume sending, integrating automated verification early in the workflow is more efficient. Our bulk verification tool checks email addresses for validity, including domain-level issues like TLS problems, before you ever send.

Understanding this layer isn’t just about certificates — it’s about ensuring your infrastructure meets the baseline expectations of modern email systems. You’re not just sending mail; you’re proving your server is trustworthy, authenticated, and capable of secure communication.

How to Test SMTP TLS with OpenSSL s_client — Step by Step

Run openssl s_client -connect smtp.example.com:587 -starttls smtp to test STARTTLS on port 587, or openssl s_client -connect smtp.example.com:465 -crlf for implicit TLS on port 465. Check the certificate chain, verify the issuer, confirm valid dates, and look for Verify return code: 0 — this means the certificate is accepted without issues. This test is trusted by network engineers and security teams worldwide as a core diagnostic step.

Open a terminal or command-line interface. You'll need OpenSSL installed — it's standard on Linux, macOS, and available via WSL or Windows Subsystem for Linux.
Run the STARTTLS test: openssl s_client -connect smtp.example.com:587 -starttls smtp. This simulates how your email client connects using TLS after the initial SMTP handshake. The -starttls smtp flag tells OpenSSL to negotiate TLS after the SMTP protocol starts.
For port 465 (implicit TLS), use: openssl s_client -connect smtp.example.com:465 -crlf. This mode establishes TLS immediately. The -crlf flag ensures line endings match SMTP expectations.
After the connection attempts, examine the output. Look at the certificate chain — OpenSSL shows the full path from the server’s certificate to a trusted root. A complete, unbroken chain is required for trust.
Verify the issuer. The certificate should be issued by a recognized Certificate Authority (CA), such as Let’s Encrypt, DigiCert, or Cloudflare. Certificates from self-signed or unknown CAs will fail verification unless manually trusted.
Check validity dates. The certificate must be within its valid period — not expired and not yet active. Invalid dates cause immediate rejection.
Look for Verify return code: 0 at the end of the output. It means OpenSSL successfully verified the certificate chain and trust path. Any non-zero return code indicates a failure — either expiration, issuer mismatch, or missing intermediate.

The 7 steps described in “How to Test SMTP TLS with OpenSSL s_client — Step by Step”, in order.

Common Issues and What They Mean

Return codes like 21 (unable to verify the first certificate) often indicate a missing intermediate CA. A 20 (unable to get local issuer certificate) suggests your system’s CA store is outdated or incomplete. On Unix-like systems, update your CA bundle via sudo apt-get update && sudo apt-get install ca-certificates or equivalent.

For more robust testing, consider using tools like RFC 5246 (TLS 1.2) as a reference for expected behavior. TLS validation is an industry-standard requirement for secure email delivery, and OpenSSL remains the reference implementation.

If you’re troubleshooting deliverability for a list of email addresses, ensure your sender setup matches standards. For example, invalid TLS configurations can trigger email blocks or routing issues. Use tools like our bulk email verification service to check entire lists for valid configurations and email health — before you send.

What to Look for in the OpenSSL s_client Output

When debugging SMTP TLS certificates with openssl s_client, focus on four key details: the verify return code, subject and issuer alignment, certificate validity dates, and subjectAltName/CN matching. A return code of 0 means the certificate chain was accepted. The subject and issuer must match the expected domain and a trusted Certificate Authority. Check that notBefore and notAfter dates include today’s date. A mismatch in CN or subjectAltName will cause the connection to fail.

Verify Return Code

Verify return code: 0 means the certificate chain was verified successfully and the connection is trusted. Any other code indicates a failure in the chain.
If you see codes like 20, 21, or 22, the certificate is expired or not trusted — common when the CA root is missing or outdated.
Use OpenSSL’s official documentation to look up the exact meaning of any return code.

Subject, Issuer, and Validity

The subject field must match the domain you're connecting to. For example, if you’re connecting to smtp.company.com, the CN or subjectAltName should reflect that.
The issuer must be from a widely trusted CA like Let's Encrypt, DigiCert, or Sectigo. If the issuer is self-signed or unknown, the chain fails.
Check notBefore and notAfter — a certificate outside those dates will not be accepted, even if the chain looks good. A common cause of connection issues.
If the subjectAltName doesn't include the domain or includes a wildcard mismatch (e.g., *.example.com vs. mail.example.com), the connection will reject the certificate.
Let’s say the certificate says CN=mail.example.com, but you're connecting to smtp.example.com — unless subjectAltName includes smtp.example.com, it will fail.

Always compare the certificate’s domain fields against the actual SMTP server you're connecting to — a single mismatch in CN or subjectAltName breaks TLS negotiation.

Use these checks to isolate whether an SMTP TLS failure is due to expired, misconfigured, or untrusted certificates. A clear, unbroken chain with proper validation fields is required for secure connections. If you’re troubleshooting email deliverability or SMTP issues in production, validating certificate trust chains like this is a critical step. You don’t need to be a cryptography expert — just follow the output step by step. For large-scale email list validation, ensure your sender infrastructure has trusted, valid certificates. Tools like bulk verification can help identify domains with issues before they impact deliverability.

Common TLS Certificate Failures and Their Fixes

You’ll encounter TLS certificate issues in SMTP when a server presents an expired, self-signed, incomplete chain, or domain-mismatched certificate. These cause handshake failures, mail rejection, or security warnings. Fixing them requires validating the certificate chain, ensuring correct subject names, and using CA-issued certificates for public mail servers. Tools like OpenSSL s_client help isolate the root cause.

Expired or Self-Signed Certificates

If your SMTP server returns a "certificate has expired" error, renew the certificate before the expiration date. Most public email providers block connections to servers with outdated certs. A self-signed certificate works for internal testing but fails with external servers because it’s not trusted by default. For public mail delivery, swap it for a certificate from a recognized Certificate Authority (CA), like Let’s Encrypt or DigiCert.

According to RFC 5280, a certificate must be valid at the time of verification. Using outdated or untrusted certs breaks SMTP security expectations. You can verify validity manually with OpenSSL: openssl s_client -connect mail.example.com:587 -servername example.com. If it fails, the certificate is likely expired or invalid.

Incomplete Chain or Domain Mismatch

If the certificate chain is incomplete, your server sends only the end-entity cert, missing intermediate CA certificates. This breaks trust validation—many mail servers reject such connections. Ensure your server configuration includes the full intermediate chain, properly ordered, during TLS handshake. You can test this with openssl s_client -connect smtp.example.com:587 -servername example.com -servername example.com -showcerts and inspect the output for gaps.

A domain mismatch happens when the certificate’s Subject Alternative Name (SAN) does not include the domain your client is connecting to. For example, a cert for example.com won’t validate if you’re connecting to mail.example.com. Always include all required domains in SANs when issuing a certificate. This is especially critical for multi-domain mail setups.

Use tools like SSL Labs’ SSL Test (https://www.ssllabs.com/ssltest/) to check your SMTP server’s TLS configuration in real-world conditions. It detects missing chains, SAN mismatches, and weak ciphers. When in doubt, replace any self-signed or expired cert with one from a trusted CA and validate the full chain.

For ongoing verification of email delivery health—including TLS readiness—automate checks with a tool like the inbox placement test to measure real-world delivery performance across major providers.

You can catch TLS-related SMTP handshake failures before they impact your deliverability by verifying email lists at scale and testing connectivity early. Tools like Emaillistchecker.io reduce the risk of certificate mismatches, invalid domains, or unresponsive mail servers by filtering out problematic addresses before you send. This avoids wasted bandwidth and protects your sender reputation.

Bulk Verification Catches Invalid Addresses Early

When you send to a large list without cleaning it first, some addresses will fail during the SMTP handshake—especially if the server doesn’t support TLS or has misconfigured certificates. Each failed attempt can trigger rate limits or blacklist warnings. Bulk verification tools check every email for basic validity, domain existence, and SMTP responsiveness, filtering out addresses that would cause TLS handshakes to fail. That means fewer rejected connections and a smoother outbound flow.

For example, if a domain has a self-signed or expired certificate, the server will drop the connection early. Emaillistchecker.io detects these cases during verification and reports them, so you don’t waste sends on addresses that won’t accept delivery.

AI Assistant Flags Patterns in Delivery Failures

When you send to thousands of emails, inconsistent failures can be hard to trace. An AI assistant like the one in Emaillistchecker.io can spot recurring patterns—like repeated TLS handshake timeouts, certificate errors, or domain-level rejections—and suggest possible causes. It doesn’t replace your own debugging, but it surfaces issues faster than manual log review.

For instance, if 20% of emails to @example.com fail with “certificate mismatch,” the tool can flag that domain for further inspection. The pattern might reveal a misconfigured mail server, a certificate with the wrong DNS name, or a proxy redirecting traffic. This gives you a data-backed starting point for fixing the underlying issue.

API Verification Tests Connectivity Upfront

Your email verification shouldn’t stop at checking syntax. The real-time API checks whether a domain’s mail server is actually reachable—and whether it supports TLS negotiation. It simulates the full SMTP handshake, including certificate validation, and returns whether the connection can be established securely.

By integrating this API into your sending workflow, you can test addresses before they’re used in campaigns. This is how tools like Emaillistchecker.io prevent TLS handshake failures from derailing entire sends. The API is available at Emaillistchecker.io API and supports high-volume validation with no expiration on purchased credits.

While OpenSSL’s s_client is precise for low-level debugging, it’s not designed for checking thousands of addresses or catching delivery patterns at scale. Automated tools complement command-line tools by handling the scale and visibility that manual testing can’t.

Why Manual Testing with OpenSSL s_client Is the Gold Standard

When SMTP TLS certificates misbehave, automated tools often mask the root issue. OpenSSL s_client doesn’t guess or abstract — it shows you the raw TLS handshake step by step, so you can pinpoint exactly where a certificate fails: at the server, client, chain validation, or cipher negotiation. It’s deterministic, verifiable, and trusted by security teams worldwide.

Unfiltered Access to the TLS Handshake

Automated tools may hide flaws behind a simple "invalid" result. With OpenSSL s_client, you see every detail of the encryption negotiation — from the server’s advertised ciphers to the certificate chain, expiration, and trust chain. There’s no abstraction layer, no black box, just the actual protocol behavior.

Let’s say you’re debugging an SMTP server that refuses TLS connections. A tool might say “failed to verify certificate.” OpenSSL will tell you if it’s expired, self-signed, missing intermediate certs, or if the server sent malformed handshake data. The output is raw and precise — no assumptions.

Exact Diagnosis, No Guesswork

You get deterministic results. Run the same command twice against the same server, and the output will match. No race conditions, no cached responses — you’re seeing what the server actually sent.

Tools like RFC 5280 define how certificate chains should be validated — OpenSSL implements that rigor directly. It doesn’t rely on heuristics or third-party lookup databases. That’s why it’s the baseline for testing in security, compliance, and email delivery operations.

This transparency is essential when debuggging deliverability issues — especially when your email server is blocked due to a misconfigured TLS setup. You can verify if your certificate is trusted, if the chain is complete, and whether your client is rejecting it based on policy.

For teams managing bulk email sends, accurate TLS validation helps avoid reputational damage. A single expired certificate can trigger blocks, even if the rest of your setup is correct. Tools like bulk verification can’t catch certificate flaws in SMTP infrastructure — but OpenSSL s_client, used correctly, can.

How to Use OpenSSL s_client to Test Mail Server Configuration

You can test email server configurations for SMTP TLS issues using openssl s_client by connecting to port 587 (STARTTLS) and port 465 (implicit TLS) on providers like Gmail, Outlook, and Yahoo. This reveals certificate validity, cipher negotiation, and handshake failures. Use the output to diagnose issues early and ensure your mail server is ready for real delivery.

Test Both STARTTLS and Implicit TLS Ports

For port 587 (STARTTLS), run: openssl s_client -connect smtp.gmail.com:587 -starttls smtp to verify your server initiates TLS correctly after the EHLO command.
For port 465 (implicit TLS), use: openssl s_client -connect smtp.gmail.com:465 — no STARTTLS flag needed. This tests whether your server can establish a TLS-encrypted connection from the start.
Check the output for "verify return code" 0 (valid certificate) and ensure the certificate chain is complete. A non-zero return code means chain validation failed.
Test against multiple providers—Gmail, Outlook, Yahoo—since each uses different CA-signed certificates and may enforce different cipher and certificate policies.

Automate Testing for Multiple Domains and Warming Up

Create a script (e.g., in Bash or Python) to loop through multiple domains or IPs during domain warm-up. This helps track configuration consistency across your sending infrastructure.
Redirect output to a log file: openssl s_client -connect smtp.gmail.com:587 -starttls smtp > /tmp/gmail-test.log. This preserves historical data for audit trails and team debugging.
Use grep -A 10 "Verify return code" or openssl x509 -noout -text on the logged certificate to verify chain depth and expiration.
Compare results across multiple runs to detect drift. For example, a sudden certificate warning might indicate a misconfigured reverse DNS or expired cert on your mail server.

OpenSSL’s output is the most direct way to verify that your TLS handshake succeeds before sending real email. The bulk verification tool can help you test your entire list for deliverability risks, including problematic domains or invalid SMTP configurations, before sending.

Understanding the difference between STARTTLS and implicit TLS isn’t optional—it’s essential for sending emails reliably and avoiding outright rejection.

For a deeper look at how cert issues affect deliverability, see the TLS 1.2 RFC and how ISPs like Gmail enforce certificate trust through Certificate Authority (CA) checks. Tools like inbox placement testing complement these checks by measuring actual delivery success across major inboxes.

What 'Verify Return Code' Means in OpenSSL s_client Output

When you run openssl s_client, the "Verify return code" tells you whether the SSL/TLS certificate chain was trusted. A code of 0 means everything’s good — the chain is valid and trusted. Codes like 20 (self-signed) or 21 (expired) signal problems that require action, while others (10, 18, etc.) point to specific trust or revocation issues. Knowing these codes is key to diagnosing handshake failures.

Common Return Codes and What They Mean

0 — Certificate verification succeeded. The full chain is trusted and valid. This is the only safe return code for production.
20 — The certificate is self-signed or not trusted by your system’s root store. Common in internal dev environments or self-hosted services. You can bypass this with -verify none for testing, but never in production.
21 — The certificate has expired. This is a critical failure. You must renew the certificate immediately. An expired cert breaks TLS connections and is flagged by most clients.
10 — The issuer certificate was not found in the trust store. Usually means a missing intermediate in the chain. Check the certificate chain from the server and ensure intermediates are properly configured.
18 — The certificate is revoked. This could be due to a CRL (Certificate Revocation List) or OCSP check failure. It's a red flag — investigate revocation status through CRL distribution points or OCSP servers.
2 — The certificate has an unknown or unsupported signature algorithm. Rare, but may occur with outdated or experimental crypto.

How to Respond to Each Code

Let’s be practical: if you’re debugging a TLS handshake and see a non-zero return code, don't just ignore it. You’re seeing a security guard blocking access. Use OpenSSL’s official documentation to understand the specific error, then fix the root cause—not just the symptom.

Item	Details
0	Certificate verification succeeded. The full chain is trusted and valid. This is the only safe return code for production.
20	The certificate is self-signed or not trusted by your system’s root store. Common in internal dev environments or self-hosted services. You can bypass this with -verify none for testing, but never in production.
21	The certificate has expired. This is a critical failure. You must renew the certificate immediately. An expired cert breaks TLS connections and is flagged by most clients.
10	The issuer certificate was not found in the trust store. Usually means a missing intermediate in the chain. Check the certificate chain from the server and ensure intermediates are properly configured.
18	The certificate is revoked. This could be due to a CRL (Certificate Revocation List) or OCSP check failure. It's a red flag — investigate revocation status through CRL distribution points or OCSP servers.
2	The certificate has an unknown or unsupported signature algorithm. Rare, but may occur with outdated or experimental crypto.

The 6 items listed under “Common Return Codes and What They Mean”, side by side.

Self-signed certs (code 20) are fine for internal testing but must be explicitly trusted. Expired certs (code 21) must be renewed—automated monitoring helps avoid downtime. Chain issues (code 10) often mean intermediates are missing; reconfigure your server to send the full chain.

Remember: TLS isn’t just about encryption. It’s about trust. One bad link breaks the chain. Fixing certificate issues early saves support tickets, failed deliveries, and security risks.

When to Use the Emaillistchecker.io API vs. Manual OpenSSL Testing

You should use OpenSSL s_client when you need to inspect the TLS handshake process in detail—like checking certificate chains, expiration dates, or cipher suite negotiation. For large-scale email list cleaning, pre-send validation, and assessing inbox placement risk, Emaillistchecker.io’s API offers faster, scalable checks with 98.9% accuracy. Let’s break down when each fits.

Manual OpenSSL Testing: Deep Dive into TLS Behavior

When troubleshooting why an email server isn’t accepting TLS connections, OpenSSL s_client gives you direct control over the TLS handshake. It’s the standard tool for inspecting certificate validity, verifying hostname matching, and identifying issues like expired certs or unsupported cipher suites. This is essential when you’re debugging delivery failures linked to TLS negotiation timeouts or handshake errors.

For example, running openssl s_client -connect mail.example.com:587 -starttls smtp reveals the full exchange between client and server. You can manually verify the certificate chain, confirm the server’s presented domain matches the target, and detect if the server rejects specific TLS versions or ciphers.

This level of control is critical when working with mail servers that have non-standard configurations or strict TLS policies. It’s a low-level diagnostic tool built into most Unix-like systems and trusted by infrastructure engineers. The OpenSSL project’s documentation, available at openssl.org, provides authoritative guidance on its use in network diagnostics.

Automated Email Verification: Scale with Emaillistchecker.io

Manual testing is slow and impractical at scale. If you’re validating thousands of email addresses, checking for disposable domains, catch-all accounts, or deliverability risk before sending, Emaillistchecker.io’s real-time API is a better fit. It handles bulk validation, detects invalid formats, role-based addresses, and checks DNS records like MX, SPF, and DKIM.

Integrate the Email Verification API into your workflows—like customer onboarding or campaign prep—to catch bounces before they happen. It returns detailed results, including risk scores based on sender reputation, domain health, and inbox placement likelihood. This isn’t just validation; it’s a proactive deliverability shield.

For businesses syncing with Mailchimp, HubSpot, Klaviyo, or SendGrid via native integrations, API-driven verification becomes seamless. It’s not about replacing tools like s_client—it’s about using the right tool for the job. OpenSSL for diagnosis. Emaillistchecker.io for prevention.

Final Thoughts: Debugging TLS Starts with Understanding the Handshake

SMTP TLS relies on a validated handshake process. When delivery fails, the root cause is often a certificate misconfiguration, expiration, or mismatched trust chain. Understanding this flow is the first step in diagnosing issues that would otherwise appear as black-box failures.

OpenSSL s_client provides direct access to the TLS handshake. It reveals exact errors — certificate expiry, hostname mismatch, revoked certificate, unsupported cipher — without relying on third-party tools or abstract reports. This level of visibility is unmatched for diagnosing server-side issues.

Use OpenSSL for deep-dive troubleshooting. Pair it with automated email verification tools to catch invalid or risky addresses before they impact deliverability. Real-time testing and bulk verification work together to maintain a clean, trusted sending list.

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 'Verify return code: 0' mean in OpenSSL s_client output?

It means the certificate chain was successfully validated and trusted by the client. No security issues were detected during verification.

Can I test TLS on port 465 using OpenSSL s_client?

Yes. Use `openssl s_client -connect smtp.example.com:465 -crlf` to test implicit TLS connections on port 465.

Why is my email delivery failing even with valid SMTP settings?

TLS certificate issues like expiration, chain problems, or domain mismatch can block delivery even if credentials are correct.

How often should I test TLS certificate health on my mail server?

Test after any configuration change, certificate renewal, or when delivery issues arise. Monthly checks are a minimum for production environments.

Does OpenSSL s_client require internet access?

Yes, it connects to the target SMTP server over the network. You need a live connection to test remote certificates.

What if OpenSSL s_client shows a self-signed certificate?

It's expected in dev or internal environments. For public email delivery, replace it with a certificate from a recognized CA.

Can Emaillistchecker.io detect TLS certificate problems?

It does not test certificates directly but verifies email address validity and deliverability, which can reveal indirect TLS issues during real connections.

Is there a way to automate OpenSSL s_client testing?

Yes. Scripts using curl, bash, or Python can automate s_client runs and parse output for alerts or logs.

What’s the difference between STARTTLS and implicit TLS?

STARTTLS upgrades an unencrypted connection to encrypted after authentication. Implicit TLS uses encryption from the start on port 465.

Can a bad TLS certificate affect sender reputation?

Yes. Failed handshakes signal misconfiguration, which can trigger spam filters and reduce inbox placement over time.

How do I know if my mail server sends the full certificate chain?

Use OpenSSL s_client and look for multiple certificates in the output — a complete chain includes the server cert, one or more intermediates, and the root CA.

Can I test TLS using a web-based tool instead of OpenSSL?

Yes, but they may not show full handshake details. OpenSSL provides deeper insight for debugging complex TLS failures.