IMAP/POP3/SMTP TLS Test

This test connects to a mail server host the way a mail client does when fetching and sending mail: on the six client ports for IMAP, POP3 and mail submission. It answers whether a client can establish a secure, encrypted connection and whether credentials are protected. Unlike SMTP transport on port 25, a valid certificate that matches the hostname is mandatory here, because mail clients reject an untrusted connection.

What this tool checks

You enter a host, not a domain name: the server on which IMAP, POP3 and the SMTP submission service actually run (often mail.example.com or imap.example.com). Which host that is the Autoconfig Check tells you. Checked per port: TCP reachability and connection time, the greeting banner, the negotiated TLS version and cipher suite, the certificate (chain against the public CAs, validity and match against the entered hostname), the capabilities offered via CAPABILITY / CAPA / EHLO and the AUTH mechanisms. On the cleartext ports 143, 110 and 587 it also checks whether STARTTLS or STLS is offered at all and whether the server allows a login before the TLS negotiation. No login is attempted, no LOGIN, USER or AUTH command is sent.

Reading the result

A port that accepts no connection is not an error: hardly any server offers all six ports. What matters are the ports that answer. A port is green when the TLS connection holds, the certificate chain is valid and the hostname matches. An untrusted or expired certificate and a hostname that does not match the certificate are an error here, not a mere note. Warnings appear for a TLS version below 1.2, a short RSA key, a soon-expiring certificate and the case where a cleartext port allows a login before STARTTLS. If a cleartext port offers no STARTTLS at all, that is an error, because a client then sends credentials unencrypted or the connection fails.

Background

Encryption of IMAP and POP3 is described in RFC 2595, which also introduces the LOGINDISABLED capability: if it is set in the pre-TLS CAPABILITY, the server refuses a cleartext login. IMAP itself is RFC 3501, POP3 is RFC 1939 with the CAPA extension from RFC 2449, mail submission is RFC 6409. RFC 8314 today recommends the implicit TLS ports 993, 995 and 465 over STARTTLS on 143, 110 and 587, because an attacker on the path can strip the STARTTLS offer from the cleartext preamble and thus force a downgrade.

Common problems and how to fix them

• Certificate does not match the hostname. The certificate is for example.com, but the client connects to mail.example.com. Issue a certificate with the right name (or a matching SAN).
• Self-signed or expired certificate. Mail clients abort the connection. Use a certificate from a public CA and automate renewal.
• Cleartext port without STARTTLS. Port 143 or 110 is open but offers no STARTTLS / STLS. Either enable STARTTLS or close the cleartext port and offer only 993/995.
• Login possible before TLS. On 143 LOGINDISABLED is missing, on 110 USER is offered before STLS, on 587 AUTH before STARTTLS. Configure the server so that a login is only possible after successful TLS.
• Old TLS version. The port still negotiates TLS 1.0/1.1. Enforce TLS 1.2 as the minimum, allow TLS 1.3.