SMTP Ports Explained: 25, 465, 587 and 2525 — Which One Should You Use?

The one-line answer

Use port 587 with STARTTLS for sending mail from an application. Use 465 with implicit TLS if your library handles it more cleanly. Use 2525 only when a firewall blocks the first two. Never use port 25 for application mail.

If that solves your problem, stop reading and go test the connection. If you want to understand *why* — and to diagnose the cases where the simple answer does not work — read on.

Two different jobs, two different ports

The confusion around SMTP ports comes from a single historical fact: the same protocol does two completely different jobs.

Relay is server-to-server transfer. Your provider's outbound server connects to Gmail's inbound server and hands over a message. This is unauthenticated — Gmail has no account for your server — and it happens on port 25.

Submission is client-to-server. Your application connects to your own provider and asks it to send a message on your behalf. This *must* be authenticated, and it happens on port 587 (or 465).

Mixing these up causes most of the "why is my mail not sending" confusion in the world. When your application talks to smtp.gmail.com, you are doing submission, not relay. Port 25 is the wrong door.

Port 25 — relay only

Port 25 was the original SMTP port, defined in 1982 when the internet was a trusted network of academic institutions. Any host could connect to any other and hand over mail with no authentication at all.

Spammers noticed. By the late 1990s open relays on port 25 were the primary vector for unsolicited email, and the industry responded by locking it down.

Today:

• AWS, Google Cloud, Azure, DigitalOcean and Oracle Cloud block outbound port 25 by default. AWS will lift the restriction on request with a justification; others rarely do.
• Most residential ISPs block it entirely to stop infected machines becoming spam relays.
• Corporate firewalls commonly block it too.

Use port 25 only if you operate your own mail server that must accept inbound mail from the internet, or if you run a relay inside a network you control.

Diagnostic tell: if your connection to port 25 hangs and eventually times out with no reply at all, that is a firewall silently dropping packets. A server that is genuinely refusing would answer immediately.

Port 587 — the modern default

RFC 6409 designated port 587 as the message submission port. It exists precisely to separate authenticated client submission from server relay, so networks can block 25 without breaking legitimate senders.

The session flow:

1. Connect on 587 (plaintext)
2. EHLO -> server advertises STARTTLS
3. STARTTLS -> negotiate TLS
4. EHLO again -> server now advertises AUTH
5. AUTH -> authenticate over the encrypted channel
6. MAIL FROM / RCPT TO / DATA

Step 4 is the one hand-rolled clients skip. After a TLS upgrade you must re-issue EHLO, because the capability list from before the upgrade is no longer valid. Skip it and you will never see the AUTH capability, silently omit authentication, and get a confusing 530 later.

Use 587 when: you are writing new code, using a mainstream library, or following any provider's default documentation. It is the most broadly supported option and works everywhere.

Port 465 — implicit TLS

Port 465 has an unusual history. It was assigned for SMTPS in the 1990s, deprecated in 1998 in favour of STARTTLS, then formally reinstated by RFC 8314 in 2018 as the preferred submission port for implicit TLS.

The difference is simple: on 465 the TLS handshake happens before any SMTP command is exchanged. There is no plaintext phase at all.

1. Connect on 465
2. TLS handshake immediately
3. Server greeting (already encrypted)
4. EHLO -> AUTH advertised
5. AUTH, then send

Advantages: no downgrade attack surface, simpler to reason about, and one fewer round trip. Disadvantages: slightly less universal support in very old libraries, and a small number of corporate proxies handle it poorly.

Use 465 when: your provider documents it as preferred (Zoho, Fastmail, Apple), your library supports it cleanly, or your security policy requires encryption from the first byte.

Port 2525 — the unofficial fallback

Port 2525 is not defined in any RFC and is not registered with IANA for SMTP. It is a de facto convention that most transactional providers — SendGrid, Mailgun, Brevo, Mailjet — support as an alternative.

Its only purpose is to get around firewalls. Some hosting providers block 587 and 465 as well as 25, and 2525 is usually left open because it is not a standard mail port.

Functionally it behaves exactly like 587: plaintext connect, STARTTLS upgrade, then authenticate. Support is per-provider, so check before you rely on it, and treat it as a workaround rather than a design choice.

STARTTLS versus implicit TLS

The historical criticism of STARTTLS was the stripping attack: an attacker in the network path removes the STARTTLS capability from the EHLO response, and a permissive client silently falls back to plaintext. This is a real attack, and it is why every client must be configured to *require* TLS and abort if the upgrade fails.

Configured correctly, both options are equally secure. Configured with "opportunistic TLS", STARTTLS is not.

Certificate validation is part of the port decision

Whichever port you use, verify the certificate. The single most common insecure pattern in email code is disabling verification to make a test pass:

// Never ship this
tls: { rejectUnauthorized: false }

It converts an encrypted connection into one any network operator can transparently intercept. When validation genuinely fails, fix the cause: update the CA bundle, connect by hostname rather than IP, or renew the expired certificate on your own server.

