Port 465: SMTPS — The Prodigal Port of Email Submission

Port 465 is where your email enters the encrypted tunnel. When you compose a message and hit send, your mail client opens a connection to port 465, and from the very first packet, everything is encrypted. No negotiation. No "please turn on security now." Just immediate, implicit TLS from hello to goodbye.

This is SMTPS: SMTP over TLS, the way email submission was always supposed to work.

How SMTPS Works

When your email client connects to port 465, the TLS handshake begins immediately. Before a single SMTP command is exchanged, before your username or password crosses the wire, the connection is encrypted. This is called "implicit TLS" because the encryption is implicit in the connection itself.¹

Compare this to STARTTLS on port 587, where the client first connects in plaintext, says hello, then asks "Can we switch to TLS now?" If someone is intercepting traffic, they can simply strip out that request and force the connection to remain unencrypted. With port 465, there is no plaintext phase to attack.

The protocol itself is identical to regular SMTP. Once the TLS tunnel is established, the client authenticates with AUTH LOGIN or AUTH PLAIN, then submits the message with MAIL FROM, RCPT TO, and DATA commands. The encryption is the transport layer. The conversation inside is the same conversation that has been happening since 1982.

The Strange History of Port 465

Port 465 has one of the strangest histories of any well-known port.

In 1997, Netscape and other early email clients needed a secure way to submit email. SSL existed. Port 25 was plaintext. The obvious solution: create a new port that speaks SSL from the start. IANA registered port 465 for SMTPS, and mail clients began using it.²

Then, in January 1999, Paul Hoffman of the Internet Mail Consortium published RFC 2487, introducing STARTTLS. The idea was elegant: instead of dedicating separate ports for secure and insecure versions of every protocol, let the client upgrade an existing connection to TLS on demand. One port could handle both encrypted and unencrypted traffic.³

The IETF decided STARTTLS was the future. By the end of 1998, IANA had revoked the registration of port 465. The port was later reassigned to Cisco's URD (URL Rendezvous Directory) protocol for source-specific multicast.⁴

Port 465, officially, was dead.

Except it wasn't.

Twenty Years of Beautiful Illegitimacy

Here's what actually happened: nobody stopped using port 465.

Mail clients had been built to use it. Mail servers supported it. Users had configured it. The deprecation was a piece of paper. The reality was millions of email connections every day, flowing through a port that officially didn't exist for email anymore.

For twenty years, port 465 lived in a strange limbo. Every guide said "use port 587 with STARTTLS." Every mail server still listened on 465. System administrators included it in their firewall rules. Email providers documented it in their setup instructions.

The port that wasn't supposed to exist for email was carrying email anyway.

The Resurrection: RFC 8314

In January 2018, Keith Moore and Chris Newman published RFC 8314, titled "Cleartext Considered Obsolete."¹ The document made a sweeping declaration: plaintext email submission should end. All email connections should use TLS.

But the RFC did something else. It finally acknowledged reality.

The document notes that port 465 "is presently used for submissions by a large number of clients and service providers." It observes that the original SMTPS registration "should have been renamed or reserved rather than revoked."¹

IANA granted a special exception, creating a new service called "submissions" (SMTP submission over implicit TLS) on port 465. For the first time since 1998, the port was officially sanctioned for email.

The prodigal port had come home.

Why Implicit TLS Wins

RFC 8314 doesn't just acknowledge port 465. It recommends it:

"Connections to Mail Submission Servers should be made using Implicit TLS in preference to connecting to the cleartext port and negotiating TLS using STARTTLS."¹

The reasons are security.

STARTTLS is vulnerable to downgrade attacks. A network attacker can intercept the connection during the plaintext negotiation phase and strip out the STARTTLS capability advertisement. The client thinks the server doesn't support encryption. The server thinks the client never asked for it. The email flows in cleartext, readable by anyone watching.⁵

In August 2021, security researchers documented dozens of STARTTLS vulnerabilities across major email clients including Apple Mail, Gmail, Mozilla Thunderbird, and Outlook. They found command injection attacks possible in 15 different implementations. An Internet-wide scan revealed 320,000 mail servers vulnerable to these attacks.⁶

With implicit TLS on port 465, these attacks are impossible. There is no plaintext phase. There is no negotiation to intercept. The connection is either encrypted from the start, or it doesn't happen at all.

The Split: Submission vs. Relay

Understanding port 465 requires understanding the difference between email submission and email relay.

When you send an email, it first goes to your mail provider's submission server. This is the server that accepts mail from authenticated users. It runs on ports 465 (implicit TLS) or 587 (STARTTLS).

That server then relays your message to the recipient's mail server using port 25. This is the relay function, the original purpose of SMTP. Port 25 handles server-to-server communication, not user submission.

RFC 2476, published in December 1998 by R. Gellens of QUALCOMM and J. Klensin, formalized this split. It established port 587 as the submission port, separating user mail submission from inter-server relay.⁷

Port 465 serves the same submission function as 587, but with implicit TLS instead of STARTTLS.

Security Considerations

Port 465 with implicit TLS is one of the most secure ways to submit email. The encryption starts immediately, and modern implementations require TLS 1.2 or higher.

The key security advantage is resistance to downgrade attacks. STARTTLS on port 587 can be stripped by an active attacker. Implicit TLS on port 465 cannot.

However, port 465 only secures the connection between you and your mail submission server. It does not guarantee end-to-end encryption. Once your message leaves your provider's server, it may traverse multiple relays before reaching the recipient. Each hop may or may not use TLS.

For truly confidential communication, you need application-layer encryption like PGP or S/MIME, not just transport-layer TLS.

Related Ports