IMAP port guide: email access on port 143

IMAP keeps mail on the server and lets multiple clients synchronize the same mailbox. Clients list folders, fetch headers, download message bodies, mark messages read, move mail, delete mail, and search server-side depending on capabilities.

Unlike POP3, IMAP is designed for multi-device access. The server remains the source of truth, so storage quotas, index health, authentication policy, and latency all affect the user experience.

Port 143 is the standard IMAP port. It may start in plaintext and then upgrade with STARTTLS. If STARTTLS is required and configured correctly, credentials should not be sent before encryption is active.

Port 993 is IMAPS, where TLS starts immediately. From a security and client-configuration perspective, IMAPS is often simpler because encryption is expected from the first byte of the connection.

Open IMAP when users, applications, or migration tools need to access mailboxes with standard mail clients. Common examples include Outlook, Apple Mail, Thunderbird, mobile mail apps, helpdesk ingestion, and mailbox migration systems.

Do not expose IMAP broadly without strong authentication and abuse controls. Public IMAP attracts password spraying, credential stuffing, mailbox scraping, and brute-force attempts against old accounts.

Before allowing port 143, decide whether STARTTLS is required, whether port 993 should be preferred, which authentication methods are allowed, and whether basic passwords are acceptable. For many hosted environments, OAuth or app passwords may be safer than ordinary account passwords.

A port checker can confirm TCP reachability, but mailbox access also depends on TLS, certificates, login policy, user state, MFA, account lockout, mailbox quotas, and server-side folder/index health.

Dovecot and Cyrus IMAP are common on Linux mail systems. Configure TLS certificates, disable weak authentication, require STARTTLS on 143 if you keep it enabled, and expose 993 when clients support implicit TLS.

Microsoft Exchange and many hosted providers expose IMAP only when enabled by policy. If IMAP is not required, disable it per mailbox or tenant. If it is required, restrict legacy authentication and monitor failed logins.

For cloud and self-hosted mail servers, open only the ports users need. Many deployments can avoid public 143 entirely and use 993 with modern authentication or provider-specific secure access.

Start with an external port check against the hostname and port 143. If it is open, use openssl s_client -starttls imap -connect mail.example.com:143 to verify STARTTLS and the certificate. For IMAPS, test port 993 with openssl s_client -connect mail.example.com:993.

Then test with a real mail client or an IMAP command-line tool using the same authentication method users will use. Confirm login, folder listing, message fetch, delete or move behavior, and server logs for failed attempts.

If port 143 is closed, IMAP may be disabled, bound only to a private interface, blocked by a firewall, or replaced by IMAPS on 993. If the port is open but login fails, inspect TLS requirements, username format, password state, MFA policy, app-password requirements, and account lockout.

If login works but sync is slow or incomplete, check mailbox size, quotas, folder count, server indexes, client cache, rate limits, and antivirus or security gateways. Large mailboxes and deep folder trees often create performance symptoms that look like connection problems.

Require encryption before credentials are sent. Prefer IMAPS on 993 or mandatory STARTTLS on 143, disable weak TLS versions, monitor failed logins, and restrict legacy authentication where possible.

Use MFA-compatible access patterns, remove stale accounts, enforce lockout and rate limits, and alert on unusual source countries, impossible travel, or mailbox download spikes. IMAP exposure is mailbox exposure, not just a network port.