Verify SMTP SSL Certificate Using openssl s_client on Ubuntu 2026

Why You Should Verify SMTP SSL Certificates on Ubuntu

You're sending a critical email from your Ubuntu server, but it’s not getting through. No error, just silence. Could a flawed SSL certificate be silently breaking your SMTP connection?

SSL certificates ensure your email server is talking to the right destination, not an attacker in between. Without verifying them, you’re leaving your messages — and your reputation — vulnerable. On Ubuntu, the openssl s_client tool gives you direct, real-time access to inspect the SSL layer without external apps.

Learning how to verify SMTP SSL certificates using openssl s_client on Ubuntu isn’t just technical curiosity. It’s how you confirm your mail flow is secure, reliable, and properly configured.

Key takeaways

• Use openssl s_client on Ubuntu to directly inspect SMTP SSL certificates without third-party tools.
• Unverified certificates can cause silent SMTP connection failures, leading to undelivered emails and poor deliverability.
• Verifying SSL certificates at the TLS layer helps detect misconfigurations, expired certs, and man-in-the-middle risks before they impact your email delivery.

What Does 'Verify SMTP SSL Certificate' Actually Mean?

When you verify an SMTP SSL certificate using openssl s_client on Ubuntu, you’re confirming that the mail server you're connecting to presents a legitimate, trusted certificate issued by a recognized Certificate Authority (CA). This check ensures the server is who it claims to be, not a man-in-the-middle attacker pretending to be a real mail server. It’s the digital handshake that prevents forged or compromised mail servers from intercepting or tampering with your email traffic.

What the Verification Actually Checks

Behind the scenes, the verification process evaluates several key security aspects. First, it checks whether the certificate is signed by a CA your system trusts—most modern Linux distributions, including Ubuntu, come with a pre-populated list of trusted root CAs. Then it validates the certificate’s expiration date; an expired certificate fails immediately. It also checks that the certificate's domain name matches the server you're connecting to, preventing domain spoofing.

Finally, it looks into whether the certificate has been revoked. This is done using Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs), both standard mechanisms defined in RFC 6960 and RFC 5280. If any of these checks fail, the connection won’t proceed unless you explicitly bypass the verification—something you shouldn’t do in production environments.

Why This Matters in Practice

A failed verification usually means one of three things: the server has a misconfigured certificate (like using a self-signed cert without proper trust), the certificate is expired, or there's a mismatched hostname. In rare cases, it could signal a real MITM attack, especially if you're connecting to a server in a public or untrusted network.

For systems that rely on secure email delivery—like automated notifications, transactional campaigns, or business communications—skipping this check opens a serious security gap. You might be sending sensitive data to a server that isn’t actually who it claims to be.

While this command is useful for debugging SMTP configurations, it’s also a good habit to incorporate into automated checks. Tools like our real-time verification API perform similar validations at scale, so you’re not just sending emails—you’re sending them to verified, secure destinations.

How openssl s_client Works with SMTP and SSL/TLS

You can verify an SMTP server’s SSL/TLS certificate on Ubuntu using openssl s_client by connecting to port 465 (SMTPS) or 587 (STARTTLS), which triggers the SSL handshake and displays certificate details like issuer, expiration, and chain validity. This command simulates a real email client connection, letting you inspect whether the server presents a valid, CA-signed certificate.

What the Command Actually Does

When you run openssl s_client -connect smtp.example.com:587 -starttls smtp, you’re telling OpenSSL to open a secure TCP connection to the SMTP server, negotiate TLS, and then show the full handshake process, including the certificate chain, cipher suite used, and whether the certificate is trusted.

It doesn’t send an email — it only tests connectivity and certificate legitimacy. This is exactly how a secure email client would behave before initiating a transmission.

Why This Matters for Deliverability

Invalid or expired certificates can cause connections to fail, leading to delivery issues. Many mail servers reject incoming connections from clients that can’t verify the server’s identity. The s_client command helps isolate whether a certificate problem is blocking your outgoing messages.

For example, if the server returns a “self-signed” certificate or one signed by an unknown CA, the connection won’t be trusted — even if the server is otherwise functional. This is a common cause of bounce rates in bulk email campaigns.

