IMAP uses port 143 for the plain connection and port 993 for IMAP over TLS (IMAPS). Use 993. Port 143 can be upgraded to an encrypted session with STARTTLS, which makes it secure in practice, but it starts in the clear and that is a meaningfully weaker position.
Every mail client setup screen asks for a port and an encryption method, and the two answers interact. Picking 993 with no encryption, or 143 with implicit TLS, produces a connection that hangs with no useful error.
The combinations that work are short enough to memorise, and worth knowing alongside the SMTP ports since you configure both at the same time.
Table of contents
- The two ports and their models
- Why 143 has not been retired
- Testing a connection
- What usually goes wrong
- IMAP versus POP3, briefly
- How this fits the rest of the stack
- FAQ
The two ports and their models
Port 993 — implicit TLS. The TLS handshake happens immediately, before any IMAP command. Nothing is ever sent in the clear. This is sometimes called IMAPS.
Port 143 — explicit TLS via STARTTLS. The connection opens in plaintext, the client asks the server what it supports, and issues STARTTLS to upgrade. Everything after that is encrypted.
Port 143 + STARTTLS -> encrypted, after an initial plaintext exchange
Port 143 + none -> plaintext, credentials readable on the wire
Port 993 + SSL/TLS -> encrypted from the first byte
Port 993 + STARTTLS -> broken, will hangThat last combination is a common configuration error. The client waits for a plaintext greeting that never comes because the server is already expecting a TLS handshake.
The corresponding settings for the rest of a mail account, since they are configured together:
- IMAP — 993 implicit TLS, or 143 with STARTTLS.
- POP3 — 995 implicit TLS, or 110 with STARTTLS.
- SMTP submission — 587 with STARTTLS, which is the standard for sending mail from a client. Port 465 is implicit TLS and also widely supported.
- SMTP relay — 25, for server-to-server transfer. Not for client submission, and blocked outbound by most consumer networks.
Why 143 has not been retired
The obvious question, since 993 is strictly better from a client’s perspective.
Historically, implicit-TLS ports were considered a deprecated approach — the IETF preferred STARTTLS on the standard port, on the grounds that allocating a second port per protocol does not scale. RFC 8314 later reversed that position for mail specifically and now recommends implicit TLS, which is why 993 is the modern advice.
Port 143 persists because:
- Internal networks. A mail server and a webmail front end on the same host talk over 143 with no encryption, because there is no network to intercept.
- Legacy clients that predate widespread implicit-TLS support.
- Server-side filtering and migration tools that connect locally.
- Compatibility. Servers keep it enabled because turning it off breaks something nobody has audited.
The security concern with STARTTLS is the stripping attack: an active attacker in the path can remove the server’s advertisement of STARTTLS support, and a client configured to upgrade opportunistically silently continues in plaintext. A client that requires TLS will refuse instead — but the requirement has to be configured, and “opportunistic” is a common default.
Implicit TLS on 993 has no such downgrade path. The connection either establishes with TLS or fails.
Testing a connection
For 993, connect with TLS directly:
openssl s_client -connect imap.example.com:993 -crlf
# expect: * OK [CAPABILITY IMAP4rev1 ...] Server readyFor 143 with STARTTLS, tell openssl to negotiate the upgrade:
openssl s_client -connect imap.example.com:143 -starttls imap -crlfOnce connected, IMAP commands are prefixed with an arbitrary tag:
a1 LOGIN username password
a2 LIST "" "*"
a3 SELECT INBOX
a4 LOGOUTThat confirms credentials and folder access independently of any mail client, which is the fastest way to determine whether a setup problem is the client or the server.
Check basic reachability first, since a firewall produces a very different failure from a certificate problem:
nc -zv imap.example.com 993
nc -zv imap.example.com 143And inspect the certificate specifically, since a name mismatch is a common cause of a client refusing to connect:
openssl s_client -connect imap.example.com:993 2>/dev/null \
| openssl x509 -noout -subject -datesWhat usually goes wrong
Connection times out. A firewall is dropping the packets, or you have the wrong port for the encryption method. Some networks block 143 outright while allowing 993.
Certificate not trusted. The certificate does not cover the hostname you connected to. Mail servers frequently have a certificate for mail.example.com while users type imap.example.com. The fix is a certificate with both names, not disabling verification in the client.
Authentication fails with correct credentials. Increasingly this is an app-password requirement — providers with two-factor authentication generally will not accept the account password over IMAP and require a generated app-specific password instead.
Works on one network, not another. Port blocking. Test from a phone on mobile data to isolate it quickly.
IMAP is disabled on the account. Several providers now default IMAP access to off for new accounts, so the port is open, the credentials are right, and the server declines anyway.
Where you control the server, the logs are decisive:
journalctl -u dovecot -f
tail -f /var/log/mail.logIMAP versus POP3, briefly
Worth stating because the port choice often comes up while deciding between them.
IMAP keeps messages on the server and synchronises state — read status, folders, flags — across every device. Delete on your phone, it is deleted on your laptop.
POP3 downloads messages and, by default, removes them from the server. It was designed for a single device with intermittent connectivity.
For essentially every modern use, IMAP is correct. POP3 remains useful in two narrow cases: pulling mail into a local archive you control entirely, and working within a very small server-side quota.
One consequence worth planning for: because IMAP keeps everything on the server, mailbox size is a server-side capacity question. On a self-hosted server that means disk headroom, and a full disk on a mail server rejects inbound mail rather than degrading gracefully.
How this fits the rest of the stack
The 143-versus-993 question is really a question about whether encryption is negotiated or assumed, and the modern answer across most protocols has settled on assumed. The same shift happened with HTTP — opportunistic upgrades gave way to HTTPS everywhere, for the same reason: anything optional can be stripped.
For web services that means certificates handled by default rather than configured per host. RunxBuild issues and renews certificates for custom domains on static sites and services, so TLS is the assumption rather than a step in a checklist. Mail is not something we offer, and a dedicated provider is the honest recommendation there. If you are pricing the web side of a project, the RunxBuild hosting calculator itemises the service, database, storage and bandwidth.
Useful related references:
- What Port is SSH: 22 (Default), How to Change, and Why
- The Unsecure HTTP Port: What Port 80 Is Still For
- Port 25: Why Your Host Blocks It and What to Use Instead
- Services on RunxBuild
FAQ
Should I use IMAP port 143 or 993?
Use 993, which is IMAP over implicit TLS — encrypted from the first byte with no downgrade path. Port 143 with STARTTLS is also encrypted in practice, but it begins in plaintext and an active attacker can strip the upgrade advertisement if the client only upgrades opportunistically.
What is the difference between IMAP and IMAPS?
IMAPS is IMAP wrapped in TLS from the start, on port 993. Plain IMAP on port 143 opens unencrypted and can optionally upgrade with the STARTTLS command. The end state is similar; the starting state is not.
Why does my IMAP connection time out?
Usually a mismatch between port and encryption method — 993 with STARTTLS selected will hang, because the client waits for a plaintext greeting that never arrives. The other common cause is a firewall blocking the port. Test with nc -zv host 993.
What are the standard mail ports?
IMAP 993 with TLS or 143 with STARTTLS; POP3 995 with TLS or 110 with STARTTLS; SMTP submission 587 with STARTTLS or 465 with implicit TLS; SMTP relay 25 for server-to-server transfer only, which most consumer networks block outbound.
Why does IMAP reject my correct password?
Most likely the provider requires an app-specific password rather than your account password, which is standard where two-factor authentication is enabled. Some providers also default IMAP access to disabled for new accounts, so the port answers and authentication still fails.