How to Use openssl s_client to Inspect SMTP TLS Certificate Details

Why You Need to Verify SMTP TLS Certificates

Ever sent an email only to see it vanish into the void—no bounce, no error, just silence? You’re not imagining it. A broken TLS certificate behind your SMTP connection can quietly sabotage delivery before the first message even leaves your server.

TLS isn’t just a security checkbox—it’s what keeps your email traffic encrypted and trusted across the global mail network. When certificates expire, misconfigure, or use weak cipher suites, your messages may fail to handshake or get flagged as risky by receiving servers. This can mean higher bounce rates, poor inbox placement, and damage to your sender reputation, even if your content is clean.

Using openssl s_client to inspect SMTP TLS certificates gives you real-time visibility into the health of your encryption setup. It’s not just for dev teams—it's a practical, repeatable check you can run in under 10 seconds to catch issues before they cost you deliverability.

Key takeaways

• Expired or misconfigured SMTP TLS certificates can cause silent email delivery failures and trigger spam filters
• Using openssl s_client lets you test TLS handshake behavior and inspect certificate validity, chain, and cipher suite in real time
• Regular verification reduces bounce rates and maintains sender reputation by ensuring secure, trusted connections

What Does openssl s_client Reveal About SMTP TLS Certificates?

When you run openssl s_client against an SMTP server on port 587 or 25, it establishes a live TLS connection and dumps the full certificate chain, issuer details, expiration date, public key size, and signature algorithm. You’ll see if the certificate matches the hostname, if the chain is trusted, and whether the server supports modern cipher suites—directly exposing misconfigurations like expired certs, expired intermediates, or TLS version mismatches. This is how you manually audit email security at the transport layer.

What You See in the Output

After connecting, s_client shows the full certificate chain—from the server cert to the root CA—often in PEM format. You’ll spot the issuer (e.g., Let’s Encrypt, DigiCert), the expiration date (e.g., "notAfter=Oct 5 12:00:00 2025 GMT"), and the public key algorithm (like RSA 2048 or ECDSA P-256). If the hostname doesn’t match the cert’s Common Name or Subject Alternative Names, it flags a mismatch—common with mail servers using wildcard certs or mislabeled domains.

It also reveals cipher suite negotiation. If the server only supports weak ciphers like SSLv3 or RC4, or rejects modern ones like ECDHE, you’ll see it in the handshake log. This helps identify outdated configurations that reduce transport security. The output includes the TLS version used (TLS 1.2 or 1.3), and whether the connection was successfully negotiated.

Common Issues Revealed

Many mail servers fail basic TLS checks. A misconfigured server might advertise a self-signed certificate, lack a proper chain, or serve an expired cert—any of which can trigger rejection by compliant mail clients. You can use s_client to validate these before sending campaigns, especially if you’re debugging why your emails are marked as unencrypted.

According to the IETF’s RFC 5246 (TLS 1.2), the handshake must verify the server’s identity and negotiate a secure, encrypted channel. s_client is a direct implementation of this—your eyes on the wire, seeing what the server actually offers. It’s not an API or a dashboard; it’s raw, real-time inspection.

It’s also useful during setup or audit. If you use services like bulk email verification to clean lists before sending, knowing your outbound mail’s TLS chain is solid helps reduce deliverability risks—especially when sending through platforms like SendGrid or Mailchimp that prioritize secure connections.

How to Use openssl s_client to Inspect SMTP TLS Certificates

You can inspect the TLS certificate presented by an SMTP server using openssl s_client by connecting to the server on port 587 with the -starttls smtp flag. This reveals the certificate chain, expiration date, issuer, subject, and SANs, helping you verify security and identity. The command is part of OpenSSL, a widely used open-source toolkit for cryptographic operations.

