Port / TCP
465SMTPS (submission)
Implicit-TLS message submission: the client authenticates and hands off outbound mail inside a TLS session established at connect time.
If it is internet-facing: Port 465 is routine where it is expected. Its risk lives in the service configuration behind it, not the port itself.
Exposure
Internet-facing
Transport
Encrypted by default
Risk if public
Low
Exposure verdict
Port 465 is meant to answer from the internet, and it protects the session itself. What remains is authentication strength, patch level, and rate limiting.
The session is protected from the first byte, so there is no plaintext phase for an on-path attacker to strip or read.
Assigned by IANA through a review process. On Unix systems a process needs root or the CAP_NET_BIND_SERVICE capability to bind here, which is why containers so often remap these to a higher port.
Grouped with the other mail ports so a rule written for one can be checked against its neighbours.
What actually goes wrong
1 note- Because TLS starts before the greeting, there is no plaintext phase for a downgrade attack to target.
Recommended firewall rule
Allow it, and harden the service
This port is expected to answer from anywhere, so the firewall is not where its security comes from.
ufw
sudo ufw allow 465/tcpiptables
sudo iptables -A INPUT -p tcp --dport 465 -j ACCEPTCheck what is really there
Listening locally
sudo ss -tlpn 'sport = :465'The bind address is the answer that matters: 127.0.0.1 is local-only, 0.0.0.0 and :: mean every interface.
Listening (macOS)
sudo lsof -nP -iTCP:465 -sTCP:LISTENmacOS ships lsof rather than ss; this names the owning process and user.
From outside
nmap -sV -Pn -p 465 <host>A version probe confirms whether SMTPS (submission) is actually what answers, rather than trusting the number. Only scan hosts you are authorised to test.
Reachability
nc -vz <host> 465The quick yes/no when you only need to know whether a path exists through the firewall.