SMTP Ports Explained: Port 25 vs 587 vs 465 vs 2525 — Complete Configuration Guide

Which SMTP port should you use? For most production applications and email clients, the answer is port 587 — and if that's blocked by a firewall or ISP, port 2525 as a fallback. But the reasoning behind that answer involves 40 years of email protocol history, two competing encryption approaches, and ISP policies that affect millions of email senders. Understanding the why makes diagnosing port-related delivery failures significantly faster, and explains why configurations that worked five years ago sometimes break on newer infrastructure.

The Four SMTP Ports: What Each Does and When to Use It

Port 25 — SMTP Relay (Server-to-Server Only)

Port 25 is the original SMTP port, defined in 1982 and still the universal standard for Mail Transfer Agent (MTA) to MTA communication — the server-to-server relay that carries your email from your outbound mail server to the recipient's mail server.

Current status: Appropriate for MTA-to-MTA relay on dedicated mail server infrastructure. Actively blocked for outbound use by most consumer ISPs and major cloud providers (including AWS, Google Cloud, and Microsoft Azure by default) to prevent abuse for spam.

Who should use it: MTAs (Postfix, PowerMTA, Exim) delivering mail to recipient mail servers in server-to-server relay. Not appropriate for email client submission or application-level email sending.

Security: No authentication required by design — it's meant for anonymous server-to-server relay. This is exactly why ISPs block outbound port 25 from end-user networks. An application sending email directly on port 25 without authentication bypasses all the spam controls that authenticated submission provides.

Port 587 — Mail Submission (The Modern Standard)

Port 587 is the IETF-designated standard for email submission, defined in RFC 6409 (originally RFC 2476 in 1998). It's the port email clients, applications, and scripts should use when submitting email to an outbound mail server or relay.

Current status: The recommended default for all email submission. Supported by virtually all commercial ESPs, managed SMTP relays, and mail server software. ISPs generally allow outbound port 587, unlike port 25.

How it works: Port 587 uses STARTTLS — the connection begins as plaintext and upgrades to TLS encryption when the client sends the STARTTLS command. The SMTP authentication (SMTP AUTH with username/password or OAuth credentials) happens over the encrypted channel, ensuring credentials are never transmitted in cleartext.

The connection sequence on port 587:

Client → Server: TCP connection on port 587
Server → Client: 220 smtp.example.com ESMTP
Client → Server: EHLO client.domain.com
Server → Client: 250-STARTTLS (advertised capability)
Client → Server: STARTTLS
Server → Client: 220 Ready to start TLS
[TLS handshake, all subsequent communication encrypted]
Client → Server: EHLO client.domain.com  (re-issued after TLS)
Client → Server: AUTH LOGIN / PLAIN / XOAUTH2
Server → Client: 235 Authentication successful
Client → Server: MAIL FROM:
[etc.]

Port 465 — Implicit TLS (Legacy but Still Used)

Port 465 has a complicated history that explains why different sources give contradictory advice about it. In 1997, it was assigned by IANA for "SMTPS" (SMTP over SSL). Many mail servers and clients quickly adopted it. Then, in 1998, IANA reassigned the port for a completely different use and deprecated it for email purposes, recommending port 587 with STARTTLS instead. But by that point, too many implementations had already adopted port 465 for it to simply disappear.

In 2018, RFC 8314 formally rehabilitated port 465 by defining "Implicit TLS" as a valid alternative to STARTTLS for email submission. Instead of upgrading from plaintext to TLS (STARTTLS), Implicit TLS establishes TLS immediately at the TCP connection level — there's no plaintext phase.

Current status: Supported by most major ESPs and mail servers. RFC 8314 makes it a valid option. Cloudflare and some security researchers actually argue Implicit TLS is slightly more secure than STARTTLS because it eliminates the brief plaintext negotiation phase. However, port 587 has broader compatibility and remains the stronger default recommendation.

The connection sequence on port 465 (Implicit TLS):

Client → Server: TCP connection on port 465
[TLS handshake immediately — no plaintext]
Client → Server: EHLO client.domain.com  (already encrypted)
Client → Server: AUTH LOGIN / PLAIN / XOAUTH2
Server → Client: 235 Authentication successful
[etc.]

Port 2525 — Non-Standard Fallback

Port 2525 is not an IETF- or IANA-recognized SMTP port. It's an informal convention adopted by many ESPs and managed SMTP services as a workaround for environments where ports 25, 465, and 587 are all blocked (common in some corporate networks and cloud hosting environments like Google Cloud that blocks port 25 by default).

Current status: Supported by most major ESPs (SendGrid, Mailgun, Postmark, etc.) as an alternative to 587. Functions identically to 587 — STARTTLS encryption, SMTP AUTH required. Use it only as a fallback when 587 is blocked.

The Difference Between STARTTLS and Implicit TLS