While openssl s_client is a low-level diagnostic tool, it’s a trusted method used by network administrators and security teams. It’s part of the OpenSSL toolkit, which is the de facto standard for SSL/TLS testing and is referenced in official RFCs like RFC 5246 (TLS 1.2).

For teams managing large email lists, automated verification of these TLS conditions is part of maintaining strong sender reputation. Tools like bulk email verification include checks for valid domains and MX records, but don’t replace direct certificate inspection when diagnosing connection failures.

Step-by-Step: Verify SMTP SSL Certificate Using openssl s_client on Ubuntu

You can verify an SMTP SSL certificate on Ubuntu by running openssl s_client -connect smtp.example.com:587 -starttls smtp in the terminal. The tool checks the certificate chain and returns a 'Verify return code'. A value of 0 means the chain is trusted and valid. Any other code indicates failure due to expiration, domain mismatch, or self-signed status.

1. Open a terminal on your Ubuntu system. This is the starting point for all TLS verification tasks. You don’t need a GUI — just a shell session.
2. Run the command: openssl s_client -connect smtp.example.com:587 -starttls smtp. Replace smtp.example.com with your target server and port. The -starttls smtp flag tells OpenSSL to negotiate TLS after connecting to the SMTP service.
3. After the connection, inspect the output. Look for the section labeled “Certificate chain” — this shows the full sequence of certificates from the server up to the trusted root CA. This chain must be complete and trusted.
4. Find the line that says “Verify return code”. If it reads “Verify return code: 0”, the certificate is valid and trusted. This is the standard indicator defined in RFC 5280 for successful certificate validation.
5. If the return code is non-zero, review the certificate details. Check the expiration date (certificates are invalid after expiry), the subject name (must match the domain), and whether it’s self-signed (not trusted by default).

Common Reasons for Verification Failure

Failure codes like 10 (cert not trusted) or 20 (certificate has expired) point directly to known issues. If the server uses a self-signed certificate, you’ll see a non-zero return code unless you explicitly trust it in your system’s trust store.

Domain mismatches occur when the certificate is issued for mail.example.com but you’re connecting to smtp.example.com. This is common in misconfigured email servers.

When You Need More Than a One-Off Check

For ongoing email delivery monitoring, manual verification isn’t scalable. You need automated tools to catch changes in certificate status, misconfigurations, or delivery risks before they affect your campaigns.

Verify large email lists with accurate deliverability insights. EmailListChecker.io checks for active domains, valid syntax, and sends test emails to measure inbox placement, helping you avoid delivery issues from untrusted or invalid SMTP setups.

Common openssl s_client Return Codes and What They Mean

When you run openssl s_client on Ubuntu to verify an SMTP SSL certificate, the return code tells you exactly what went wrong—or if everything’s fine. A return code of 0 means the certificate is trusted and valid. Codes like 18 (expired), 19 (not yet valid), or 10 (hostname mismatch) signal specific issues. A return code of 2 means it’s self-signed, which may be acceptable internally but not for public email servers. Understanding these codes is critical for diagnosing delivery problems in email infrastructure.

Understanding Return Codes in Context

You’ll see these codes in the verify return code line of the s_client output, especially when manually testing SMTP connections to mail servers. Each code maps to a specific trust or validity failure. These aren't just technical noise—they directly impact whether an email client accepts the connection. For example, a code of 18 means the certificate has passed its expiration date, which breaks TLS handshakes. Code 19 means the certificate's start date is in the future, so the server hasn’t even begun to be valid yet. These are hard failures unless you're testing in a controlled lab environment.

Return Code Reference Table

For a deeper look at TLS verification in practice, see the RFC 5280, which defines certificate fields and validation rules. You can also test any SMTP server’s configuration using tools like MXToolbox for real-time diagnostic insights.

If you’re managing a large email list and want to prevent delivery issues before they happen, bulk list verification helps catch invalid or misconfigured domains early. Verify your entire list at scale with accurate SMTP and SSL validation, reducing bounce rates and protecting sender reputation.

How to Fix a Failed SSL Verification on a Mail Server

