Port 993 – IMAPS (IMAP over SSL)

Port 993 is the default port for IMAPS (IMAP over implicit TLS) — the same Internet Message Access Protocol that runs in cleartext on port 143, but wrapped in TLS from the very first byte. A client that connects to 993 completes the TLS handshake before any IMAP command is sent, so the login, the folder list, and every message pulled with FETCH are encrypted end to end — there is no plaintext phase and no opportunistic STARTTLS upgrade for an attacker to strip or inject into. That makes IMAPS the secure, recommended way to read server-side mail, and it is why a well-run host answers on 993 and pushes clients off 143. For a tester, an open port 993 is rarely about breaking the encryption; it is about what the encryption doesn’t cover — the credentials in front of the tunnel and the mailbox behind it.

Why It’s Open

IMAPS is how most mail clients are meant to read mail, so port 993 is open on almost anything that stores a mailbox: shared hosting and cPanel/Plesk boxes, ISP and small-business mail servers, self-hosted Dovecot, Cyrus, Zimbra, and iRedMail stacks, on-prem Microsoft Exchange, and appliances that expose a mailbox for their own alerts. The daemon is usually Dovecot or Cyrus on Linux, Exchange on Windows, or whatever the hosting panel bundled. On hardened servers 993 is often the only IMAP port left answering — plaintext 143 has been retired — which makes it the front door to the whole mailbox. Where 993 is open its siblings usually are too: check for cleartext IMAP on 143, the POP3 pair on 110 and 995, and the SMTP send side on 465 and 587.

Common Risks

• Password spraying and credential stuffing that bypass MFA. This is the real modern risk on 993, and encryption does nothing to stop it. Most IMAP daemons ship without login throttling, and legacy IMAP basic auth over IMAPS sidesteps multi-factor entirely — a third-party client speaking IMAP never sees the MFA prompt. TLS just hides the guessing from the network, so a slow, distributed spray against 993 looks like ordinary isolated login failures while it works.
• Full mailbox access over an inspection-blind channel. IMAP keeps everything server-side, so a single working credential exposes every folder, the full search index, and the entire message history via LIST and FETCH. Because it all rides inside the TLS tunnel, the read and the bulk export are invisible to the IDS, WAF, and DLP that can’t see into 993 — and the attacker persists by adding forwarding or delegation rules.
• Weak TLS protocols and ciphers on the listener. An IMAPS port that still negotiates SSLv3, TLS 1.0/1.1, RC4, or export/DES ciphers can be downgraded or, with a recorded session, decrypted after the fact (POODLE, DROWN, Sweet32). The one thing 993 exists to provide is undone by a sloppy TLS config.
• Expired, self-signed, or mismatched certificates. Implicit TLS is only as strong as certificate validation. A wrong-CN, self-signed, or long-expired cert trains users to click through the warning, and an active man-in-the-middle who can front the connection then reads the plaintext.
• Heartbleed-class TLS-stack bugs. An unpatched OpenSSL on the IMAPS listener (CVE-2014-0160) leaks private keys, session data, and the very credentials and mail the tunnel was protecting, straight out of process memory — no login required.
• Banner and capability disclosure. The * OK greeting and the CAPABILITY response, though delivered inside TLS, still name the software and version (* OK Dovecot ready.) and advertise the AUTH= mechanisms — handing you the daemon’s CVE list and confirming whether basic auth is a spray target.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab the banner

nmap -sV -p 993 <target>

Inspect the TLS layer — certificate, protocols, ciphers

nmap -p 993 --script ssl-cert,ssl-enum-ciphers,ssl-heartbleed,ssl-poodle <target>

ssl-cert prints the issuer, CN/SAN, and expiry; ssl-enum-ciphers grades every protocol and cipher the listener accepts; ssl-heartbleed tests for CVE-2014-0160. sslscan <target>:993 or testssl.sh <target>:993 give the same picture in more detail.

Pull IMAP capabilities through the TLS tunnel

openssl s_client -connect <target>:993 -crlf
# once the TLS handshake completes:
a1 CAPABILITY
a2 LOGOUT

Because 993 is implicit TLS, you connect straight with s_client — there is no -starttls imap flag as there is on port 143. Look at the CAPABILITY line for the advertised AUTH= mechanisms (is AUTH=PLAIN/AUTH=LOGIN basic auth offered?) and any LOGINDISABLED. Nmap can also run the IMAP scripts over the tunnel automatically: nmap -sV -p 993 --script imap-capabilities,imap-ntlm-info <target>.

