How to Verify SSL/TLS Encryption on Your Inbound Mail Exchanger

To verify SSL TLS encryption on your inbound mail exchanger, you need to test how your mail server handles secure connections during SMTP handshakes. By initiating a secure STARTTLS session or connecting directly via SMTPS, you can inspect the active cipher suites, certificate validity, and protocol versions your mail exchange (MX) host presents to the world. Securing your inbound mail path prevents downgrade attacks, eavesdropping, and data interception during transit across the internet.

Before diving into manual command-line diagnostics, you can quickly analyze your setup using the Email Security Checker to spot missing STARTTLS declarations, weak cipher configurations, and expired certificates instantly.

Understanding Inbound Mail Exchange Encryption

When sending and receiving email, Simple Mail Transfer Protocol (SMTP) traditionally operates in plaintext. To secure this transit, mail servers rely on STARTTLS or port 465 (SMPS). Your inbound mail exchanger must present a valid SSL/TLS certificate that matches its hostname and supports modern cryptographic protocols like TLS 1.2 and TLS 1.3.

Without proper configuration, malicious actors on the network path can perform STARTTLS stripping attacks, forcing your mail server to accept unencrypted mail. Verifying your encryption posture guarantees that threat actors cannot read sensitive email payloads traversing public networks.

Finding Your Inbound Mail Exchanger

Before you can test encryption, you must identify which servers handle incoming mail for your domain by looking up your MX records. You can use standard command-line DNS tools to find these targets.

Using dig for MX Records

Run the following command in your terminal to query mail exchangers for a domain like example.com:

dig example.com MX +short

Sample output:

10 mail.example.com.
20 backup-mail.example.com.

Once you have the hostnames, resolve them to IP addresses (such as 192.0.2.25 for IPv4 or 2001:db8::25 for IPv6) to target your testing accurately.

Step-by-Step Guide to Verifying SSL/TLS on Your MX Host

Testing your mail exchanger requires simulating a mail client connection and initiating the TLS handshake. You can accomplish this across multiple operating systems using built-in or easily accessible tools.

Method 1: Using OpenSSL for Deep Certificate Inspection

The openssl s_client utility is the industry standard for examining the cryptographic handshake, certificate chain, and negotiated cipher suites of an inbound mail exchanger.

Run the following command against your mail exchanger:

openssl s_client -connect mail.example.com:25 -starttls smtp

Sample output snippet:

CONNECTED(00000003)
---
Certificate chain
 0 s:CN = mail.example.com
   i:C = US, O = Let's Encrypt, CN = R3
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

This output confirms that the server successfully negotiated TLSv1.3 using a strong cipher and a trusted certificate authority.

Method 2: Testing via PowerShell on Windows

If you are managing infrastructure from a Windows environment, you can establish a TCP connection and inspect the stream, though deep TLS inspection usually requires third-party modules or OpenSSL for Windows. Alternatively, you can use the built-in .NET classes within PowerShell:

$tcpClient = New-Object Net.Sockets.TcpClient
$tcpClient.Connect("mail.example.com", 25)
$stream = $tcpClient.GetStream()
$reader = New-Object IO.StreamReader($stream)
$writer = New-Object IO.StreamWriter($stream)
$writer.AutoFlush = $true

# Read server greeting
$reader.ReadLine()

# Send EHLO
$writer.WriteLine("EHLO client.example.com")
$reader.ReadLine()

# Request STARTTLS
$writer.WriteLine("STARTTLS")
$reader.ReadLine()

Method 3: Using Ncat for Port Verification

To check if port 465 (SMTPS) or port 587/25 with STARTTLS is open and responding to basic probes, use ncat or standard telnet:

ncat -v mail.example.com 465 --ssl

Comparison of Mail Encryption Testing Methods

Common Mistakes and How to Fix Them

1. Using Self-Signed Certificates

The Problem: Many mail servers default to self-signed certificates upon installation. Sending mail servers from large providers (like Google or Microsoft) will reject connections or fall back to plaintext if they cannot validate the certificate chain against a trusted root.

The Fix: Install a valid certificate issued by a recognized Public Certificate Authority (CA) on your mail transfer agent (MTA).

2. Allowing Outdated Protocols (TLS 1.0 / TLS 1.1)

The Problem: Leaving legacy protocols enabled exposes your mail exchanger to downgrade vulnerabilities.

The Fix: Update your MTA configuration (such as Postfix, Exim, or Exchange) to explicitly disable TLS 1.0 and TLS 1.1, enforcing a minimum of TLS 1.2.

3. Missing Intermediate Certificates

The Problem: Your server presents its leaf certificate, but fails to send the intermediate chain, causing validation errors for clients lacking the full chain in their local trust stores.

The Fix: Concatenate your server certificate and intermediate certificates into a single full-chain file within your MTA configuration.

Verification Checklist

• Identify all inbound MX hostnames using DNS lookups.
• Confirm port 25 accepts inbound TCP connections.
• Verify that the STARTTLS command is advertised during the SMTP EHLO greeting.
• Run an OpenSSL check to ensure TLS 1.2 or TLS 1.3 is negotiated.
• Check that the SSL certificate common name (CN) or Subject Alternative Name (SAN) matches your MX hostname.
• Validate that the certificate expiration date is well into the future.