When your mail server fails SSL verification, check the certificate’s validity, domain match, trust chain, and system time. An expired certificate, mismatched hostname, self-signed certificate, or incorrect time sync are the most common causes. Use openssl s_client to diagnose, then resolve based on the error output. For reliable email delivery, ensure your server’s SSL setup is correct and trusted by receivers.

Diagnose and Fix Root Causes

• Run openssl s_client -connect yourmailserver.com:587 -servername yourmailserver.com to inspect the certificate chain. Look for "verify error" messages to identify the issue.
• If the certificate is expired, renew it through your certificate authority (CA) or hosting provider. Most CAs issue certificates with 90-day validity by default, so automated renewal is recommended.
• If the error mentions domain mismatch, ensure your certificate includes the correct hostname in the Subject Alternative Name (SAN) field. You can verify this using openssl x509 -in cert.pem -text -noout. Public mail servers must have valid SANs matching the FQDN.
• If the certificate is self-signed, it will fail verification by default. While adding it to the system trust store is possible using update-ca-certificates, this is not suitable for public-facing mail servers. Replace it with a CA-signed certificate from providers like Let’s Encrypt, DigiCert, or Comodo.
• Verify the system time is accurate. A time difference of more than a few minutes can invalidate SSL checks. Use timedatectl status to confirm NTP synchronization and enable it with systemctl enable systemd-timesyncd.

Verify and Test Post-Fix

After applying fixes, retest with openssl s_client until all validation errors disappear. Check that the certificate chain is complete and trusted by common CA roots. For production mail servers, use a tool like dmarcanalyzer.com to simulate real-world inbound verification and catch misconfigurations early.

For teams managing large-scale email campaigns, you can validate the deliverability of your senders and list hygiene using trusted verification tools. Bulk list verification helps you identify invalid, risky, or non-deliverable addresses before sending, reducing bounce rates and protecting your sender reputation.

What Happens If You Ignore SSL Certificate Verification on Ubuntu?

Ignoring SSL certificate verification on Ubuntu means your system accepts connections from servers with expired, self-signed, or mismatched certificates—leading to insecure communication, failed email deliveries, and long-term damage to your sender reputation. Major providers like Gmail and Microsoft 365 will reject messages from servers with unverified SSL, often silently or with temporary errors that degrade your email deliverability over time.

Delivery Failures Due to Untrusted Handshakes

If your email system skips SSL verification, it may still attempt to send messages—but most modern email providers will reject the connection during the TLS handshake if the certificate is invalid or doesn’t match the domain. The result? Messages vanish without a clear bounce, creating silent delivery failures that you might not catch until engagement drops.

For example, a misconfigured TLS setup on your SMTP server could cause Gmail to return a 550 5.7.1 Service unavailable; client was blocked error. Without proper verification, you might assume your messages are going through, when in reality, they’re being silently filtered.

Reputation Damage and Rate Limiting

Repeated failed TLS handshakes with major providers signal poor infrastructure to sending reputation systems like Google’s and Microsoft’s. These systems track not just content and spam scores, but also protocol adherence. Consistently hitting servers with invalid certificates leads to IP-level warnings, temporary blocks, or even long-term blacklisting.

Spamhaus and other email monitoring platforms track connection anomalies across the internet. If your outbound IP shows patterns of TLS handshake failures—especially with known high-volume providers—your sending reputation will decline, reducing inbox placement even for legitimate messages.

Let’s be clear: you’re not just risking a single failed delivery. You’re weakening your entire infrastructure’s credibility. It’s not a one-off fix—it compounds if left unaddressed.

You can test your server’s SSL configuration from an Ubuntu terminal using openssl s_client, which is the same tool we use in our backend to validate real-time email sender infrastructure. You can also verify your email list before sending to catch potential issues early—our bulk verification service checks for invalid or unresponsive destinations, reducing the chance of delivery rejection due to misconfigured systems.

When to Use openssl s_client Instead of a GUI or Web Tool

