Port 995 – POP3S (POP3 over SSL)

Port 995 is the default port for POP3S (POP3 over implicit TLS) — the same Post Office Protocol that runs in cleartext on port 110, but wrapped in TLS from the very first byte. A client that connects to 995 completes the TLS handshake before it sends USER, PASS, or a single RETR, so the login and every message pulled off the server are encrypted end to end — there is no plaintext phase and no opportunistic STLS upgrade for an attacker to strip or inject into. That makes POP3S the secure, recommended way to download mail, and it is why a well-run host answers on 995 and pushes clients off 110. For a tester, an open port 995 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

POP3S is how mail clients are meant to fetch mail when POP3 is still in use, so port 995 is open on almost anything that stores a mailbox: shared hosting and cPanel/Plesk boxes, ISP and small-business mail servers, self-hosted Dovecot and Courier stacks, Cyrus on larger sites, on-prem Microsoft Exchange, and appliances that expose a mailbox for their own alerts. The daemon is usually Dovecot or Courier on Linux, Cyrus on bigger deployments, Exchange on Windows, or whatever the hosting panel bundled. POP3 is a download-and-delete protocol — it pulls messages to one device and, by default, removes them from the server — so it is used less than IMAP today, but it is still enabled almost everywhere IMAP is. On hardened servers 995 is often the only POP3 port left answering — plaintext 110 has been retired — which makes it the front door to the whole mailbox. Where 995 is open its siblings usually are too: check for cleartext POP3 on 110, the IMAP pair on 143 and 993, 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 995, and encryption does nothing to stop it. Most POP3 daemons ship without login throttling, and legacy POP3 basic auth over POP3S sidesteps multi-factor entirely — a third-party client speaking POP3 never sees the MFA prompt. TLS just hides the guessing from the network, so a slow, distributed spray against 995 looks like ordinary isolated login failures while it works.
• Full mailbox download over an inspection-blind channel. POP3 has no folder model: a single working credential means RETR over every message in the inbox, and the account takeover is total, not partial. Because the download rides inside the TLS tunnel, the bulk export is invisible to the IDS, WAF, and DLP that can’t see into 995 — and because POP3 deletes as it goes, the theft can also empty the mailbox behind it.
• Weak TLS protocols and ciphers on the listener. A POP3S 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 995 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 POP3S 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 CAPA response, though delivered inside TLS, still name the software and version (+OK Dovecot ready.) and advertise the SASL 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 995 <target>

Inspect the TLS layer — certificate, protocols, ciphers

nmap -p 995 --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>:995 or testssl.sh <target>:995 give the same picture in more detail.

Pull POP3 capabilities through the TLS tunnel

openssl s_client -connect <target>:995 -crlf
# once the TLS handshake completes:
CAPA
QUIT

Because 995 is implicit TLS, you connect straight with s_client — there is no -starttls pop3 flag as there is on port 110. Look at the CAPA output for the advertised SASL mechanisms (is PLAIN/LOGIN basic auth offered? is USER/APOP enabled?). Nmap can also run the POP3 scripts over the tunnel automatically: nmap -sV -p 995 --script pop3-capabilities,pop3-ntlm-info <target>.

Walk a session by hand (inside TLS)

openssl s_client -connect <target>:995 -crlf
USER victim
PASS secret
STAT
LIST
RETR 1
QUIT

STAT returns the message count and mailbox size, LIST enumerates messages, and RETR 1 pulls the first one — 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 pop3s://<target>

Hydra’s pop3s module handles the TLS wrap itself (equivalently, hydra -S -s 995 ... pop3); keep the guess rate low and wide to mimic real spraying and to test whether any lockout fires.

Metasploit

msfconsole -q
use auxiliary/scanner/pop3/pop3_version
set RHOSTS <target>
set RPORT 995
set SSL true
run

use auxiliary/scanner/pop3/pop3_login
set RHOSTS <target>
set RPORT 995
set SSL true
set USER_FILE users.txt
set PASS_FILE passwords.txt
set STOP_ON_SUCCESS true
run

