Port 465 SMTPS – Free, Online, Private

What listens on 465

Port 465 is TLS-wrapped SMTP submission. The IANA service name that matches current mail practice is submissions, Message Submission over TLS, RFC 8314. The same number still has a urd row, URL Rendezvous Directory, from an earlier assignment. Historically 465 was SMTPS, then it was unassigned, then it came back as submissions. A client that says 'SSL' on 465 speaks TLS from the first byte. There is no STARTTLS command, because the handshake already happened. Port 587 is submission with a cleartext greeting and STARTTLS. Both are for authenticated users. Neither is a replacement for port 25 between mail servers.

The IANA service name is submissions: Message Submission over TLS. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 465. 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 465

Service notes for port 465: the IANA name is submissions (Message Submission over TLS), and the program people mean is SMTPS. TCP 465 is IANA submissions, message submission over TLS, from RFC 8314. The registry also still lists urd on 465. Mail clients know it as implicit TLS SMTP. Require authentication. A submissions listener that relays without a login is an open relay that happens to use TLS. The certificate has to match the name the client dials, or the client will refuse to send the password. Do not offer 465 on a host that is not your mail submission service. Scanners will find it and try well-known passwords. Implicit TLS does not make a weak password strong. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 465, you are on the wrong page.

A client set to STARTTLS on 465 waits for a 220 banner and instead sees a TLS record. Switch the client to implicit TLS, or move it to 587. The other direction, implicit TLS pointed at 587, fails the same way. A firewall that opened 587 and not 465 breaks the clients you told to use SSL. Another trap is a hosting panel that enabled 465 and left the relay open to authenticated users with the default 'password' account.

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 465 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 465 should be the mail daemon, and the first bytes should be TLS, not an SMTP banner. openssl s_client -connect host:465 shows the certificate. nc -vz only shows the handshake. A 220 banner in cleartext means you reached a different configuration than submissions.

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.

• 465 is not port 25. MX delivery stays on 25. 465 is authenticated submission.
• The registry lists both submissions and urd. For mail, submissions is the relevant name.
• STARTTLS belongs on 587. Implicit TLS belongs on 465.
• UDP is not how you submit mail.

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

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

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

Remotenc -vz host 465