1. Open a terminal or command-line interface—on Linux, macOS, or Windows with WSL or Git Bash. This is where you’ll run the command to connect to the SMTP server directly.
2. Run the command: openssl s_client -connect smtp.example.com:587 -starttls smtp. Replace smtp.example.com with your target server (like smtp.mailgun.org or smtp.sendgrid.net). The port 587 is standard for submission with STARTTLS.
3. Wait for the connection to complete. Once the TLS handshake finishes, the terminal will display the server's certificate in PEM format. This includes metadata such as the issuer, subject, validity period, and SANs.
4. Locate the Certificate chain section. It starts with SSL-Session and includes the server certificate, intermediate certificates, and sometimes the root CA. You can verify if the chain is complete and trusted.
5. Check the Verify return code. Look for verify return code: 0. A code of 0 means the certificate chain verified successfully, which includes proper trust, expiration check, and correct hostnames.
6. Examine notAfter and subject fields. The notAfter field shows the expiration date—ensure it’s in the future. The subject field should match the domain you’re connecting to, and the Subject Alternative Name (SAN) list should include the server’s hostname.

Why This Matters for SMTP Security

A valid TLS certificate with correct SANs proves the server is who it claims to be. Without this, your email may be intercepted, spoofed, or flagged as insecure. According to the RFC 5280, certificate validity and domain alignment are essential for trust in TLS communications.

Common Issues to Watch For

• Self-signed certificates: These cause verify return codes other than 0 and are not trusted by default.
• Expired certificates: The notAfter date will be in the past. No modern email client will accept these.
• Missing SANs: If the domain isn’t listed in the SAN, the certificate is invalid for that server, even if the subject matches.

If you're managing email deliverability and want to validate server configurations or check for misconfigurations in your own or third-party SMTP providers, tools like inbox placement testing can help determine if TLS issues impact real-world delivery.

Interpreting the openssl s_client Output

When you run openssl s_client to inspect an SMTP TLS certificate, look for Verify return code: 0—it means the chain is trusted and valid. A date in the past under notAfter means the certificate has expired. Check the Subject Alternative Name (SAN) field: if it doesn’t match your domain, the certificate is misconfigured. If the issuer isn’t in your root store or it’s self-signed, you’ll see a trust error. These are common signs of setup issues or potential security risks.

What to Look for in the Output

• If Verify return code: 0 appears, the certificate chain is properly verified and trusted by your system’s root store. This is the expected result when everything is configured correctly.
• If you see notAfter set to a date in the past, the certificate has expired. Expired certificates can cause TLS handshake failures and reduce trust with receiving mail servers.
• Check the Subject Alternative Name (SAN) field. If your domain doesn’t appear here—and it's not the subject of the certificate—mail servers may reject your messages, even if the certificate otherwise looks valid.
• Self-signed certificates or issuers not in your trust store will show errors like verify error:num=20:unable to get local issuer certificate. These are often seen in development environments but can flag your messages as suspicious to major providers.
• A mismatch between the certificate’s Common Name (CN) and the domain you're connecting to can also cause trust failures. Modern standards prefer SANs over CN for validation.

Risks of Ignoring Certificate Warnings

Certificate issues aren't just about trust—they directly impact email deliverability. Mail servers like Gmail or Microsoft’s receive systems will flag or block messages from domains with expired, self-signed, or improperly configured certificates. This is part of how they defend against spoofing and abuse.

For a deeper look at how email infrastructure relies on TLS trust chains, see the IETF’s RFC 5280 on X.509 certificate standards. The structure of certificate fields, including SANs and issuance chains, is designed to prevent impersonation and misconfiguration.

Want to catch these issues before they hurt your sender reputation? You can verify your domain’s certificate setup as part of a broader deliverability health check. Use inbox placement testing to simulate how your messages land in real inboxes—with or without TLS configuration issues—before sending at scale.

Common TLS Certificate Issues Detected with openssl s_client

You can use openssl s_client to catch TLS certificate problems that break SMTP connections—like expired certs, hostname mismatches, missing intermediates, or unsupported cipher suites—before they cause delivery failures. Let’s walk through the most frequent issues and how to spot them.

Certificate Expiration

• Check the notAfter date in the output: if it’s in the past, the certificate is expired and will prevent secure connections.
• Expired certs are a leading cause of TLS handshake failures in email delivery systems. Tools like SSL Labs can help validate certificate validity across the web.

Hostname Mismatch