Record every open 995, 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, POP3S 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 995, Metasploit’s auxiliary/scanner/ssl/openssl_heartbleed (set RPORT 995), 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 POP3S/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 POP3S 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, POP3, and ManageSieve parsers, causing a pre-authentication out-of-bounds heap write that can lead to information disclosure or remote code execution. Rated CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and the most serious modern bug to hit a POP3 stack. It lives in the protocol parser that runs after the TLS handshake, so implicit TLS on 995 is no defence — the flaw is reachable pre-login over the encrypted session exactly as it is over cleartext 110.
• CVE-2020-12673 — Dovecot before 2.3.11.3. A specially formatted NTLM SASL request triggers an out-of-bounds read that crashes the authentication service, taking POP3S (and IMAP) logins down with it. No credentials needed, and it fires inside the TLS tunnel just as it would in the clear. CVSS 7.5.

The STLS/STARTTLS command-injection class that makes cleartext 110 risky (the CVE-2011-1926 family) does not apply to 995: with implicit TLS there is no plaintext negotiation phase for an attacker to inject into. That is the security advantage of POP3S — 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 POP3 auth and require OAuth2 with multi-factor at the mail gateway. Microsoft deprecated Basic Authentication for POP3 in Exchange Online in October 2022, and Google has tightened the same path, precisely because legacy POP3 over 995 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 POP3 server and its TLS library. Run Dovecot 2.3.11.3 or later (CVE-2019-11500, CVE-2020-12673), keep Courier, Cyrus, and Exchange current, and keep OpenSSL patched against Heartbleed and DROWN. Never expose an unmaintained POP3 daemon on 995.
• Watch for persistence and bulk download, not just logins. Alert on new mail forwarding or delegation rules and on a mailbox being drained by RETR right after a successful login — a POP3 compromise over the encrypted channel usually reveals itself that way rather than in the traffic.
• Prefer 995 over cleartext 110, and firewall it. Standardise clients on POP3S, retire plaintext 110 where they allow it, and restrict 995 to the networks that genuinely need it.

Real-World Example

Microsoft’s identity-security telemetry has repeatedly shown that legacy authentication protocols — POP3, IMAP, and SMTP AUTH — are the engine behind the overwhelming majority of account-takeover attacks: more than 99% of password-spray attempts and the bulk of credential-stuffing runs come in over these older protocols, precisely because they can’t present a modern-auth or multi-factor challenge. A third-party client speaking POP3 over 995 authenticates with nothing but a username and password, so the TLS tunnel that protects the mail on the wire also hides an MFA-less spray from network monitoring. That is why Microsoft turned off Basic Authentication for POP3 (and the other legacy protocols) in Exchange Online in October 2022, and why enabling MFA is cited as making an account more than 99% less likely to be compromised. The lesson for an exposed port 995 is the same one the CVEs teach: the fix is not more encryption — the transport is already encrypted — but disabling legacy/basic auth, forcing modern auth with MFA, and rate-limiting logins so the spray has nowhere to hide.

FAQ

What is port 995 used for?

Port 995 is the default port for POP3S — POP3 wrapped in TLS. A mail client connects to it, completes a TLS handshake, and then authenticates and downloads messages from the server with RETR, usually deleting them from the mailbox afterwards. Unlike plain POP3 on port 110, the entire session — login and mail alike — is encrypted from the first byte, which is why 995 is the port modern setups use for secure mail retrieval.

Is port 995 secure?

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

What’s the difference between port 110 and port 995?

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

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

Both are implicit-TLS mail-retrieval ports, but for different protocols. Port 995 is POP3S — POP3, which downloads messages to one device and typically deletes them from the server. Port 993 is IMAPS — IMAP, which keeps mail on the server in folders and syncs it across devices. Most hosts run both; IMAP over 993 is the more common choice today, while POP3 over 995 lingers on legacy clients.

How do I test or secure port 995?

Test it by fingerprinting the daemon (nmap -sV -p 995), grading the TLS layer (nmap --script ssl-cert,ssl-enum-ciphers,ssl-heartbleed -p 995 or testssl.sh <target>:995), pulling capabilities with openssl s_client -connect <target>:995, 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/Courier/Cyrus and OpenSSL, and firewalling 995 to trusted networks.

TL;DR

• Service: POP3S (POP3 over implicit TLS), encrypted email download
• Default port: 995/TCP (cleartext POP3 is 110/TCP)
• Biggest risk: password spraying / credential stuffing that bypass MFA, plus full mailbox download 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 POP3 server and OpenSSL, and prefer 995 over cleartext 110