The STARTTLS vs Implicit TLS question comes up whenever someone compares port 587 (STARTTLS) to port 465 (Implicit TLS). Both ultimately produce an encrypted connection, but the path differs:

# Test if port 587 is open and accepting STARTTLS:
$ nc -zv smtp.provider.com 587
Connection to smtp.provider.com 587 port [tcp/submission] succeeded!

# Initiate STARTTLS manually:
$ openssl s_client -connect smtp.provider.com:587 -starttls smtp
EHLO test
250-smtp.provider.com Hello
250-STARTTLS
250 AUTH PLAIN LOGIN
STARTTLS
220 2.0.0 Ready to start TLS
# TLS handshake begins — verify Protocol: TLSv1.2 or TLSv1.3 in output

The downgrade attack concern with STARTTLS is largely theoretical in practice. A man-in-the-middle attacker who can intercept your SMTP connection could strip the STARTTLS capability advertisement from the server's EHLO response, causing the client to send email in plaintext. Modern SMTP client implementations typically refuse to authenticate over unencrypted connections even when STARTTLS isn't available, mitigating this risk. But Implicit TLS (port 465) eliminates the concern entirely by never having a plaintext phase.

SMTP Port Selection for Specific Use Cases

Application Code Sending Email (Python, Node.js, PHP, etc.)

Default to port 587 with STARTTLS. Most programming language SMTP libraries default to port 587 when STARTTLS is configured. If port 587 is blocked in your deployment environment (common on Google Cloud and some corporate networks), use 2525. Code example for context — always use SMTP AUTH over TLS, never plaintext port 25 from application code.

Email Client Configuration (Outlook, Apple Mail, Thunderbird)

Use port 587 (STARTTLS) or port 465 (SSL/TLS, which means Implicit TLS). Never configure an email client to use port 25 for outbound mail — clients using port 25 are typically being treated as relays rather than authenticated submitters, which affects deliverability and may be rejected by your ISP.

MTA-to-MTA Relay (Postfix, PowerMTA Delivering to Recipient Servers)

Port 25 is correct for server-to-server relay. Your MTA connects to the recipient server's port 25 to deliver incoming mail. This is the fundamental MTA function and port 25 is the correct port for it. Your MTA should use TLS opportunistically (STARTTLS when offered) or mandatorily (MTA-STS enforcement if configured) for this relay connection.

Internal Application Server to Managed SMTP Relay

Port 587 with STARTTLS and SMTP AUTH. This is the canonical pattern: your application server submits authenticated email to a managed relay (your own Postfix relay, a commercial service like Mailgun or Sendgrid) on port 587. The relay handles all external delivery on port 25.

Diagnosing SMTP Port Connection Problems

When email fails to send from an application or script, the first diagnostic question is whether the port connection itself is succeeding. Use telnet or openssl to test directly:

# Test port 587 connection (expect a 220 banner)
telnet smtp.yourmailserver.com 587

# Test port 587 with TLS (test the full STARTTLS handshake)
openssl s_client -starttls smtp -connect smtp.yourmailserver.com:587

# Test port 465 with Implicit TLS
openssl s_client -connect smtp.yourmailserver.com:465

# Test port 25 relay from an MTA server
telnet recipient-domain.com 25

A successful connection on port 587 should return a 220 banner from the server. If the connection times out rather than refusing, the port is likely blocked by a firewall or ISP policy. If it refuses immediately with "connection refused," the service isn't running on that port.

Common port connection problems:

• Port 25 blocked: Cloud hosting (AWS, Google Cloud, Azure) blocks outbound port 25 by default. Solution: use port 587 to a managed relay, or request port 25 unblocking (AWS requires a specific request for this)
• Port 587 blocked by corporate firewall: Some enterprise networks block port 587. Solution: try 2525, or work with network team to allow 587
• TLS certificate errors on port 587/465: The server's TLS certificate hostname must match the server you're connecting to. Check with openssl s_client and look for certificate validity errors
• Authentication failures after TLS handshake: Verify username (typically full email address), password, and authentication mechanism (PLAIN, LOGIN, XOAUTH2 depending on provider)

Port Selection and Email Deliverability

Port selection does not directly affect inbox placement at recipient mail servers. Gmail, Outlook, and Yahoo don't make filtering decisions based on which port your MTA used to connect. What matters is TLS encryption (required by all major ISPs for compliant delivery), authentication compliance (SMTP AUTH on port 587/465), and the authentication records (SPF, DKIM, DMARC) on your sending domain.

The indirect deliverability impact of port selection comes from ISP restriction avoidance. Applications that attempt to send directly on port 25 from consumer ISP networks get blocked, not because of port filtering at the recipient but because the outbound port 25 traffic never reaches the recipient server. Using port 587 to a managed relay ensures the submission reaches your relay, which can then handle port 25 delivery to recipient servers from a properly configured mail server infrastructure.

Last updated: March 30, 2026