SMTP Port 465 Not Working

"SMTP Port 465 Not Working" is not a real SMTP reply code (you won't find a 465 in RFC 5321 or RFC 3463 — those are 3-digit reply codes like 550). It's a symptom: your mail client can't establish a working session on TCP port 465. The connection times out, hangs, or fails during the TLS handshake.

Is SMTP port 465 deprecated?

No. This is the single most common myth about port 465, and the old advice to "use 587 because 465 is deprecated" is wrong. Port 465 was briefly deprecated in the late 1990s, but RFC 8314 (January 2018) formally restored it as the standard port for message submission over implicit TLS, and even recommends that clients and servers implement both STARTTLS on 587 and implicit TLS on 465 (RFC 8314 §3.3, §7.3). In 2026, port 465 is supported by Postfix, Exim, Exchange Online, Gmail, and every major ESP. So the fix is almost never "stop using 465" — it's "connect to 465 correctly."

What causes "SMTP port 465 not working"?

The difference between 465 and 587 is when TLS starts:

• Port 465 — implicit TLS (a.k.a. "SMTPS" / "TLS wrapper"): the TLS handshake happens immediately, before any SMTP command. The whole session is encrypted from the first byte.
• Port 587 — STARTTLS: the session starts in plaintext, then the client issues STARTTLS to upgrade.

Most 465 failures come from one of three causes:

1. Protocol mismatch (the #1 cause). Your client is configured for STARTTLS but pointed at 465 — or vice versa. Sending a plaintext EHLO to port 465 makes the server wait for a TLS handshake that never comes, so the connection hangs or times out. Per Amazon SES's SMTP documentation, 465 expects a TLS wrapper (connect over TLS immediately), while 587 expects STARTTLS (connect plaintext, then upgrade).
2. Firewall / ISP blocking port 465 outbound. Many corporate networks, hosting providers, and ISPs block 465. On AWS EC2, default egress restrictions historically applied to port 25, but security groups or network ACLs can block 465 too.
3. TLS handshake failure — outdated TLS version, certificate validation error, or a forced cipher the server rejects.

How do I fix SMTP port 465 not working?

Step 1 — Confirm the port is reachable. Use openssl (not plain telnet, since 465 is encrypted from the start):

openssl s_client -connect smtp.yourprovider.com:465 -crlf

If you get a TLS handshake and a 220 greeting, the port is open. If it hangs or refuses, the port is blocked — go to Step 3.

Step 2 — Use implicit TLS, not STARTTLS. Configure your client for TLS-on-connect. In Nodemailer, secure: true is required for 465 (and false for 587):

// Port 465 — implicit TLS
const transporter = nodemailer.createTransport({
  host: "smtp.yourprovider.com",
  port: 465,
  secure: true, // TLS from the first byte — REQUIRED for 465
  auth: { user: "apikey", pass: process.env.SMTP_PASSWORD },
});

In Python's smtplib, use SMTP_SSL (not SMTP + starttls()):

import smtplib, ssl
server = smtplib.SMTP_SSL("smtp.yourprovider.com", 465, context=ssl.create_default_context())
server.login(user, password)

Step 3 — If the port is genuinely blocked, fall back to 587. Port 587 with STARTTLS is the most universally unblocked submission port. If 587 is also blocked, some providers offer alternate ports as unofficial or documented fallbacks — for example, Amazon SES supports 2587 (STARTTLS) and 2465 (TLS wrapper). Per RFC 8314 these are security-equivalent when TLS is correctly required — so this is a connectivity workaround, not a downgrade.

Step 4 — If you authenticate against Gmail/Google Workspace, note that Google has been phasing out password-only "less secure app" access: consumer Gmail accounts lost this option in 2022, while Google Workspace (business) accounts follow a separate, later cutoff. Use an App Password (requires 2-Step Verification) or OAuth2 — a bad password on 465 surfaces as an auth failure after a successful TLS connect, which is a different problem from the port "not working."