SMTP TLS Checker - Test Your Mail Server's STARTTLS Security
Check whether your mail server advertises STARTTLS and supports secure SMTP connections. A comprehensive SMTP TLS test can examine TLS protocol versions, certificate validity, hostname matching, and negotiated ciphers for individual MX hosts. These checks help identify encryption configuration problems, but do not by themselves guarantee encrypted delivery for every email.
This page does not open an SMTP connection or inspect a certificate. The form continues to MXScan signup. The report below is sample data until you choose to view it.
Why SMTP TLS Matters for Email Security
SMTP TLS can protect message content during a server-to-server transfer when both sides negotiate it. MTA-STS is how a domain can publish a requirement for TLS, and TLS-RPT is how supporting receivers can send reports. Neither one proves that every message was encrypted.
Data Protection
Encrypts email content during server-to-server transfer
Credential Security
Protects SMTP authentication credentials
Privacy Compliance
Meets regulatory requirements for data in transit
Deliverability
Required by many providers for email acceptance
Example report - illustrative values only
SAMPLE DATA - NOT A LIVE SCAN. The host names, STARTTLS labels, TLS versions, certificate labels, cipher names, and B+ grade demonstrate the report layout. They are not a probe of your domain.
MX Host Analysis
Cipher Suite Analysis
✅ Strong Ciphers
⚠️ Weak Ciphers
TLS Security Grade
Good configuration with room for improvement
How to interpret an SMTP TLS test
STARTTLS in an SMTP greeting means the server offers to upgrade that connection to TLS. It does not prove that a particular message was encrypted, or that every sender will use the offer. Opportunistic TLS can fall back to an unencrypted session when the other side does not require encryption.
A completed handshake is not the same as certificate verification. Verification checks the certificate chain, the validity dates, and whether the certificate name matches the mail host that was connected. A handshake can finish against a certificate that does not match the MX hostname.
When neither the sender nor the receiver requires TLS, mail can still be delivered without encryption. When one side requires TLS, a failed handshake or a missing STARTTLS offer can lead to a deferral or a rejection instead. Results also differ by MX host: a passing result for one host does not describe the others.
The sample report on this page uses mail.example.com and backup.example.com. Those names, versions, and the B+ grade are layout examples. They are not findings for a domain you enter here.
TLS Protocol Security
Understanding TLS version security implications.
✅ Secure Protocols
Latest standard with improved security and performance
Widely supported and secure when properly configured
❌ Insecure Protocols
Contains vulnerabilities, should be disabled
Multiple known vulnerabilities, must be disabled
Completely compromised, never use
SMTP TLS Hardening Guide
Best practices for securing your mail server's TLS configuration.
Enable Strong Protocols Only
Disable TLS 1.1 and below, enable TLS 1.2 minimum:
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
Configure Strong Ciphers
Prefer AEAD ciphers and disable weak algorithms:
Certificate Best Practices
• Use certificates from trusted CAs
• Include all MX hostnames in SAN
• Use 2048-bit RSA or 256-bit ECDSA keys minimum
• Enable OCSP stapling for better performance
Run a Full Email Security Audit
Review the separate authentication and DNS checks. This page does not run them together.
Frequently Asked Questions
Are TLS 1.0/1.1 still risky?
TLS 1.0 and 1.1 have known vulnerabilities and are no longer appropriate for new mail-server configurations. TLS 1.2 remains widely used. TLS 1.3 is the current version where both sides support it. A handshake that succeeds does not by itself prove the certificate name matches the mail host.
How to prefer modern ciphers?
Mail-server configuration can prefer AEAD cipher suites such as AES-GCM and ChaCha20-Poly1305 and can disable obsolete suites. A cipher list in an example report is not a measurement of your server.
What if STARTTLS is not available?
If a server does not advertise STARTTLS, a sender that does not require TLS can still deliver the message without encryption. A sender or receiver that requires TLS can defer or reject the message instead. STARTTLS availability on one MX host does not prove that every message to or from the domain is encrypted.