You should use openssl s_client on Ubuntu when diagnosing SSL/TLS issues in automated environments like CI/CD pipelines, headless servers, or scripts—where GUIs and web tools aren’t available. It gives you raw access to certificate chains, handshake details, and TLS negotiation state without installing extra software. It’s the standard tool in Linux server environments and is part of core OpenSSL, always available.

Use openssl s_client when you need automation and control

• When integrating SSL verification into a shell script or CI/CD pipeline, openssl s_client runs without any GUI dependencies or browser requirements.
• It exposes complete handshake logs, including cipher negotiation, renegotiation attempts, and certificate chain validation—details often hidden in web-based tools.
• For security audits or compliance checks, you need low-level access to TLS handshake state; web tools may hide or simplify this data.
• On a minimal Docker container or embedded system, you may not have access to additional tools—openssl s_client is typically already present in base images.
• When verifying mail servers (SMTP, IMAP, etc.) in production environments, you need consistent, scriptable output—not interactive UIs.

When standard tools fall short

GUI tools like browser developer tools or online SSL checkers often only show the final certificate or basic trust chain. They don’t expose handshake failures, session resumption issues, or SNI mismatches. If you’re trying to debug a connection timeout from a specific IP, a web tool won’t help you understand whether the server responded with a fatal alert or dropped the connection early.

For example, TLS 1.3 changed how handshake messages are structured—tools that only show final outcomes can’t catch subtle negotiation errors. openssl s_client lets you see the exact message flow, cipher suite choice, and server preferences, which is crucial for troubleshooting email delivery issues or TLS misconfigurations.

When you're working on systems where every byte matters—like ensuring your email sending infrastructure passes DMARC or SPF checks in a strict environment—having granular visibility is not optional. You can't trust a web-based report alone; you need to see exactly what the server sent.

For teams managing high-volume email sends, tools like bulk email verification help ensure your mailing list is clean before sending, reducing delivery risks tied to invalid or problematic addresses—including those with broken TLS configurations.

How Email Verification Tools Like Emaillistchecker.io Relate to SMTP Certificate Checks

You don’t need to verify SSL certificates with openssl s_client every time you send mail—but doing so confirms your server is trusted, which email verification tools like Emaillistchecker.io indirectly check. If your SMTP setup is weak, even a clean list can fail inbox placement, and tools that test deliverability are effectively auditing your sender health.

Direct and Indirect Checks on Sender Reputation

Email verification services such as Emaillistchecker.io focus on list quality—checking for invalid, disposable, or dormant addresses—but their deliverability tests evaluate more than just the destination. When you run an inbox-placement test, you're simulating how real inboxes receive your message. This process fails if your sender’s infrastructure shows red flags, including missing or misconfigured SSL/TLS certificates.

For example, if your server lacks a valid SSL certificate, or the certificate chain is broken, many providers will flag your message. This isn’t a direct check by Emaillistchecker.io—but it’s part of the broader sender reputation profile they analyze. Poor authentication signals (like failed TLS negotiation) can lower your sender score over time, even if your list is clean.

Proactive Validation with OpenSSL Prepares Your Setup

That’s where openssl s_client comes in. Using it before sending to a list lets you confirm your mail server’s TLS setup is correct. If you find a mismatched certificate or a revoked certificate, fixing it first reduces the risk of your messages being rejected or quarantined.

Let’s say you’re setting up a new server. You run openssl s_client -connect mail.example.com:587 -starttls smtp and get a warning about an expired certificate. You fix that before ever sending a batch—potentially avoiding a blocklist trigger. The same logic applies to bulk sending: a secure handshake increases your chances of landing in the inbox, which is exactly what deliverability tests measure.

While tools like Emaillistchecker.io don’t verify certificates directly, their real-time verification API and inbox-placement tests rely on the same underlying standards. A successful test isn’t about the list alone—it’s about proving your sending environment is trustworthy. You can test this setup with their inbox placement feature to simulate how real inboxes will handle your next campaign.

Ultimately, your SMTP security is invisible until it fails. Using openssl s_client is a low-cost way to prevent those failures before they cost you engagement.

Best Practices for Sustaining SMTP Security on Ubuntu