Walk a session by hand (inside TLS)

openssl s_client -connect <target>:993 -crlf
a1 LOGIN victim secret
a2 LIST "" "*"
a3 SELECT INBOX
a4 FETCH 1 BODY[]
a5 LOGOUT

LIST enumerates every folder, SELECT INBOX opens one, and FETCH 1 BODY[] pulls the first message — all inside the encrypted session, so a valid login gives you the whole mailbox.

Password spraying and brute-force with Hydra

hydra -L users.txt -P passwords.txt -f imaps://<target>

Hydra’s imaps module handles the TLS wrap itself; keep the guess rate low and wide to mimic real spraying and to test whether any lockout fires.

Metasploit

msfconsole -q
use auxiliary/scanner/imap/imap_version
set RHOSTS <target>
set RPORT 993
set SSL true
run

Record every open 993, the certificate and cipher findings, the daemon banner, the advertised auth mechanisms, and any credential that works, so the evidence lands in the pentest report instead of a terminal you’ll close by mistake.

What to Look For

Known CVEs and Exploits

• CVE-2014-0160 (Heartbleed) — OpenSSL 1.0.1 before 1.0.1g mishandles TLS heartbeat packets, letting an unauthenticated attacker read up to 64 KB of process memory per request from any TLS listener, IMAPS included. That memory routinely holds private keys, session tokens, and the very usernames, passwords, and mail the tunnel exists to protect. CVSS 7.5, tested with nmap --script ssl-heartbleed -p 993, Metasploit’s auxiliary/scanner/ssl/openssl_heartbleed (set RPORT 993), and Exploit-DB 32745.
• CVE-2016-0800 (DROWN) — if the same certificate/key is served anywhere with SSLv2 still enabled, a Bleichenbacher RSA padding oracle lets an attacker decrypt a recorded IMAPS/TLS session. Affects OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g. CVSS 5.9 — the concrete reason to disable SSLv2 across every service that shares the IMAPS key.
• CVE-2019-11500 — Dovecot before 2.2.36.4 and 2.3.x before 2.3.7.2 mishandle the NUL byte while scanning quoted strings in the IMAP (and ManageSieve) parser, causing a pre-authentication out-of-bounds heap write that can lead to information disclosure or remote code execution. Rated CVSS 9.8 and the most serious modern bug to hit an IMAP stack. It lives in the protocol parser that runs after the TLS handshake, so implicit TLS on 993 is no defence — the flaw is reachable pre-login over the encrypted session exactly as it is over cleartext 143.
• CVE-2024-23185 — Dovecot up to 2.3.21 builds its message-header parse buffer with no size limit, so a message with very large headers drives memory usage until the service exhausts resources — a crafted message becomes a denial of service. CVSS 7.5.

The STARTTLS command-injection class that makes cleartext 143 risky (the CVE-2011-1926 family) does not apply to 993: with implicit TLS there is no plaintext negotiation phase for an attacker to inject into. That is the security advantage of IMAPS — but, as the CVEs above show, it does not cover the daemon’s own parser bugs or a weak TLS configuration.

Mitigation

• Enforce strong TLS with a valid certificate. Require TLS 1.2 or 1.3 on the listener and disable SSLv2/SSLv3 and TLS 1.0/1.1 along with RC4, export, and DES ciphers (in Dovecot, ssl_min_protocol = TLSv1.2 and a hardened ssl_cipher_list). Serve a CA-signed certificate with the correct CN/SAN so clients never learn to click through warnings.
• Kill legacy basic auth and require MFA. Disable app-password / legacy IMAP auth and require OAuth2 with multi-factor at the mail gateway. Microsoft deprecated Basic Authentication for IMAP in Exchange Online in October 2022, and Google has tightened the same path, precisely because legacy IMAP over 993 was the MFA-bypass route.
• Use strong credentials and throttle logins. Enforce a real password policy and put fail2ban or the daemon’s own rate limiting (Dovecot’s auth_failure_delay / auth_penalty) on repeated failures, then alert on slow, distributed spraying that stays under a per-IP threshold.
• Patch the IMAP server and its TLS library. Run Dovecot 2.3.7.2 or later (CVE-2019-11500), keep Cyrus and Exchange current, and keep OpenSSL patched against Heartbleed and DROWN. Never expose an unmaintained IMAP daemon on 993.
• Watch for persistence, not just logins. Alert on new mail forwarding or delegation rules and on geographic anomalies in successful IMAP logins — a mailbox compromise over the encrypted channel usually reveals itself that way rather than in the traffic.
• Prefer 993 over cleartext 143, and firewall it. Standardise clients on IMAPS, retire plaintext 143 where they allow it, and restrict 993 to the networks that genuinely need it.

