Port 993 IMAPS – Free, Online, Private

What listens on 993

Port 993 is implicit TLS for IMAP. The IANA name is imaps, IMAP over TLS protocol, RFC 8314 and RFC 9051. The client sends a TLS ClientHello. There is no cleartext IMAP banner. Port 143 is the cleartext port, where a client may issue STARTTLS. Mail applications that offer 'SSL' on 993 and 'STARTTLS' on 143 are describing that split. UDP 993 is reserved, not a mail transport. The certificate has to match the host name the client dialed, which is often imap.example.com and not the machine name of one backend.

The IANA service name is imaps: IMAP over TLS protocol. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 993. The service described here is the TCP one. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 993

Service notes for port 993: the IANA name is imaps (IMAP over TLS protocol), and the program people mean is IMAPS. TCP 993 is the IANA imaps port, IMAP over TLS from the first byte. Cleartext IMAP with STARTTLS is port 143. UDP 993 is reserved. TLS protects the login and the mail. It does not make a weak password safe against online guessing. Rate-limit authentication and prefer a modern IMAP server that disables cleartext mechanisms. Leaving 143 open 'for old clients' keeps a downgrade path. If every client can do 993, close 143 on the public address. The mailbox contents are still on the server. Disk encryption and access control are separate problems. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 993, you are on the wrong page.

A client set to SSL with port 143, or to STARTTLS with port 993, fails even though the server is healthy. Match the mode to the port. A second bug is a certificate for the web host presented on the mail host. TCP connects, TLS fails, and the user says the port is closed. A third is a proxy that terminates TLS and forwards cleartext to 143, so the public port is 993 and the internal listener is 143. Checking only the internal host then shows the wrong port. A fourth is a firewall that copied the 143 rule and never added 993.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 993 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. TCP 993 should complete TLS and show a certificate. openssl s_client is the right probe. A cleartext banner means this listener is not IMAPS. Port 143 being open is a separate finding.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• 993 is implicit TLS. 143 is cleartext plus optional STARTTLS.
• UDP 993 is reserved. IMAP is TCP.
• No cleartext banner is normal.
• A certificate name mismatch fails after the TCP handshake succeeds.

Linuxsudo ss -lptn 'sport = :993'
sudo lsof -nP -iTCP:993 -sTCP:LISTEN

macOSsudo lsof -nP -iTCP:993 -sTCP:LISTEN
netstat -anv -p tcp | grep '\.993[^0-9]'

Windowsnetstat -ano | findstr :993
Get-NetTCPConnection -LocalPort 993

Remotenc -vz host 993