SMTP Port 25 vs 587: 2026 Submission, Relay, TLS, and Decision Framework

SMTP ports 25 and 587 serve fundamentally different roles in the email transport pipeline. Port 25 is the original SMTP port, dating to 1982, used for server-to-server message relay. Port 587 is the modern submission port, designated by RFC 6409 (2011), used for authenticated client-to-server message submission. The distinction matters because the operational realities of the two ports differ substantially in 2026: port 25 is universally blocked for outbound traffic from ISPs and cloud providers due to spam abuse history, while port 587 with STARTTLS authentication is the standard for any client or application submitting email to a mail server.

This comparison covers the practical reality of SMTP ports in 2026: the submission versus relay distinction that produces the different port roles, the universal ISP and cloud provider blocking of outbound port 25, port 587's role as the dominant submission port, the RFC 8314 (2018) revival of port 465 with implicit TLS as an alternative to STARTTLS, port 2525 as informal fallback when standard ports are blocked, the STARTTLS-versus-implicit-TLS security trade-off that determines which port to choose, and the configuration patterns appropriate for each use case from application development to mail server deployment.

Submission versus relay: the fundamental split

Two different jobs. Two different ports. Different security models entirely.

The SMTP protocol covers two distinct operations that have historically used different ports for good architectural reasons.

Message submission. An email client (or application) sends an outgoing message to a mail server for processing and onward delivery. The client authenticates to prove it has the right to use the mail server, and the mail server takes responsibility for the message after submission. The submission step is client-to-server traffic that must be authenticated and encrypted because credentials are involved.

