Port 465 – SMTPS (Simple Mail Transfer Protocol Secure)

Port 465 is the default port for SMTPS — SMTP message submission over implicit TLS, where the socket is encrypted from the very first byte, before a single SMTP command is exchanged. A mail client (Thunderbird, Apple Mail, Outlook, or a script sending through Gmail or Microsoft 365) uses it to hand outgoing mail to its provider’s submission server over an already-encrypted channel. That makes 465 the secure member of the mail-sending family: unlike cleartext relay on port 25 or STARTTLS submission on port 587, there is no plaintext phase to sniff or downgrade. The findings that matter on an open port 465 are therefore about how well the TLS is configured and who is allowed to authenticate — not about cleartext credentials on the wire.

Port 465 has an unusually tangled history worth stating precisely, because it drives the top question users ask about it. It was first registered in the late 1990s as “smtps” (SMTP over SSL), that assignment was quickly deprecated and reassigned by IANA to URD (URL Rendezvous Directory), and the industry was told to standardise on 587 with STARTTLS instead — yet 465 never actually went away. In 2018 RFC 8314 formally re-blessed it, assigning the submissions service (Message Submission over implicit TLS) to TCP 465 and recommending implicit TLS in preference to STARTTLS, precisely because STARTTLS is exposed to downgrade attacks. So today the three mail-sending ports divide up cleanly:

Why It’s Open

Port 465 is open on almost anything that accepts outbound mail from clients or applications. Google (Gmail), Microsoft 365, Yahoo, and most ISP and hosting mail platforms all offer it, and it is the port countless apps, cron jobs, and PHPMailer/smtplib scripts are configured to use because implicit TLS is the simplest thing to get right — no STARTTLS negotiation to fumble. On self-managed servers the daemon terminating TLS on 465 is usually Postfix (smtps service in master.cf), Exim, or Sendmail on Linux/UNIX, or whatever a cPanel/Plesk/Zimbra/iRedMail stack bundled. Where 465 answers, its relatives usually do too: check the cleartext/STARTTLS submission siblings on 25 and 587, and the implicit-TLS mailbox-retrieval pair on IMAPS 993 and POP3S 995.

Common Risks

• Weak TLS on the listener. Implicit TLS is only as strong as the TLS it negotiates. A 465 endpoint that still accepts SSLv2/SSLv3 or TLS 1.0/1.1, offers export/anonymous/RC4 ciphers, or reuses an RSA key with an SSLv2-capable service is exposed to interception and decryption (DROWN, POODLE, BEAST-class). And because 465 is a raw TLS endpoint, an OpenSSL memory-disclosure bug like Heartbleed leaks submitted credentials and the server’s private key straight off the socket.
• Certificate problems. Expired, self-signed, or hostname-mismatched certificates train users and clients to click through warnings, which reopens the man-in-the-middle door that implicit TLS was supposed to close. Encryption you can’t authenticate is encryption an active attacker can impersonate.
• Credential brute-force and password spraying over the TLS channel. The tunnel is encrypted, but AUTH LOGIN/AUTH PLAIN behind it is still a login prompt. Most submission servers don’t throttle failed logins, so hydra, medusa, and Metasploit grind username/password lists at will — and legacy SMTP AUTH frequently bypasses MFA, exactly the way legacy IMAP does.
• Open relay and authentication bypass. A submission service that relays mail without valid authentication — or accepts spoofed senders — becomes a spam cannon and a sender-reputation disaster. This is more classically a port 25 MTA problem, but a misconfigured 465 listener can be abused the same way, so it’s worth testing explicitly.
• A full MTA behind the port. The daemon terminating TLS on 465 is a complete mail server — Postfix, Exim, or Sendmail — and its parser and delivery bugs (some remote, some pre-auth) are reachable wherever it accepts a message. The implicit-TLS wrapper doesn’t shrink that attack surface; see the CVEs below.
• Banner and version disclosure. Once the handshake completes, the SMTP greeting and EHLO response usually name the software and version outright (220 mail.example.com ESMTP Postfix), handing you the exact CVE list to check.

One genuine security advantage is worth keeping in mind while you test: because TLS on 465 is implicit, there is no STARTTLS step for an active attacker to strip, so the port 587 STARTTLS-downgrade class of attack simply doesn’t apply here. On 465 the encryption either happens or the connection fails.

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 does the TLS itself)

nmap -sV -p 465 <target>