You must verify SSL certificates during setup and after any change to prevent insecure connections. Use automated tools to check expiration dates, rely on CA-signed certificates like Let’s Encrypt for public services, and embed verification in deployment pipelines to catch issues before they break email delivery. This reduces both security risks and downtime.

Verification & Monitoring

• Always run openssl s_client after configuring SMTP with SSL/TLS to confirm certificate validity and chain trust at setup and after every config update.
• Set up a cron job to check certificate expiration dates on scheduled intervals, especially for public-facing services. A simple script can alert you 30 days before expiry.
• Use trusted Certificate Authorities like Let’s Encrypt — their free, automated certificates are widely recognized and reduce configuration errors.

Automation & Integration

• Integrate openssl s_client checks into your CI/CD pipeline to catch invalid or expired certs early, before deployment to production.
• Combine these checks with monitoring tools like Nagios or Prometheus to detect TLS failures in real time and trigger alerts.
• For mission-critical services, test the entire SMTP workflow — not just the cert — using inbox placement tools to verify delivery success and inbox filtering behavior. Test inbox placement regularly in production environments to validate both TLS and content filters.

Following the RFC 5246 guidelines for TLS ensures compatibility and security. Automated verification in your pipeline is not optional—it’s the only reliable way to maintain SMTP integrity across updates.

Final Word: SSL Verification Is Part of Reliable Email Infrastructure

A trusted SSL certificate is not a luxury — it’s a requirement for modern email delivery. Without proper TLS encryption, messages are vulnerable, domains are flagged, and sender reputation suffers.

Using openssl s_client on Ubuntu gives you full visibility into your SMTP connection health. You can inspect certificate chains, validate expiration, and detect misconfigurations before they cause delivery failures.

When paired with tools like Emaillistchecker.io for list hygiene, you build a system that sends securely, delivers reliably, and maintains sender reputation across all channels.

Keep reading

• Bulk email verification and list cleaning: when and how to verify (complete guide)
• How to Use Email Verification to Identify Unengaged Subscribers for Sunset Policies
• Intermittent Certificate Errors During Email Verification Processes
• How to Audit Verified Email Sources Using Exchange Online Connectors and Mail Flow Logs
• How to Reduce List Fatigue with Sunset Policies for Unengaged Subscribers

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

Frequently asked questions

Can I verify an SMTP SSL certificate without installing openssl?

No — openssl is the standard command-line tool for SSL verification. It’s available by default on most Ubuntu systems.

What if openssl s_client shows 'Verify return code: 0' but the email still fails to send?

The certificate is valid, but the issue may be elsewhere: authentication failure, rate limiting, or a blocked IP range.

Is it safe to use a self-signed certificate for internal email servers?

It can work internally if the certificate is manually trusted. However, it’s not suitable for outbound mail to public providers.

How often should I check my SMTP server’s SSL certificate?

Automatically check it weekly in production environments, especially if using automated renewal tools like Certbot.

Does Emaillistchecker.io test SSL certificate validity?

No — it doesn’t verify SMTP certificates. However, its inbox-placement tests can detect deliverability issues caused by weak SSL.

Why does my email client reject the connection even with a valid certificate?

The issue could be incorrect port usage, missing STARTTLS directive, or a misconfigured local firewall.

Can I automate openssl s_client checks on Ubuntu?

Yes — use bash scripts with cron or integrate the command into monitoring tools like Nagios or Prometheus.

What’s the difference between SMTPS and STARTTLS?

SMTPS uses port 465 with SSL from the start; STARTTLS uses port 587 and upgrades the connection after the initial handshake.

How do I know if a certificate is issued by a trusted CA?

The 'Verify return code: 0' result means the system trusts the certificate chain built from known root CAs.

Is there a browser-based tool to test SMTP SSL verification?

No — browsers don’t support direct SMTP connection checks. Use command-line tools like openssl s_client instead.

Can a valid SSL certificate prevent my email from being marked as spam?

Not directly — but weak security or certificate issues can harm sender reputation, increasing the risk of spam filtering.

What does 'Verify return code: 2' mean in the output?

It indicates a self-signed certificate. While acceptable in internal systems, it will not be trusted by external mail providers.