Diagnosing port problems

Symptom: connection times out with no response. A firewall is dropping packets. Check cloud security groups, VPC egress rules, and your host provider's outbound policy. Test whether a different port succeeds — if 465 works and 587 does not, it is definitively a firewall.

Symptom: connection refused immediately. Nothing is listening on that port, or the host actively rejects it. Verify the hostname and port against the provider's documentation.

Symptom: connects, then hangs after STARTTLS. A TLS negotiation mismatch — often a protocol version floor or a middlebox interfering. Try implicit TLS on 465.

Symptom: certificate error. Hostname mismatch (you connected to an IP), an expired certificate, or a missing intermediate in the chain.

Symptom: works locally, fails in production. Almost always egress filtering in the production network. Your laptop and your container have very different firewall rules — always test from the environment that will actually send.

Provider port reference

Gmail            smtp.gmail.com               587 STARTTLS  /  465 SSL
Microsoft 365    smtp.office365.com           587 STARTTLS
Outlook.com      smtp-mail.outlook.com        587 STARTTLS
Yahoo            smtp.mail.yahoo.com          587 STARTTLS  /  465 SSL
Zoho             smtp.zoho.com                465 SSL      /  587 STARTTLS
Fastmail         smtp.fastmail.com            465 SSL
SendGrid         smtp.sendgrid.net            587 / 465 / 2525
Mailgun          smtp.mailgun.org             587 / 465 / 2525
Postmark         smtp.postmarkapp.com         587 / 2525
Amazon SES       email-smtp.<region>...       587 / 465 / 2465 / 2587
Brevo            smtp-relay.brevo.com         587 / 2525

Choosing in practice

1. Start with 587 + STARTTLS required + certificate verification on.
2. If your library or provider prefers it, use 465 + implicit TLS.
3. If both are firewalled and you cannot change the network, try 2525.
4. Use 25 only for server-to-server relay inside infrastructure you own.

Then verify it. Run the exact host, port and encryption mode through SMTPTester from the same network your application uses — a 30-second check that proves the port is reachable, TLS negotiates, and your credentials are accepted before anything reaches production.

What happens on the wire, port by port

It helps to see the difference concretely.

Port 587 session:

C: (TCP connect)
S: 220 smtp.example.com ESMTP
C: EHLO app.example.org
S: 250-STARTTLS ...
C: STARTTLS
S: 220 Ready to start TLS
   (TLS handshake)
C: EHLO app.example.org        <- required again
S: 250-AUTH LOGIN PLAIN ...
C: AUTH LOGIN ...

Port 465 session:

C: (TCP connect)
   (TLS handshake immediately)
S: 220 smtp.example.com ESMTP
C: EHLO app.example.org
S: 250-AUTH LOGIN PLAIN ...
C: AUTH LOGIN ...

The 465 flow is two steps shorter and has no plaintext phase at all. That is the entire practical difference.

Ports in containers and serverless environments

Modern deployment targets add their own constraints, and they are the most common cause of "it works locally" failures.

Docker and Kubernetes do not block ports themselves, but the underlying host and cloud network usually do. A pod that cannot reach port 587 is almost always blocked by a security group or network policy, not by the container runtime.

AWS Lambda allows outbound TCP inside a VPC with a NAT gateway, but a function with no VPC configuration uses AWS-managed networking where port 25 is blocked. Ports 587 and 465 generally work.

Cloudflare Workers, Vercel Edge and Deno Deploy do not support raw TCP sockets at all. No SMTP library will work there, regardless of port. Your only option is an HTTP API, or routing the send through a separate service that does have TCP access.

Google Cloud Run and App Engine block port 25 permanently with no exception process. Use 587 or 465.

If you are building on an edge runtime, decide the transport before you design the feature. Discovering that SMTP is impossible after you have written the sending code is an avoidable rewrite.

Testing each port safely

A quick manual check for each option:

# reachability only
nc -vz smtp.example.com 587

# full STARTTLS handshake and certificate check
openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf

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

Look for Verify return code: 0 (ok) in the openssl output. Anything else is a certificate problem to fix at the source.

Run these from the environment that will actually send. A laptop test proves only that your laptop's network allows the connection.

Frequently asked questions

Is 465 deprecated? No. It was deprecated in 1998 and formally reinstated by RFC 8314 in 2018. Both 587 and 465 are current standards.

Is one more secure than the other? Correctly configured, no. Incorrectly configured, 587 is riskier because opportunistic STARTTLS can silently downgrade.

Can I use port 25 for submission if I control both ends? Yes, inside a network you own. Not across the public internet.

Why does my host block 587? Some budget hosts block all mail ports to prevent abuse from compromised accounts. Ask support, and use 2525 if they offer no alternative.

Should I open port 25 inbound? Only if you are running a mail server that must receive mail from the internet. Otherwise leave it closed.