Run the SMTP and TLS NSE scripts

nmap -p 465 --script=smtp-commands,smtp-open-relay,smtp-enum-users,smtp-ntlm-info,ssl-cert,ssl-enum-ciphers <target>

Check for the classic TLS bugs on the listener

nmap -p 465 --script=ssl-heartbleed,sslv2-drown,ssl-poodle <target>

Open the implicit-TLS session by hand

Port 465 speaks TLS immediately, so connect straight into it — do not use -starttls smtp, which is for the cleartext-then-upgrade ports 25/587:

openssl s_client -connect <target>:465 -crlf
# once inside TLS:
EHLO tester
QUIT

Audit protocols, ciphers, and the certificate

sslscan <target>:465
# or, for a fuller report:
testssl.sh <target>:465

Drive a full authenticated submission with swaks

swaks --server <target>:465 --tls-on-connect \
  --auth LOGIN --auth-user user@target --auth-password 'password' \
  --from user@target --to test@target

--tls-on-connect is what makes swaks speak implicit TLS (SMTPS) rather than STARTTLS.

Brute-force AUTH over SSL with Hydra

hydra -l user@target -P passwords.txt -s 465 -S <target> smtp

The -S flag wraps the connection in SSL and -s 465 points it at the SMTPS port.

Metasploit modules

msfconsole -q
use auxiliary/scanner/smtp/smtp_version
set RHOSTS <target>
set RPORT 465
run

use auxiliary/scanner/smtp/smtp_enum
set RHOSTS <target>
set RPORT 465
run

Record every open port 465, the daemon banner, the negotiated TLS version and cipher, the certificate details, 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. A missing bounds check in the TLS heartbeat handler lets a remote attacker read up to 64 KB of process memory per request, with no authentication. On an SMTPS listener that memory routinely holds submitted usernames and passwords and the server’s private TLS key, which is why this is the cleanest example of a bug that is specifically a port-465 / TLS-transport problem rather than a mail-logic one. CVSS 7.5. Test with nmap’s ssl-heartbleed or Metasploit’s auxiliary/scanner/ssl/openssl_heartbleed; archived on Exploit-DB.
• CVE-2016-0800 (DROWN) — OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g, plus any server still speaking SSLv2. A Bleichenbacher RSA padding oracle that lets an attacker decrypt captured TLS sessions when the same RSA key is exposed on any SSLv2-capable service; mail servers (SMTPS, IMAPS, POP3S) were among the researchers’ demonstrated targets. It’s the concrete reason to hard-disable SSLv2 on 465 and never share certificates with legacy services. CVSS 5.9. Detect with nmap’s sslv2-drown.
• CVE-2019-10149 (“The Return of the WIZard”) — Exim 4.87 through 4.91 (and 4.92 in some configurations). Improper validation of the recipient address in deliver_message() allows command execution as root. CVSS 9.8 and on CISA’s Known Exploited Vulnerabilities list. Port-scope honesty: this is an Exim MTA flaw reachable wherever Exim accepts a message, and most exploitation targets inbound port 25 — but an Exim daemon that also serves submission on 465/587 is the very same vulnerable binary, so a 465 listener fingerprinted as vulnerable Exim is in scope. Public exploit on Exploit-DB 46996; write-up in the Qualys advisory.
• CVE-2020-28017 (one of Qualys’s “21Nails” set of 21 Exim flaws) — Exim before 4.94.2. An integer overflow leading to a heap buffer overflow in receive_add_recipient. CVSS 9.8. Same framing as above: an Exim-binary bug reachable on any listener the MTA runs — 25, 465, or 587 — so patch Exim to 4.94.2+ regardless of which port you found it on. Details in the 21Nails advisory.

Fingerprint the daemon first: a Postfix or Sendmail banner means the two Exim RCEs above don’t apply, and you should pivot to that server’s own advisory list instead of assuming a generic “SMTP” bug hits every mail port.

Mitigation

