SMTP Port Numbers Explained: 25, 465, 587, 2525

SMTP ports confuse people because they evolved as standards changed and old documentation keeps circulating advice that no longer applies. The simple rule: port 25 is for server-to-server, port 587 and 465 are for client submission with authentication, port 2525 is a fallback. Anything else you read is either historical or incorrect.

This guide covers the four ports you actually need to care about, when to use each, and the common configuration mistakes.

The four SMTP ports that matter

Port	Purpose	Encryption	Authentication
25	Server-to-server (MX-to-MX) relay	Opportunistic STARTTLS	None (or optional)
465	Client submission (SMTPS)	Implicit TLS from start	Required
587	Client submission (RFC 6409)	STARTTLS upgrade	Required
2525	Unofficial fallback	STARTTLS	Required

There are other historical ports (366 for ODMR, 2526 for some proprietary uses), but they don't show up in modern sender setups.

Port 25: server-to-server relay

Port 25 is the original SMTP port from RFC 5321 (and earlier 821/2821). It's the port mail servers use to talk to each other for MX-to-MX delivery.

When mail flows from your SMTP server to a Gmail inbound server, that connection happens on port 25.

Don't use port 25 for client submission. Two reasons:

1. ISPs block outbound port 25 from consumer networks. Comcast, Cox, Verizon, and most others have done this for over a decade to suppress spam from compromised hosts.
2. Cloud providers (AWS, GCP, Azure) block outbound port 25 by default on new accounts. AWS requires submitting a removal request and even then doesn't always grant it.

Port 25 also typically does not require authentication — receivers accept connections from any IP and rely on reputation, authentication checks, and content filtering after. This is appropriate for server-to-server but not for client submission.

Port 587: modern submission (STARTTLS)

Port 587 is the dedicated submission port defined by RFC 6409. It's where clients (mail apps, scripts, your application) submit messages to an SMTP relay for delivery.

How it works:

1. Client connects to server on port 587 in plaintext
2. Client issues STARTTLS command
3. Server upgrades the connection to TLS
4. Client authenticates (usually AUTH PLAIN or AUTH LOGIN)
5. Client sends the message via standard SMTP commands

The plaintext-then-upgrade pattern is the legacy reason port 587 exists separately from port 465. Modern STARTTLS implementations enforce TLS — clients should refuse to send credentials if STARTTLS fails or the server doesn't offer it.

Use port 587 when you want compatibility with the widest range of SMTP libraries and tools. Most ESP submission configs default to it.

Port 465: implicit TLS submission

Port 465 has a strange history. Originally assigned to "SMTPS" (SMTP over SSL) in 1997, IANA deprecated it in 1998 in favor of STARTTLS on port 587. Then RFC 8314 in 2018 formally reinstated 465 for implicit-TLS submission.

How it works:

1. Client connects to server on port 465 with TLS from the first byte
2. Client authenticates after TLS handshake
3. Client sends the message

No STARTTLS dance. The connection is encrypted from the start.

For new code, port 465 is slightly cleaner because there's no plaintext negotiation phase to misconfigure. For interoperability, port 587 has slightly broader library support.

Practitioner note: I've seen more misconfigurations on port 587 than 465 — usually because the STARTTLS upgrade silently fails and the client falls back to plaintext, sending credentials in clear. If your library doesn't enforce STARTTLS, switch to 465 and avoid the whole class of bug.

Port 2525: the unofficial fallback

Port 2525 has no RFC assignment. It became the de facto fallback when ESPs realized their customers' ISPs were sometimes blocking 25, 587, and 465.

SendGrid, Mailgun, Mailjet, SocketLabs, and Elastic Email all support port 2525 as an alternate submission port with the same authentication and TLS behavior as 587 (STARTTLS).

Use 2525 only if:

• You're on a network blocking 25, 587, and 465 (rare but happens)
• You've confirmed your ESP supports it
• Standard ports don't work for non-policy reasons

For most senders, port 2525 is irrelevant. Stick with 587 or 465.

Picking the right port

Scenario	Recommended port
Your application sends through ESP (SendGrid, Mailgun, etc.)	587 or 465
Your application sends through Gmail SMTP relay	587
Your application sends through Microsoft 365 SMTP relay	587
Your own MTA receives mail from the internet	25
Your own MTA accepts client submission	587 or 465
Your client mail app submits to your provider	587 or 465
You're blocked on 587/465 and on a hostile network	2525
Anonymous server-to-server delivery	25

Configuring submission correctly

A correct authenticated submission to port 587 (showing the SMTP dialog):

> EHLO myhost.example.com
< 250-mail.esp.com Hello
< 250-STARTTLS
< 250-AUTH LOGIN PLAIN
< 250 OK

> STARTTLS
< 220 Ready to start TLS

[TLS handshake]

> EHLO myhost.example.com
< 250-mail.esp.com Hello
< 250-AUTH LOGIN PLAIN
< 250 OK

> AUTH PLAIN <base64-encoded-credentials>
< 235 Authentication succeeded

> MAIL FROM:<[email protected]>
< 250 OK

> RCPT TO:<[email protected]>
< 250 OK

> DATA
< 354 End data with <CR><LF>.<CR><LF>

[message]
.

< 250 OK: queued as ABC123
> QUIT

The same flow on port 465 skips the STARTTLS exchange — TLS happens immediately after TCP connect.

Practitioner note: If you're debugging a "connection refused" or "connection timeout" issue, test from the same machine the application runs on. Network policies (firewall, security group, NAT egress) often block specific ports differently than your dev machine. nc -zv smtp.host.com 587 confirms reachability before you start blaming the SMTP library.

Common port-related mistakes

• Using port 25 for client submission. Will fail outbound on most consumer networks and many cloud providers. Always use 587 or 465 for authenticated submission.
• Connecting to 587 without enforcing STARTTLS. If your library is misconfigured, you'll send credentials in plaintext.
• Connecting to 465 with starttls enabled. Port 465 is implicit TLS — don't issue STARTTLS.
• Mixing ports across environments. If staging uses 587 and prod uses 465, you'll catch port-specific bugs in production.
• Hardcoding port numbers. Pull from environment config so you can switch without code changes.

For full SMTP protocol detail, see how does SMTP work. For configuring SMTP across major providers, see SMTP settings reference.

If your application's SMTP submission is failing intermittently and you're not sure if it's port, TLS, auth, or rate limits, book a consultation. SMTP debugging is the bread-and-butter of infrastructure work.

Sources

• RFC 5321: Simple Mail Transfer Protocol
• RFC 6409: Message Submission for Mail
• RFC 8314: Cleartext Considered Obsolete
• IANA Service Name and Transport Protocol Port Number Registry
• SendGrid — SMTP Ports Explained
• Microsoft Learn — Authenticated SMTP Submission Setup

---

v1.0 · May 2026