Every email you send exits your application or mail server through a TCP port — a numbered "door" in the network through which data flows. For email specifically, there are four ports that matter: 25, 465, 587, and 2525. Each has a distinct history, a specific intended use case, and a very different relationship with security and deliverability. Yet most developers and email marketers treat them as interchangeable, picking whichever one works first and never revisiting the choice.

That's a mistake. The port you submit mail on affects whether your messages get through at all, whether they're encrypted in transit, and how your sending infrastructure is perceived by mailbox providers and spam filters. This guide explains everything you need to know — from the underlying protocols to the pragmatic decision of which port to use in your specific setup.

How SMTP Ports Evolved - And Why It Still Matters

Understanding why four different ports exist requires a quick look at how email infrastructure evolved. SMTP — Simple Mail Transfer Protocol — was defined in 1982 by Jon Postel in RFC 821. At the time, the internet was a trusted academic network and security was not a concern. Port 25 was assigned as the universal SMTP port, used for all mail exchange between servers.

As the internet grew and spam became a crisis, the clean original architecture fractured. ISPs began blocking port 25 on residential and business connections to prevent compromised machines from sending spam directly to the world. Alternative ports were introduced, deprecated, and revised by standards bodies over the following decades. The result is the slightly messy landscape we have today: four ports, each with its own story.

Port-by-Port Breakdown

Here is a direct comparison of all four ports across every dimension that matters for deliverability and infrastructure decisions.

Encryption Models: STARTTLS vs. Implicit TLS

The most technically significant difference between ports isn't the port number itself — it's the encryption model. Ports 587 and 2525 use STARTTLS; port 465 uses Implicit TLS. These are fundamentally different approaches to securing the connection between your mail client and the SMTP relay, and the difference has real security implications.

Port 25: Why It's Blocked Almost Everywhere — And What That Means

Port 25 deserves special attention because it is simultaneously the most important port in the email ecosystem and the most restricted. Server-to-server mail delivery — the final hop from your ESP's infrastructure to Gmail's or Outlook's incoming mail servers — always uses port 25. You cannot change this. The MX records for every receiving mail server point to a host that listens on port 25.

What you can control is whether your application submits mail to a relay using port 25. You should not. Here's why:

Major cloud platforms including AWS EC2, Google Cloud, and Azure all block outbound port 25 by default on new accounts. AWS requires a formal support request to lift the restriction, and even then only grants it for specific use cases. This means that if you spin up a VPS and try to send email directly on port 25, your messages will either be silently dropped or you'll receive a TCP connection timeout before even reaching the target mail server.

The reason is anti-spam. Port 25 has been a primary vector for botnets and compromised machines blasting spam directly to the world's mail servers. Blocking it at the network edge removes this threat at the source. It has worked — but it also means that anyone building legitimate email infrastructure needs to submit through an authenticated relay on port 587 or 465, not send directly on port 25.

How Port Usage Has Shifted Over Time

Adoption of the "correct" submission ports has grown steadily as security awareness increased and old habits were replaced by better defaults in libraries and ESP documentation. The canvas chart below shows the estimated global share of authenticated SMTP submission traffic across the major ports over the past decade.

Choosing the Right Port: A Decision Guide

The choice of port depends on three factors: who you are (application developer, email marketer, sysadmin), what you're connecting to (an ESP relay, your own MTA, a cloud mail service), and what your network environment allows. The following breakdown covers the most common scenarios.

Scenario 1: Sending Transactional Email from an Application

Use port 587 with STARTTLS enforced as your first choice. It is the most universally supported port across all major SMTP relays and passes through virtually all firewalls. If your ESP or relay also supports port 465, prefer it if your language's SMTP library handles implicit TLS cleanly — Node.js's Nodemailer, for example, does this well with the secure: true flag.

Scenario 2: Sending Marketing Email via an ESP

Your ESP handles the port selection internally for delivery. What you control is the API or SMTP submission port your platform uses to hand off messages to the ESP's relay. Follow your ESP's documentation exactly — most will specify port 587 with authentication credentials. Port 2525 may be offered as a fallback if your hosting provider blocks 587.

Scenario 3: Running Your Own Mail Server

Your MTA (Postfix, Exim, Sendmail) needs port 25 open and listening to receive inbound mail from other servers. For outbound delivery, your MTA connects outbound on port 25 to remote MX hosts — this is non-negotiable. For user submission (clients connecting to your MTA to send), configure port 587 with SASL authentication and enforced STARTTLS, plus optionally port 465 with implicit TLS. Never open port 25 for unauthenticated submission from the internet.

Scenario 4: Locked-Down Cloud Environment (e.g., AWS, GCP)

If you cannot open port 587 (unusual but possible in very locked-down environments), fall back to port 2525, which most major ESP relays support as an alternative. Note that port 2525 is not an IANA standard and some firewalls or security scanners may flag it. Always confirm TLS support with your relay provider before relying on it for production traffic.

Diagnosing Port and Connection Issues

Port connectivity problems are among the most common causes of "email not sending" errors in application deployments. Before diving into logs and code, a quick network test can pinpoint whether you're dealing with a port block, a TLS misconfiguration, or a relay authentication failure.

Port Choice and Deliverability: The Indirect Connection

Port selection doesn't directly influence spam scores or inbox placement — mailbox providers evaluate messages based on content, authentication (SPF, DKIM, DMARC), and sender reputation, not the submission port. However, port choice has two indirect deliverability implications that are worth understanding.

First, unauthenticated relay on port 25 is a red flag. If your server is configured to accept and forward mail on port 25 without authentication, you are running an open relay — one of the fastest ways to get your IP address listed in every major blacklist within hours. Open relays are actively scanned for and exploited. The authentication requirement on ports 587 and 465 is as much about protecting your sending reputation as it is about security.

Second, encryption signals trust. While mailbox providers don't currently penalise senders for transmitting in plaintext on the submission hop, MTA-to-MTA encryption via STARTTLS on port 25 is becoming a baseline expectation. Google's Transparency Report shows the percentage of Gmail traffic sent over encrypted connections, and senders whose mail arrives without TLS are increasingly deprioritised in quality scoring models. Ensuring the full chain — submission to relay to destination — uses TLS is good hygiene that compounds over time.

The takeaway from these numbers: if your email is landing in the 13% of unencrypted traffic, you're at risk of losing deliverability. Modern mail infrastructure is overwhelmingly encrypted, and ensuring your stack — from submission port to relay to delivery — uses TLS throughout is no longer optional. It's the baseline expectation.