• Enforce TLS 1.2+ and strong ciphers. Disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1 on the 465 listener, drop export/anonymous/RC4 suites, and prefer forward-secret ciphers. In Postfix that’s smtpd_tls_mandatory_protocols / smtpd_tls_mandatory_ciphers on the smtps service.
• Use a valid, trusted certificate. Deploy a CA-issued cert whose hostname matches, keep it current, and never share its RSA key with an SSLv2-capable service (the DROWN precondition).
• Require authentication after TLS, and disable open relay. Accept mail only from authenticated submitters, reject relay for unauthenticated senders, and verify with smtp-open-relay after any config change.
• Kill legacy basic auth and enforce MFA. Move clients to OAuth2/modern auth so a stolen password alone can’t submit mail — the same fix that closed the legacy-IMAP MFA-bypass path.
• Rate-limit and monitor authentication. Put fail2ban or the daemon’s own limits on repeated AUTH failures, and alert on spikes so brute-force and spraying stall and surface.
• Patch the MTA. Keep Postfix, Exim (≥ 4.94.2), and Sendmail current — the highest-severity mail-server CVEs are in the daemon, not the TLS wrapper.
• Prefer 465 or 587 over cleartext, and firewall the port. Standardise clients on implicit TLS (465) or enforced STARTTLS (587) instead of plaintext submission, and restrict 465 to the networks that genuinely need it.

Real-World Example

Heartbleed (CVE-2014-0160) is the cleanest illustration of why an encrypted port is still worth testing. When the OpenSSL flaw broke in April 2014, the attention went to HTTPS web servers — but every other service that terminated TLS with the same vulnerable OpenSSL was leaking too, including SMTPS on 465, IMAPS on 993, and POP3S on 995. A single crafted heartbeat returned up to 64 KB of the mail daemon’s memory, and because submission servers hold plaintext credentials and the private key in that memory while processing logins, an attacker could quietly harvest usernames, passwords, and the key that authenticates the TLS itself — no login, no log entry, no malformed mail. Mail operators who patched their web tier but forgot the submission and retrieval listeners stayed exposed for weeks. It’s the enduring lesson for port 465: “it’s encrypted” is where the assessment starts, not where it ends — the TLS stack, the certificate, and the MTA behind them all still have to be right.

FAQ

What is port 465 used for?

Port 465 is the default port for SMTPS — SMTP message submission over implicit TLS. A mail client or application connects to it to send outgoing mail to its provider’s submission server, with the whole session encrypted from the first byte. It’s the send-side counterpart to the encrypted mailbox-retrieval ports IMAPS 993 and POP3S 995.

What’s the difference between port 465 and port 587?

Both are client-to-server submission ports, and both end up encrypted — the difference is when. Port 465 uses implicit TLS: the connection is encrypted before any SMTP command is sent. Port 587 starts in cleartext and upgrades to TLS with the STARTTLS command. Because that upgrade is optional, an active attacker can strip it (a downgrade attack), which is why RFC 8314 recommends implicit TLS on 465 as the preferred choice. Port 465 is not the same as port 25, which is server-to-server relay, not client submission.

Is port 465 secure?

More secure than the alternatives, but not automatically safe. Implicit TLS removes the cleartext phase and the STARTTLS downgrade risk, so credentials aren’t sniffable on the wire. What’s left to get wrong is the TLS configuration (weak protocols and ciphers, a bad certificate), the authentication (brute-force with no lockout, legacy auth that bypasses MFA), open-relay misconfiguration, and unpatched bugs in the mail server itself — so an open 465 still deserves a proper review.

Do I still need port 25 if I use port 465?

Yes, but for a different job. Port 465 handles submission from your clients and apps to your server; port 25 handles delivery between mail servers (MX relay). A mail server typically listens on both — 465/587 for authenticated submission and 25 for receiving mail from other servers — so closing 25 would stop it receiving inbound mail even with 465 open.

How do I secure or close port 465?

Enforce TLS 1.2+ with strong ciphers and a valid certificate, require authentication after TLS, disable open relay, kill legacy basic auth in favour of OAuth2/MFA, rate-limit failed logins, and patch the MTA (Postfix/Exim/Sendmail). If nothing legitimately submits mail through the host, stop the smtps service and firewall TCP/465, then rescan with nmap -p 465 <target> to confirm it’s closed.

TL;DR

• Service: SMTPS — SMTP message submission over implicit TLS (RFC 8314 submissions)
• Default port: 465/TCP (vs STARTTLS submission on 587, and server-to-server relay on 25)
• Biggest risk: weak TLS config, certificate problems, unthrottled AUTH brute-force/MFA-bypass, and MTA CVEs — not cleartext sniffing
• Mitigation: enforce TLS 1.2+ and strong ciphers, use a valid cert, require auth after TLS, disable open relay, kill legacy auth, rate-limit logins, patch the MTA