IMAP Server Test: Ports 143, 993, STARTTLS, TLS Certificates, and Capabilities

What the IMAP Server Test Does

The mxio IMAP Server Test connects to an IMAP server on ports 143 and 993, negotiates TLS (either via STARTTLS or implicit TLS), reads the server's CAPABILITY list, and validates the TLS certificate. It reports whether the server is reachable, what IMAP extensions it supports, and whether its encryption configuration is sound.

This is a connectivity and capability test. It does not authenticate to a mailbox or read email — it verifies that the server is accepting connections and advertising the features that email clients depend on.

The Two IMAP Ports

IMAP uses two standard ports with different TLS models:

Port 143: STARTTLS

Port 143 is the original IMAP port. The connection starts in plaintext, the server sends a greeting and may include initial capabilities, and the client can issue a STARTTLS command to upgrade to TLS before authenticating. After the TLS handshake, the server may advertise additional capabilities that were hidden in the pre-TLS phase (servers commonly withhold AUTH=PLAIN until the connection is encrypted).

Port 993: Implicit TLS (IMAPS)

Port 993 wraps the entire IMAP session in TLS from the initial TCP connection. There is no plaintext phase. The TLS handshake completes before the server sends its IMAP greeting. This is the recommended configuration per RFC 8314, which encourages implicit TLS over STARTTLS for all mail access protocols.

Most modern email clients connect on port 993 by default. Port 143 with STARTTLS is still widely supported but is considered the legacy path.

STARTTLS vs. Implicit TLS

The same distinction applies to IMAP as to SMTP:

STARTTLS (port 143): Connection starts unencrypted. The client sends STARTTLS, the server responds OK, and both sides perform a TLS handshake. A network attacker could strip the STARTTLS capability from the server's greeting, forcing a plaintext session.

Implicit TLS (port 993): TLS handshake happens immediately upon TCP connection. No plaintext phase, no stripping attack surface. The IMAP greeting arrives inside the encrypted channel.

The tool reports starttls_supported: true for port 143 connections that successfully negotiate STARTTLS, and implicit_tls: true for port 993.

Understanding IMAP Capabilities

After connecting, the tool issues a CAPABILITY command and reports the server's response. Capabilities define what the server supports — they determine which features are available to email clients. The tool reads capabilities at each phase of the connection (banner, post-CAPABILITY command, post-STARTTLS) and reports the final merged set.

Common Capabilities

What Missing Capabilities Mean

If a capability is absent, the email client must either work without it or fall back to a less efficient method. For example:

• No IDLE — The client must poll for new messages at intervals instead of receiving push notifications. This increases latency for new mail delivery and uses more bandwidth.
• No CONDSTORE / QRESYNC — The client must re-download message flags and folder state on every sync, which is slow for large mailboxes.
• No COMPRESS=DEFLATE — The connection runs uncompressed. This matters more on slow or metered connections.

These are not errors — they are feature gaps. Not every IMAP server implements every extension. But knowing which capabilities are present helps diagnose client behavior issues ("why does my email client poll instead of pushing?").

Reading the TLS Results

The TLS diagnostics are the same as the SMTP Server Test. For each port, the tool reports:

• TLS version — TLS 1.2 or 1.3 expected. Versions below 1.2 are flagged as weak.
• Cipher suite — The negotiated encryption algorithm.
• Certificate details — Subject, issuer, SANs, expiry, chain validation, hostname match, and self-signed detection.

Common Certificate Issues

Hostname mismatch — The certificate covers mail.example.com but the client connects to imap.example.com. This happens when MX records, IMAP server hostnames, and certificates are managed separately. The fix: ensure the certificate's Subject Alternative Names include all hostnames clients use to connect.

Expired certificate — Email clients will warn users or refuse to connect. Automate renewal with ACME (Let's Encrypt).

Self-signed certificate — Email clients will show a security warning. Acceptable for internal or test servers, not for production mail services.

When to Use IMAP Test vs. SMTP Test

IMAP is the mailbox access protocol — it lets clients read, search, and manage email that has already been delivered. SMTP is the delivery and relay protocol — it moves email between servers and from clients to servers. They serve different roles in the email infrastructure.

If users report they cannot send email, test SMTP. If users report they cannot read or receive email in their client, test IMAP. If email is not arriving at all, start with MX Lookup to verify DNS routing, then test SMTP on the destination server to confirm it is accepting connections.

Test your IMAP server