• Look for Verify return code: 21 (hostname mismatch)—it means the cert doesn’t cover the domain you’re connecting to.
• Verify the Subject Alternative Name (SAN) field: it must include the exact server hostname. If it doesn’t, the connection may be rejected by strict mail servers.
• Use -servername with s_client to test the correct host: openssl s_client -connect mail.example.com:587 -servername mail.example.com.

Incomplete Certificate Chain

• A missing intermediate certificate breaks trust. Look for a Certificate chain that ends with a root CA—anything shorter than that means an incomplete chain.
• Some SMTP servers fail to send mail if the chain is incomplete, even if the certificate itself is valid.
• Use -showcerts to see all certificates sent during the handshake.

Unsupported Cipher Suite

• A handshake failure or SSL negotiation failed often points to unsupported cipher suites.
• Check the SSL handshake section: if the server doesn’t offer any cipher supported by your client, the connection drops.
• Modern systems prefer ECDHE-based key exchange and forward secrecy. Older or misconfigured servers may restrict cipher choices.

These checks help prevent SMTP connection failures that affect deliverability. Use them proactively when debugging email infrastructure issues—or when verifying domain setups in tools like our SMTP integrations with Mailchimp, SendGrid, or HubSpot. A clean TLS handshake is foundational to inbox placement.

How to Automate Verification of SMTP TLS Configurations

You can automate SMTP TLS configuration checks by scripting openssl s_client to test multiple domains, parsing the output for certificate validity, expiration, and chain issues, then triggering alerts via monitoring tools like Prometheus or Nagios when problems are detected. This ensures your email infrastructure stays secure and compliant at scale.

Scripting the Checks Across Domains

Let’s say you manage email for dozens of domains. Running openssl s_client manually for each one isn’t sustainable. Instead, write a simple shell script that loops through your list of SMTP hosts, connects on port 587 or 25, and captures the TLS handshake output. You can run this as a periodic cron job or integrate it into a CI/CD pipeline for ongoing validation. The goal is to make checks consistent, repeatable, and repeatable across environments.

For example, a loop like for domain in "${domains[@]}"; do openssl s_client -connect "$domain:587" -servername "$domain" < /dev/null | grep -q "Verify return code" && echo "OK: $domain" || echo "FAIL: $domain"; done quickly identifies which hosts fail basic TLS negotiation. This approach scales to hundreds of domains without manual effort.

Parsing Results and Triggering Alerts

Raw openssl s_client output is rich but noisy. Use tools like awk, grep, or a lightweight parser to extract key details: certificate expiration dates, issuer, subject, and whether verification succeeded. For instance, openssl s_client -connect mail.example.com:587 -servername mail.example.com < /dev/null 2>&1 | awk '/notAfter=/ {print $2}' fetches the expiry date directly.

When you detect a certificate expiring within 30 days or verify return code 21 (self-signed), flag it. Use standard systems like Zabbix, Prometheus, or Datadog to surface these events as alerts. This is how large organizations maintain high deliverability — by catching problems before they affect sender reputation.

While this is a technical foundation, it’s not a substitute for sending real messages. For end-to-end deliverability validation, you might test real messages against inboxes using an inbox placement service. Learn more about how to test if your messages reach inboxes at scale: test inbox placement with real recipients.

For deeper email infrastructure insights — like verifying domain authentication or checking for known bad addresses — tools like bulk email list verification can complement your TLS checks by ensuring your sending list is clean and your sender reputation remains strong.

SMTP TLS Security Best Practices

You should use certificates from trusted Certificate Authorities, include all relevant hostnames in the SAN field, set up renewal alerts at least 30 days before expiry, and regularly audit your TLS setup with tools like openssl s_client or MxToolbox. This ensures your SMTP connections are secure, trusted, and avoid delivery failures due to misconfiguration.

Configure TLS with Valid, Trusted Certificates

• Only use TLS certificates issued by recognized Certificate Authorities (CAs) like Let’s Encrypt, DigiCert, or Entrust. Self-signed or untrusted certificates cause clients to reject mail.
• Verify your CA trust chain is complete. A broken chain breaks encryption and can cause mail rejection.
• Check the certificate validity period using openssl s_client -connect smtp.example.com:587 -starttls smtp — this shows expiration dates and trust status.