Message relay. A mail server transfers a message to another mail server (typically the recipient's mail server for final delivery). Relay traffic is server-to-server; no authentication is required because mail servers establish trust through their published MX records, IP reputation, and authentication protocols (SPF, DKIM, DMARC). The relay step does not involve user credentials.

The original SMTP design used port 25 for both submission and relay, with no distinction between the two operations. This produced the open-relay problem: a mail server accepting unauthenticated traffic on port 25 could be abused by spammers to relay arbitrary mail. The fix, introduced through RFC 6409 (originally RFC 2476 in 1998), separated submission to a dedicated port (587) where authentication is required, while keeping port 25 for inter-server relay where authentication is unnecessary.

The architectural improvement matters because the separation allows different security policies for the two operations. Port 25 traffic can be relatively permissive (mail servers accepting mail from anywhere for processing) while port 587 traffic is strictly authenticated (only known users with valid credentials). The separation also makes blocking decisions easier: ISPs can block outbound port 25 from end-user networks without affecting authenticated submission on port 587.

Port 25 in 2026

Port 25's role in 2026 is limited to server-to-server SMTP relay. Mail servers connect to each other on port 25 to deliver messages from sending mail server to recipient mail server. Authentication is not required for port 25 traffic; instead, mail servers establish trust through DNS records (MX, A, AAAA, PTR), authentication protocols (SPF, DKIM, DMARC), and IP reputation.

The port 25 connection flow for normal email delivery:

1. Sending mail server looks up MX records for the recipient domain (e.g., gmail.com → gmail-smtp-in.l.google.com).
2. Sending mail server resolves the MX hostname to an IP address via A or AAAA records.
3. Sending mail server initiates TCP connection to that IP on port 25.
4. SMTP conversation: EHLO, MAIL FROM, RCPT TO, DATA, message body, QUIT.
5. STARTTLS upgrade often happens after EHLO when both servers support TLS (which essentially all modern servers do).
6. Receiving server validates the sender through SPF/DKIM/DMARC checks, applies receiver-side reputation filtering, and delivers or rejects.

Several characteristics of port 25 in 2026:

Outbound port 25 is widely blocked. Most ISPs block outbound port 25 from residential connections, and most cloud providers (AWS EC2, Google Cloud, Azure, DigitalOcean, Vultr) block outbound port 25 from cloud VMs by default. Outbound blocking is the primary anti-spam control: a compromised home computer or cloud VM with port 25 access could send spam directly to recipients, bypassing the user's normal mail server entirely. Blocking forces all outbound mail through authenticated submission paths.

Exemptions are available but not guaranteed. Cloud providers offer formal port 25 exemption request processes; ISPs sometimes do for business accounts. The request typically requires justification, use case description, and expected volume. Approval is at the provider's discretion and often denied for new accounts or unclear use cases.

Inbound port 25 must remain open for receiving mail. Mail servers accepting inbound mail must listen on port 25. The inbound side is universally allowed by ISPs and cloud providers; only outbound is restricted.

TLS on port 25 is opportunistic. Server-to-server mail traffic on port 25 uses opportunistic STARTTLS: the connection starts plain text, attempts to upgrade to TLS, and continues with TLS if successful or plain text if not. This is less secure than enforced TLS (used on submission ports) but is required for backward compatibility with the many legacy mail servers that do not support TLS.

Should never be used for client submission. Modern email clients, applications, and any non-mail-server software should never submit mail on port 25. The lack of authentication makes it inappropriate for client use; the blocking situation makes it operationally unreliable; the security model differs from what submission needs.

Port 587 in 2026

Port 587 is the standard submission port designated by RFC 6409. Email clients, applications, mail servers, and any other system submitting outgoing mail to a mail server uses port 587 by default in 2026.

The port 587 connection flow:

1. Client establishes TCP connection to mail server on port 587.
2. Server responds with greeting banner (e.g., "220 mail.example.com ESMTP Postfix").
3. Client sends EHLO command identifying itself.
4. Server responds with supported extensions list including STARTTLS.
5. Client sends STARTTLS command to upgrade the connection to TLS.
6. TLS handshake completes; subsequent traffic is encrypted.
7. Client sends AUTH command with credentials (typically PLAIN or LOGIN over TLS, sometimes CRAM-MD5).
8. Server validates credentials and authorises the session.
9. Client sends MAIL FROM, RCPT TO, DATA, message body, QUIT.
10. Server queues the message for processing and onward delivery.

Characteristics of port 587 in 2026:

Universally supported. Every major mail server (Postfix, Exim, Sendmail, Exchange, all ESP relays) supports port 587 submission. Almost every SMTP library (Nodemailer, Python smtplib, PHPMailer, Java JavaMail, .NET SmtpClient, etc.) defaults to port 587 for outgoing submission.

STARTTLS enforced or required. Modern port 587 deployments require successful STARTTLS upgrade; the server refuses to accept authentication credentials over plain text. Clients should configure their SMTP libraries to require TLS rather than merely prefer it, to avoid the silent downgrade attack surface described below.

Authentication required. The SMTP server requires AUTH before accepting any message submission. Anonymous submission is not permitted on port 587. Authentication typically uses username/password (PLAIN or LOGIN mechanism) over the TLS-protected channel.

ISP and cloud-friendly. Unlike port 25, port 587 outbound is universally allowed by ISPs and cloud providers. The authenticated nature of the traffic makes it inherently less vulnerable to spam abuse than port 25, so blocking is unnecessary.

Default for ESP relays. Mailgun, SendGrid, Postmark, Amazon SES, Brevo, and every other ESP relay endpoint defaults to port 587 for their SMTP submission interfaces. Applications submitting through an ESP use the ESP's port 587 endpoint with the ESP-provided credentials.

Port 465 and the implicit TLS revival

Port 465 has an unusual history. It was originally assigned to SMTPS (SMTP over SSL) in the late 1990s, then deregistered by IANA when port 587 was designated for submission. For nearly two decades port 465 had no official IANA assignment but continued to be supported by many mail systems as a legacy port.

RFC 8314 (2018) officially revived port 465 for SMTP submission with implicit TLS. The standard recognised that implicit TLS has security advantages over STARTTLS and codified port 465 as the recommended port for implicit-TLS submission. In 2026, port 465 is mainstream again and supported by every major mail server, ESP, and SMTP library.

The port 465 connection flow:

1. Client establishes TCP connection to mail server on port 465.
2. TLS handshake begins immediately, before any SMTP conversation. The mail server presents its TLS certificate; the client validates it.
3. Once TLS is established, the SMTP conversation begins inside the encrypted channel: EHLO, AUTH, MAIL FROM, RCPT TO, DATA, etc.
4. All subsequent traffic is encrypted from the connection's first byte; there is no plain-text phase.

The implicit TLS approach has security advantages over STARTTLS:

No STRIPTLS downgrade risk. The STRIPTLS attack against STARTTLS deployments involves a man-in-the-middle stripping the STARTTLS command from the EHLO response, preventing the connection from upgrading to TLS. If the client's SMTP library is misconfigured to allow plain-text fallback, credentials and message data flow unencrypted. Implicit TLS on port 465 eliminates this attack surface because TLS is mandatory from byte one.

Cleaner compliance scanning. Implicit TLS makes it easier for compliance teams to verify that all traffic on port 465 is encrypted. The traffic pattern is unambiguous: encrypted from start. STARTTLS traffic on port 587 has a brief plain-text phase that compliance scanning must handle correctly.

Marginal performance improvement. Implicit TLS removes one round-trip from the connection establishment (the STARTTLS exchange). For high-throughput systems opening thousands of connections per minute, the saved round-trip can produce measurable performance improvements.

Despite these advantages, port 587 remains more widely used in 2026 because of universal library and tooling support. Port 465 is the recommended choice when implicit TLS specifically matters (compliance, performance, library quirks) but not the universal default the way port 587 is.

Port 2525 as fallback

Port 2525 is an unofficial SMTP submission port not standardised by IETF or registered with IANA. Despite the lack of formal standardisation, the port is widely supported by ESPs and SMTP services as a fallback option when ports 587 and 465 are blocked.

The reason for port 2525's adoption: corporate firewalls and some restrictive networks block outbound traffic on standard ports (25, 465, 587) as part of broader port-restriction policies, but typically allow outbound traffic on non-standard high-number ports. Port 2525 provides a path through these restrictions while functioning identically to port 587 from a protocol standpoint.

Characteristics of port 2525:

• Mirrors port 587 functionality. Same STARTTLS upgrade pattern, same authentication requirements, same SMTP conversation flow. The only difference is the port number.
• Not universally supported. Some mail servers and ESPs offer port 2525; others do not. Mailgun, SendGrid, and most major ESPs do; smaller services may not. Self-hosted mail servers typically require explicit configuration to listen on port 2525.
• TLS encryption supported. Port 2525 supports STARTTLS exactly like port 587. Encryption is not compromised by the non-standard port.
• Should not be the primary choice. Use port 2525 as fallback when 587 and 465 are blocked. The lack of formal standardisation means support is not guaranteed across all SMTP libraries and infrastructure.

In 2026, port 2525 is a useful tool for specific network environments but not the default. Programmes choosing port 2525 as the primary submission port without trying 587 first are typically over-engineering for a network restriction that does not apply to their actual environment.

STARTTLS versus implicit TLS

The choice between STARTTLS (port 587) and implicit TLS (port 465) is the most significant technical decision when configuring SMTP submission. The two approaches have different security characteristics that produce different operational outcomes.

STARTTLS mechanics:

1. Client connects to server on port 587 over plain TCP. No encryption yet.
2. Server sends greeting banner in plain text.
3. Client sends EHLO command in plain text.
4. Server responds with capabilities list including STARTTLS support.
5. Client sends STARTTLS command.
6. Server responds with confirmation.
7. TLS handshake initiates. Connection is now encrypted.
8. All subsequent traffic (including authentication credentials and message data) flows inside the encrypted channel.

The plain-text phase before TLS upgrade is brief but creates the STRIPTLS attack surface. A man-in-the-middle on the network path can:

• Intercept the EHLO response from the server
• Strip the STARTTLS line from the capabilities list before forwarding to the client
• Client never sees STARTTLS as a supported capability
• If the client is configured to use TLS only when offered, it proceeds in plain text
• Authentication credentials and message data flow unencrypted; the attacker captures them

The defence against STRIPTLS is configuring the client to require TLS rather than merely prefer it. Properly configured clients fail the connection if STARTTLS is not offered, rather than fall back to plain text. Modern SMTP libraries default to this behaviour but legacy code may still have the older permissive default.

Implicit TLS mechanics:

1. Client connects to server on port 465 over plain TCP.
2. TLS handshake begins immediately, before any SMTP traffic.
3. Server presents TLS certificate; client validates.
4. Once TLS is established, SMTP conversation begins inside the encrypted channel.
5. All traffic from byte one is encrypted; no plain-text phase exists.

The implicit TLS approach has no STRIPTLS surface because there is no plain-text phase to attack. The connection is encrypted or it is not established at all.

For most modern deployments, both port 587 with STARTTLS (properly configured to require TLS) and port 465 with implicit TLS produce secure outcomes. The choice depends on operational preferences and specific requirements rather than fundamental security differences.

ISP and cloud port 25 blocking

The universal blocking of outbound port 25 by ISPs and cloud providers shapes practical email infrastructure in 2026. Operators encountering port 25 issues almost always need to restructure their architecture rather than try to get the blocking lifted.

Major providers and their port 25 policies:

Provider	Outbound port 25 default	Exemption process
AWS EC2	Blocked	Formal request via Support Center; approval not guaranteed
Google Cloud	Blocked permanently	No exemption process; must use SendGrid relay or equivalent
Microsoft Azure	Blocked permanently	No exemption process; must use SendGrid or Office 365 SMTP relay
DigitalOcean	Blocked by default	Support ticket request; not guaranteed
Vultr	Allowed on most plans	Some restrictions on new accounts
Hetzner	Open by default	No restrictions for dedicated server customers
OVH	Open by default	Generally permissive on dedicated servers
Most ISPs (residential)	Blocked	Business accounts may have exemptions; residential generally cannot

The architectural implications:

Self-hosted mail servers on cloud VMs. Programmes wanting self-hosted email on AWS EC2, Google Cloud, or Azure typically cannot do direct port 25 outbound. The standard pattern is using the cloud provider's managed email service (AWS SES) or routing outbound through a third-party SMTP service (SendGrid, Mailgun).

Self-hosted mail servers on dedicated servers. Hetzner, OVH, IONOS, and other dedicated server providers typically allow port 25 outbound. Self-hosted email is operationally simpler on these providers than on the major cloud VMs.

Applications on cloud infrastructure. Applications generating email should use port 587/465 to submit to a managed SMTP service rather than attempting port 25 directly. The application running on EC2 calls Amazon SES API (or an ESP API) which handles the actual delivery from infrastructure with proper port 25 access.

Residential and small business networks. Email clients (Thunderbird, Outlook, Apple Mail) on residential connections use port 587 to submit to their mail server (corporate Exchange, Gmail SMTP, etc.). The mail server then handles the outbound delivery from its own infrastructure where port 25 is permitted.

Configuration examples

Practical configuration for common scenarios:

Postfix configured as outbound mail server (port 25 outbound):

# Bind to all interfaces, listen on port 25
inet_interfaces = all
smtp_bind_address = 198.51.100.10

# Enable opportunistic TLS for outbound port 25 traffic
smtp_tls_security_level = may
smtp_tls_loglevel = 1

# Strong cipher requirements
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

Postfix configured as submission mail server (port 587, STARTTLS):

# In master.cf, enable the submission service
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

Python smtplib for client submission on port 587:

import smtplib

# Connect and require STARTTLS
with smtplib.SMTP('smtp.example.com', 587) as server:
    server.starttls()  # Upgrade to TLS
    server.login('user@example.com', 'password')
    server.send_message(msg)

Python smtplib for implicit TLS on port 465:

import smtplib

# Implicit TLS from connection start
with smtplib.SMTP_SSL('smtp.example.com', 465) as server:
    server.login('user@example.com', 'password')
    server.send_message(msg)

Node.js Nodemailer for port 587 with required TLS:

const transporter = nodemailer.createTransport({
  host: 'smtp.example.com',
  port: 587,
  secure: false,        // STARTTLS, not implicit TLS
  requireTLS: true,     // Fail if TLS upgrade fails
  auth: { user: 'user@example.com', pass: 'password' }
});

Node.js Nodemailer for port 465 with implicit TLS:

const transporter = nodemailer.createTransport({
  host: 'smtp.example.com',
  port: 465,
  secure: true,         // Implicit TLS from start
  auth: { user: 'user@example.com', pass: 'password' }
});

Decision framework by use case

The decision framework for SMTP port selection in 2026:

Use port 587 with STARTTLS when: the application or client is doing standard SMTP submission to a mail server or ESP; the SMTP library is properly configured to require TLS rather than merely prefer it; broad library and infrastructure compatibility is needed; the deployment is a typical web application, mail client, or marketing platform.

Use port 465 with implicit TLS when: compliance requirements specifically prefer implicit TLS over STARTTLS; the SMTP library handles implicit TLS more cleanly than STARTTLS; performance optimisation matters for high-throughput connection establishment; the operator wants to eliminate the STRIPTLS attack surface entirely.

Use port 25 for server-to-server delivery when: the system is a mail server delivering messages to recipient mail servers (the normal MTA function); both ends of the connection are mail servers, not clients; the infrastructure has port 25 access (dedicated servers, on-premise infrastructure, cloud VMs with exemption).

Use port 2525 as fallback when: the standard ports (587 and 465) are blocked by network policies; corporate firewalls allow non-standard high-number ports but block standard SMTP ports; the ESP or mail server supports port 2525 as an explicit alternative.

Never use port 25 for client submission. The lack of authentication makes it inappropriate; the blocking situation makes it operationally unreliable; the security model differs from what submission needs. Applications, mail clients, and any non-mail-server software should never default to port 25 for submission.

The 2026 default for new email infrastructure: port 587 with STARTTLS for client submission, port 25 for server-to-server relay between mail servers, port 465 with implicit TLS when specific reasons favour it, port 2525 only as fallback when network restrictions block the standard ports.