SMTP error port 465

There is no SMTP reply code "465." Port 465 is a TCP port, not an SMTP status code, so "SMTP error port 465" refers to a connection that fails when a mail client tries to submit mail over port 465 — the implicit TLS submission port (historically called SMTPS or "TLS Wrapper"). The fix is almost never to abandon the port; it's to configure your client correctly, confirm the port is reachable, and fix authentication.

Correction to a common myth: Older guidance (including a previous version of this page) claimed port 465 "will fail" because IANA reassigned it. That is out of date. IANA did revoke the original smtps registration in the late 1990s, but RFC 8314 (2018, §7.3) formally re-registered port 465 for mail submission over implicit TLS and describes it as the preferred long-term direction over STARTTLS on 587 (§1), while §3.3 calls for supporting both ports during the transition period. Major providers support it today: Amazon SES accepts 465 and 2465 as "TLS Wrapper" endpoints, and Gmail documents smtp.gmail.com:465 with SSL. Port 465 is not deprecated.

What causes an "SMTP error" on port 465?

The error is a TCP/TLS-layer failure, surfaced by your mail library, not the server's SMTP dialogue. The usual root causes:

1. The client doesn't speak implicit TLS on 465 (most common). Port 465 expects the TLS handshake immediately on connect — there is no plaintext greeting and no STARTTLS command. If your library opens a cleartext socket (the STARTTLS pattern used on 587) and waits for a 220 banner, the handshake never completes and you get a hang, timeout, or an SSL error like wrong version number.
2. The port is blocked. Many residential ISPs, corporate firewalls, and cloud providers block or drop outbound 465 via their own firewall or security-group rules. (Note: AWS EC2's well-known default outbound throttling applies to port 25, not 465 — a blocked 465 connection on EC2 is a security-group/firewall configuration issue, not a platform-wide restriction.) This presents as Connection timed out / ETIMEDOUT, distinct from a TLS error.
3. Authentication failure after the TLS handshake. The socket connects fine but the server rejects credentials (535 5.7.8). For Gmail/Google Workspace this is usually because you used your normal password — Google removed "Less Secure Apps" access for personal Gmail accounts in 2022, with Workspace accounts moved to a similar requirement on a later 2024–2025 timeline, so you must use an App Password (with 2-Step Verification) or OAuth2.
4. TLS/certificate problems. Hostname/SNI mismatch, an outdated CA bundle, or a self-signed server cert can abort the handshake.

How do I fix an SMTP error on port 465?

Step 1 — Enable TLS-from-connect, not STARTTLS. On 465 the connection must be encrypted from the first byte.

// Nodemailer — port 465 requires secure: true
const transporter = nodemailer.createTransport({
  host: "smtp.example.com",
  port: 465,
  secure: true, // implicit TLS on connect (set false ONLY for 587/STARTTLS)
  auth: { user: "USERNAME", pass: "APP_PASSWORD" },
});

# Python — use SMTP_SSL for 465 (not SMTP + starttls, which is for 587)
import smtplib, ssl
ctx = ssl.create_default_context()
with smtplib.SMTP_SSL("smtp.example.com", 465, context=ctx) as s:
    s.login("USERNAME", "APP_PASSWORD")
    s.send_message(msg)

Step 2 — Prove the port is reachable. Test the TLS handshake directly:

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

A successful run prints the certificate chain and a 220 SMTP banner. If it hangs or times out, the port is blocked — switch networks, open the port in your firewall/security group, or fall back to the STARTTLS submission port 587 (set secure: false in Nodemailer / use SMTP() + starttls() in smtplib). Both 465 and 587 are valid per RFC 8314.

Step 3 — Fix authentication. Use an App Password or OAuth2 for Gmail/Workspace; for SendGrid use apikey as the username and the API key as the password; for SES use your SMTP credentials (not your AWS keys).

Sending through Courier instead. If you'd rather not manage SMTP ports, TLS modes, and provider auth yourself, route email through Courier, which handles provider connections and failover so you don't troubleshoot port 465 directly.