Ensure Correct SANs and Timely Renewals

• Include every hostname your mail server responds to in the Subject Alternative Name (SAN) field — for example: smtp.example.com, mail.example.com, and example.com.
• Use tools like MxToolbox or RFC 5280 to validate SANs and certificate structure.
• Set up automated renewal alerts at least 30 days before expiry. Missing an update leads to service interruption and bounce rates over 50% in some cases.
• Test your configuration after renewal with openssl s_client to confirm the new certificate is correctly installed and trusted.

Let’s be clear: misconfigured TLS is a common root cause of failed deliveries and poor sender reputation. Regular audits prevent surprises. Use openssl s_client not just once — make it part of your ongoing monitoring process.

“A well-configured TLS setup is not a luxury — it’s a requirement for inbox placement.”

For teams managing high-volume mail streams, maintaining a clean list reduces risk. You can check if your sender infrastructure aligns with security standards by validating domains and endpoints. To automate and scale this, consider using bulk verification tools that help confirm domain integrity and support consistent deliverability.

How Emaillistchecker.io Complements SMTP TLS Inspection

While openssl s_client reveals what’s happening at the server level—like TLS handshake details and certificate chains—Emaillistchecker.io checks whether the email address itself is valid, active, and safe to send to. You can verify infrastructure security with OpenSSL, but you need email verification to ensure your messages actually reach real inboxes.

Validating Real Addresses, Not Just Server Configurations

Inspecting SMTP TLS with OpenSSL shows you if a domain is set up to accept encrypted connections, but it doesn’t tell you if the address is real or functional. Emaillistchecker.io goes beyond infrastructure by validating each email address against multiple checks: syntax, domain existence, mailbox existence, catch-all detection, role accounts (like info@ or support@), and disposable domains. These are the kinds of issues that lead to high bounce rates and poor deliverability—even with a properly configured TLS server.

For example, a catch-all address might accept any email, but it's often a sign of poor inbox hygiene. Role accounts are frequently ignored or marked as spam. Disposable domains, while technically valid, almost never result in engaged recipients. Using Emaillistchecker.io helps catch these before they hurt your sender reputation. The tool’s 98.9% accuracy rate means you’re not just verifying syntax—you’re filtering out the noise that inflates bounce rates and can trigger blocklists.

Seamless Integration and Workflow Prevention

Once you’ve confirmed the TLS setup with openssl s_client, the next step is ensuring your list is clean. Emaillistchecker.io integrates directly with Mailchimp, SendGrid, Klaviyo, and HubSpot so you can validate your list before sending. This means you can plug into your existing marketing stack and filter out invalid or risky addresses—without leaving your dashboard.

Running a bulk verification before a campaign reduces the number of hard bounces, which is critical for maintaining a good sender reputation. According to RFC 5321, hard bounces are a primary signal to mailbox providers that your list quality is poor. You don’t want to rely solely on tools like OpenSSL to tell you about your email health—use it properly, then follow up with end-to-end validation.

With tools like Emaillistchecker.io, you can run a bulk verification on your list directly in your browser, or integrate verification via API for automated workflows. Real-time checks ensure your list stays clean, and inbox placement tests help you understand how well your messages are likely to land in the inbox—not the spam folder.

What Happens If You Ignore SMTP TLS Certificate Issues?

If you skip inspecting SMTP TLS certificates, your emails may be silently dropped, delayed, or marked as spam — even if your content is clean. Reputable providers like Gmail and Microsoft Outlook actively reject messages from servers with expired, self-signed, or misconfigured TLS certificates. This undermines deliverability and harms sender reputation without obvious warning.

Real Risks of Ignoring TLS Certificate Problems

• Receiving servers may drop your messages entirely if TLS negotiation fails — no bounce, no error, no notification. You’ll never know they were lost.
• Mail providers such as Gmail use TLS status as a signal in their spam filtering; weak or broken TLS can trigger automatic rejection or classification as suspicious.
• Delayed delivery occurs when servers time out during TLS handshakes, especially with misconfigured or expired certificates. This hurts time-sensitive campaigns.
• Domains with recurring TLS issues are more likely to be flagged in reputation systems. Even a single failure can harm long-term deliverability.

