Port 465: Implicit TLS, the Deprecation That Got Reversed, and When to Use It

Port 465 is SMTP submission over implicit TLS — the connection is encrypted from the first byte, before any SMTP command is sent. It was deprecated in 1998 in favour of STARTTLS on port 587, then formally reinstated by RFC 8314 in 2018, which is why you will find documentation confidently telling you both that it is obsolete and that it is preferred. Both statements were true, at different times.

For a new integration either port works with any competent provider. The distinction that matters is not security in theory but what happens when the negotiation goes wrong.

Implicit TLS versus STARTTLS
The port map worth memorising
Testing both from the command line
Configuring it in application code
Common failures and what they mean
Sending mail from an application, more generally
How this fits the rest of the stack
FAQ

Implicit TLS versus STARTTLS

The two ports differ in when encryption starts, not in how strong it is.

Port 465, implicit TLS — the TLS handshake happens first. Nothing is sent in plaintext, ever. If TLS fails, the connection fails and no mail is sent.
Port 587, STARTTLS — the connection opens in plaintext, the client issues STARTTLS, and the connection is upgraded. Credentials are sent after the upgrade.

The practical difference is the failure mode. STARTTLS begins in the clear, so an attacker positioned in the path can strip the STARTTLS advertisement from the server’s response, and a client configured to opportunistically upgrade will silently continue unencrypted — the STARTTLS stripping attack. Implicit TLS has no such window, because there is no plaintext phase to interfere with.

This is why RFC 8314 came back to 465 and recommends it for message submission. A client that is strictly configured to require TLS on 587 is also safe; the point is that 465 is safe by construction rather than by configuration.

The port map worth memorising

25 — server-to-server mail transfer. Almost every residential ISP and most cloud providers block outbound 25 to limit spam. Do not use it for application mail.
465 — submission over implicit TLS. Registered as submissions in RFC 8314.
587 — submission with STARTTLS. The long-standing default and universally supported.
2525 — not a standard. Offered by many providers as a fallback when 587 is blocked by a network.

If your application cannot connect on any of these from a cloud host, the cause is nearly always outbound port blocking rather than anything about your credentials. Providers restrict outbound SMTP by default and often require a support request to open it.

Testing both from the command line

Two different commands, because the connection shapes differ.

# Port 465 -- TLS immediately
openssl s_client -connect smtp.example.com:465 -crlf

# Port 587 -- plaintext, then upgrade
openssl s_client -connect smtp.example.com:587 -starttls smtp -crlf

# Is the port even reachable?
nc -vz smtp.example.com 465
nc -vz smtp.example.com 587

A successful connection prints the certificate chain and then the server’s greeting. If nc hangs rather than refusing, the traffic is being dropped by a firewall — a refusal is a closed port, a hang is a filter.

Once connected, EHLO example.com lists what the server supports. On 587 before STARTTLS you should see 250-STARTTLS in the response; its absence on a server that should offer it is the stripping scenario worth investigating.

Configuring it in application code

Every mail library has the same shape: a flag for implicit TLS and a separate one for STARTTLS. Mixing them up produces a hang or a protocol error rather than a clear message.

// Node, nodemailer
const transport = nodemailer.createTransport({
  host: 'smtp.example.com',
  port: 465,
  secure: true,          // implicit TLS -- must be true for 465
  auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS },
});

// For 587
// port: 587, secure: false   -- STARTTLS is negotiated automatically

import os, smtplib

# Port 465 -- SMTP_SSL, TLS from the start
with smtplib.SMTP_SSL('smtp.example.com', 465) as s:
    s.login(os.environ['SMTP_USER'], os.environ['SMTP_PASS'])
    s.send_message(msg)

# Port 587 -- SMTP, then starttls()
with smtplib.SMTP('smtp.example.com', 587) as s:
    s.starttls()
    s.login(os.environ['SMTP_USER'], os.environ['SMTP_PASS'])
    s.send_message(msg)

secure: false in nodemailer does not mean unencrypted — it means “not implicit TLS”, and STARTTLS still happens. The naming is unfortunate and causes people to set it to true on 587, which hangs.

Common failures and what they mean

Connection hangs, no response — usually implicit TLS against a STARTTLS port or the reverse. The client waits for a handshake the server is not going to start.
Connection refused — nothing listening on that port. Check the port number and hostname.
Connection timed out — a firewall is dropping the traffic. On a cloud host this is very often outbound SMTP blocking.
535 Authentication failed — credentials. On providers with two-factor authentication this usually means you need an app-specific password rather than your account password.
certificate verify failed — a certificate chain problem on the mail server, not something to fix by disabling verification in your mail client.

That last one deserves a note. Turning off certificate verification to make mail send removes the guarantee that you are talking to your mail provider rather than something in the middle — which is precisely what implicit TLS was reinstated to protect.

Sending mail from an application, more generally

Ports and TLS are the easy half. The half that decides whether mail arrives is authentication of the domain: SPF, DKIM, and DMARC records in DNS. A perfectly encrypted message from an unauthenticated domain goes to spam.

The other operational reality is that SMTP is synchronous and mail servers are sometimes slow. Sending mail inline during a web request means a user waits on a third party, and a timeout becomes a failed signup. Push the send into a background worker with a retry, and the request returns immediately.

That worker is a service like any other: it needs somewhere to run, a queue or a table to read from, and logs when a send fails. Deployed as a service with runtime logs and its own environment variables — with the SMTP credentials injected rather than committed — it is a small piece of infrastructure rather than a fragile bit of the web app.

How this fits the rest of the stack

Port 465 is implicit TLS, encrypted from the first byte, formally reinstated by RFC 8314. Port 587 is STARTTLS and equally fine when the client requires the upgrade. Use 465 if your provider offers it, keep 587 as the fallback, and never use 25 from an application. Test with openssl s_client, with -starttls smtp only for 587.

The part that determines delivery is SPF, DKIM, and DMARC, and the part that determines user experience is sending from a background worker rather than inside the request. If you are costing out that worker alongside the rest of the stack, the RunxBuild hosting calculator itemises the service, database, storage, and bandwidth separately.

Useful related references:

FAQ

What is port 465 used for?

SMTP message submission over implicit TLS, meaning the connection is encrypted before any SMTP command is exchanged. It is how an application or mail client hands outgoing mail to a mail server securely, as distinct from port 25, which is for server-to-server transfer.

Is port 465 deprecated?

No, not any more. It was deprecated in 1998 in favour of STARTTLS on 587, but RFC 8314 formally reinstated it in 2018 and registered it as submissions. Documentation calling it obsolete predates that change, which is why you find contradictory advice.

Should I use port 465 or 587?

Either works with a modern provider. 465 is encrypted from the first byte and cannot be downgraded, which makes it safe by construction. 587 is equally safe provided your client is configured to require STARTTLS rather than treat it as optional. Use whichever your provider documents, and keep the other as a fallback.

Why does my SMTP connection hang on port 465?

Almost always because the client is configured for STARTTLS rather than implicit TLS. On 465 the client must begin the TLS handshake immediately — secure: true in nodemailer, SMTP_SSL in Python. Configured for STARTTLS, it waits for a plaintext greeting the server will never send.

Why can’t I connect to any SMTP port from my server?

Most cloud providers block outbound SMTP by default to limit spam, and residential ISPs block port 25 almost universally. A timeout rather than a refusal points at filtering. Check whether your provider requires a request to unblock outbound mail ports, and try 2525 if it is offered.