Real-World Example

In 2019 Proofpoint published a six-month study of IMAP-based password spraying against major cloud tenants. Roughly 60% of Microsoft Office 365 and G Suite tenants were targeted, about a quarter suffered at least one successful breach, and the campaigns ran a 44% success rate. Crucially, the guessing rode over IMAPS: the connections to 993 were TLS-encrypted, so the spray traffic was opaque to network monitoring, and legacy IMAP basic auth meant a third-party client could hammer credentials without ever triggering the multi-factor prompt. The encryption that makes 993 the “secure” port also blinded defenders to the attack running across it. Once in, attackers set forwarding and delegation rules and read the mailbox at will. The fix was not stronger TLS — the transport was already encrypted — but turning off legacy/basic IMAP auth, forcing modern auth with MFA, and rate-limiting logins so the spray had nowhere to hide.

FAQ

What is port 993 used for?

Port 993 is the default port for IMAPS — IMAP wrapped in TLS. A mail client connects to it, completes a TLS handshake, and then authenticates and reads, searches, and manages messages that stay stored on the server in folders. Unlike plain IMAP on port 143, the entire session — login and mail alike — is encrypted from the first byte, which is why 993 is the port modern setups use for secure mailbox access.

Is port 993 secure?

The transport is: IMAPS encrypts the whole session with implicit TLS, so credentials and mail aren’t sniffable on the wire and there is no STARTTLS phase to strip. But “encrypted” isn’t “safe” — password spraying and credential stuffing still work against 993 (and legacy basic auth over it bypasses MFA), a single stolen login exposes the entire mailbox, and a weak TLS config or an unpatched OpenSSL (Heartbleed) can undo the encryption itself. Treat 993 as the right port to use, then harden the authentication and TLS behind it.

What’s the difference between port 143 and port 993?

Both carry IMAP. Port 143 is the cleartext version — encryption is optional, via an opportunistic STARTTLS upgrade that an active attacker can strip, and often isn’t enforced. Port 993 is IMAPS: the identical protocol wrapped in TLS from the first byte, with no unencrypted phase to strip or inject into. For anything sensitive, 993 is the safe default and 143 should be retired or forced to require TLS.

Is IMAPS the same as IMAP?

Yes — IMAPS is IMAP; the “S” only means the session runs over TLS. Every IMAP command (LOGIN, LIST, SELECT, FETCH) is identical; the difference is that on 993 they travel inside an encrypted tunnel instead of in the clear. That is why a Dovecot or Cyrus parser bug like CVE-2019-11500 affects the daemon on 993 just as it does on 143 — the encryption protects the wire, not the code.

How do I test or secure port 993?

Test it by fingerprinting the daemon (nmap -sV -p 993), grading the TLS layer (nmap --script ssl-cert,ssl-enum-ciphers,ssl-heartbleed -p 993 or testssl.sh <target>:993), pulling capabilities with openssl s_client -connect <target>:993, and checking for lockout with a controlled Hydra spray. Secure it by enforcing TLS 1.2+ with a valid certificate, disabling legacy basic auth in favour of OAuth2 with MFA, rate-limiting failed logins, patching Dovecot/Cyrus/Exchange and OpenSSL, and firewalling 993 to trusted networks.

TL;DR

• Service: IMAPS (IMAP over implicit TLS), encrypted server-side mailbox access
• Default port: 993/TCP (cleartext IMAP is 143/TCP)
• Biggest risk: password spraying / credential stuffing that bypass MFA, plus full mailbox exposure over a channel network defenders can’t inspect
• Also watch: weak TLS protocols/ciphers, bad certificates, and Heartbleed-class OpenSSL bugs on the listener
• Mitigation: enforce TLS 1.2+ with valid certs, kill legacy basic auth and require MFA, use strong creds with rate-limiting/lockout, patch the IMAP server and OpenSSL, and prefer 993 over cleartext 143