Port 465/tcp has one of the most tangled histories in the IANA registry, and getting it right is a differentiator versus copycat port sites that still call it "deprecated SMTPS." The port was first registered around 1997 as smtps (SMTP over SSL), then revoked — RFC 8314 notes the original registration "made no sense" because MX-routed SMTP has no way to negotiate a port — and the slot was reassigned to an unrelated multicast service (urd, URL Rendezvous Directory for SSM). In January 2018, RFC 8314 re-designated 465 for "message submission over implicit TLS" under the service name submissions. The result is a genuine dual registration: the live IANA registry today lists both urd and submissions on TCP 465 (and igmpv3lite on UDP 465). For email, 465 is functionally equivalent to the 587 submission port but uses implicit TLS — the TLS handshake begins immediately on connect, before any SMTP exchange — which removes the cleartext negotiation window and saves a round-trip. The MSA must implement SMTP AUTH (RFC 4954) and the requirements of RFC 6409/RFC 5068. Because TLS is established up front, 465 is immune to the STARTTLS-stripping/command-injection attack class that affects 25/587; it remains subject to credential brute-force/password-spray if weak authentication is allowed, and RFC 8314 requires TLS 1.2+ with certificate hostname validation. For an analyst, an open 465/tcp indicates a mail submission agent offering implicit-TLS submission; verify certificate validity and hostname, confirm TLS ≥1.2, and check that AUTH is enforced. The correct present-tense statement is that 465 is an IANA-registered, RFC-endorsed implicit-TLS submission port — not deprecated.

IANA assignment

submissions — "Message Submission over TLS protocol"; reference [RFC8314]; assignee IESG/IETF Chair; registered 2017-12-12. Dual registration: TCP 465 also carries the older urd ("URL Rendezvous Directory for SSM", contact Toerless Eckert, no reference); UDP 465 is igmpv3lite [IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry

Range class

well-known (0–1023)

Primary use

SMTP message submission over implicit TLS (handshake on connect, then authenticated RFC 6409 submission) [Well-established] — RFC 8314, RFC 6409

Other/unofficial uses

legacy "SMTPS" (no-auth) treatment is an anti-pattern; the co-registered urd multicast-directory service [Community-reported/IANA-assigned] — RFC 8314

Prevalence

nmap-services open-frequency 0.013888 (listed under the legacy name "smtps") [Well-established] — nmap-services file

Security implications

implicit TLS eliminates STARTTLS stripping/injection; still subject to credential brute-force/password-spray; RFC 8314 mandates TLS 1.2+ and certificate hostname validation [Well-established/Threat-reported] — RFC 8314, Microsoft Exchange team

Typically seen on

provider/host mail submission agents (Gmail/Google Workspace, Microsoft 365, Fastmail all support it)

Related ports

587 (submission + STARTTLS), 25 (relay); parallels 993/995 as the implicit-TLS variant

Analyst note

Open 465/tcp indicates a mail submission agent offering implicit-TLS submission. Confirm certificate validity/hostname, require TLS 1.2+, and verify AUTH is enforced.