How to Catch These Before They Cause Damage

Manually verifying TLS setup using openssl s_client is a simple, reliable way to catch certificate issues before they affect your send rates. It’s not just about encryption — it’s about compliance with industry standards like RFC 5246 and DMARC policies that depend on valid TLS.

Use openssl s_client -connect your-smtp-server:587 -starttls smtp to test the handshake and view the certificate chain. Look for expiration dates, mismatched domains, or weak cipher suites. These red flags should trigger immediate fixes.

While tools like bulk verification ensure email address validity, they don’t check TLS. That’s where manual inspection matters — it’s a low-effort, high-impact step in maintaining technical integrity.

For teams managing large-scale email sends, regular TLS validation should be part of your workflow. It’s not enough to assume your setup is secure — you must confirm it. Ignoring certificate issues isn’t just risky, it’s a silent blocker to inbox placement.

Key Takeaway: Secure Your Email Infrastructure with Proactive Checks

Use openssl s_client to verify that your SMTP TLS certificates are valid, issued by a trusted CA, and correctly configured. This simple step prevents connection failures and ensures encrypted communication.

Even the strongest encryption is undermined by poor list hygiene. Invalid or risky email addresses increase bounce rates, harm sender reputation, and raise blocklist risk.

Combine TLS inspection with real-time verification. Emaillistchecker.io’s bulk verification and API check for syntax, domain validity, and inbox placement likelihood — helping you maintain a clean, deliverable list.

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

• Email authentication: SPF, DKIM, DMARC and BIMI (complete guide)
• How to Continuously Monitor Email Authentication Records for Deliverability
• SPF and DKIM Setup for Sending to QQ and 163 Email Users
• Yandex Authentication Failure Reasons for Foreign Email Servers
• How to Resolve Sender Rejected Due to Reverse DNS Mismatch in AWS SES

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does openssl s_client -starttls smtp do?

It initiates a TLS handshake with an SMTP server on port 587, allowing inspection of the certificate used to encrypt the connection.

How do I check if an SMTP server’s TLS certificate is expired?

Run openssl s_client against the server and look for the `notAfter` date in the certificate output. If it’s in the past, the certificate is expired.

Can I use openssl s_client to test email deliverability?

Not directly. It checks encryption and server configuration but not deliverability. Use Emaillistchecker.io for end-to-end email validation and inbox placement testing.

What does 'Verify return code: 0' mean in openssl s_client output?

It means the certificate chain was successfully validated against trusted root certificates. No trust issues detected.

Why does my email server reject connections even with TLS?

TLS rejection can stem from expired, self-signed, or mismatched certificates. Use openssl s_client to diagnose and fix certificate issues.

How often should I check SMTP TLS certificates?

At least monthly. Set up automated checks and alerts for expiration to prevent disruptions in email delivery.

Does Emaillistchecker.io verify SMTP TLS certificates?

No. It focuses on email address validity and list hygiene. For TLS auditing, use tools like openssl s_client or third-party services like MxToolbox.

Is it safe to run openssl s_client on public SMTP servers?

Yes, it’s a standard diagnostic tool. It doesn’t send messages or alter server state — it just connects and checks the TLS handshake.

What’s a Subject Alternative Name (SAN) in an email certificate?

It’s a field that lists additional hostnames the certificate is valid for. A missing SAN can cause connection failures for mail clients.

What happens if the certificate doesn’t match the server hostname?

The TLS handshake will fail or produce a warning. Many mail servers will reject the connection to prevent man-in-the-middle attacks.

Can I automate openssl s_client for multiple domains?

Yes. Use shell scripts with loops to run the command against a list of domains and parse the output for expiry or configuration issues.

Does Emaillistchecker.io help with spam trap detection?

Yes. Its 98.9% accuracy identifies risky addresses like role accounts, disposable domains, and catch-alls — known spam trap sources.