dotvitals

SMTP TLS Checker

Connect to a mail server and check STARTTLS support, certificate validity and the negotiated protocol.

Try

Fix it here

This builds the change the checks above ask for, and validates it against the same rules.

SMTP TLS configuration

The Postfix, Exim or Dovecot configuration that makes STARTTLS work on port 25 — at a security level that adds encryption without refusing anybody's mail — checked by running the resulting session back through our own SMTP TLS scanner, and replaced by an honest procedure where the mail servers belong to Microsoft or Google.

We check the configuration against the mail servers this domain actually publishes, and the certificate has to match the name senders connect to. A certificate for some other name fails the check even when STARTTLS itself works.

About the smtp tls checker

This tool opens a real SMTP connection to a mail server on port 25, the port used for server-to-server delivery, and issues an EHLO command to see whether the server advertises STARTTLS support. If it does, the tool attempts the STARTTLS upgrade and inspects the resulting TLS session, since advertising support and actually completing a working handshake are not the same thing.

It reports the negotiated TLS protocol version and cipher suite, and separately validates the certificate presented during the handshake: whether it is currently valid, whether the hostname matches, and whether the chain leads to a trusted root. A server can complete a TLS handshake with an expired or self-signed certificate, which still encrypts the connection but does not authenticate who is on the other end.

This distinction matters because opportunistic STARTTLS without certificate validation only protects against passive eavesdropping, not an active attacker who can intercept the connection, since nothing in plain STARTTLS forces a sender to check the certificate before delivering. MTA-STS and DANE exist specifically to close that gap by telling senders the certificate must validate. A mail server with no STARTTLS support at all delivers everything, including message bodies and credentials on authenticated submission ports, in clear text on the wire, which is a serious and easily fixed problem on any server still running that way.

Common questions

Why check port 25 instead of 587?
Port 25 is used for server-to-server delivery, which is what other domains' mail servers connect to when sending you mail; port 587 is for user submission from an email client, a different scenario.
Can a server pass this check but still be insecure?
Yes. STARTTLS support with an invalid or self-signed certificate still encrypts the connection but does not authenticate the server, which only protects against passive eavesdropping, not an active interception.
What TLS version should a mail server use?
TLS 1.2 or 1.3. Older versions such as TLS 1.0 and 1.1 are deprecated and should be disabled on any server still offering them.
How does this relate to MTA-STS?
MTA-STS tells senders to require a valid, trusted certificate during STARTTLS rather than accepting any certificate, closing the gap that plain opportunistic STARTTLS leaves open to interception.
What this tool checks (9 rules)
  • email.smtp-tls.banner-malformed — Mail server's SMTP greeting does not conform to the protocol
  • email.smtp-tls.certificate-expired — Mail server's TLS certificate has expired or is not yet valid
  • email.smtp-tls.certificate-name-mismatch — Mail server's certificate does not cover its own hostname
  • email.smtp-tls.certificate-untrusted — Mail server's TLS certificate does not verify
  • email.smtp-tls.no-starttls — Mail server does not offer STARTTLS
  • email.smtp-tls.port-unreachable — Mail server does not accept connections on port 25
  • email.smtp-tls.probe-unavailable — SMTP transport security was not tested
  • email.smtp-tls.starttls-failed — STARTTLS is advertised but the handshake does not complete
  • email.smtp-tls.weak-protocol — Mail server negotiates a deprecated TLS version