Email SMTP Ports: 25 vs 465 vs 587 vs 2525

Every day, more than 370 billion emails move across the internet, yet few people think about the infrastructure that makes this constant flow of communication possible. At the center of it all is Simple Mail Transfer Protocol (SMTP), the standard protocol responsible for sending emails from a sender’s client or application to a mail server, and then onward to the recipient’s server.

An SMTP port is the network endpoint that enables this connection. In email transmission, the port determines how a client or application communicates with the mail server and which security mechanisms, such as encryption and authentication, are applied during the process. This is why the SMTP port you use matters for both deliverability and security. The wrong port can cause connection failures, blocked messages, or weaker protection during transmission, while the correct configuration supports reliable and secure email delivery.

The most commonly used SMTP ports today are 25, 465, 587, and 2525. In this guide, we explain how each of them works and how to choose the right one for secure, reliable email delivery.

Let’s dive in.

Understanding SMTP Fundamentals

What is SMTP and How Does It Work?

Simple Mail Transfer Protocol (SMTP) is the Internet standard for electronic mail transmission.

Developed in the early 1980s, SMTP serves as the foundation for how emails move across networks from sender to recipient.

Think of the functions of SMTP a bit like a relay race:

1. Composition: You write an email in your client (like Gmail, Outlook, or Apple Mail)
2. Submission: Your email client submits the message to an SMTP server
3. Relay: The SMTP server determines where to send the message next
4. Delivery: After potentially passing through several SMTP servers, the message arrives at the recipient’s mail server
5. Retrieval: The recipient accesses the message using protocols like POP3 or IMAP

An illustration that shows the simple process of how an email is sent across the internet (Compose > SMTP Server > Deliver to Recipient’s Mail Server, and then Read)

To visualize this process, imagine sending a physical letter:

• You (email client) write a letter and drop it in a mailbox (SMTP submission)
• The postal service (SMTP relay) routes your letter through various sorting facilities
• Eventually, the letter arrives at your recipient’s local post office (incoming mail server)
• Your recipient checks their mailbox (POP3/IMAP) and retrieves your letter

The Evolution of SMTP Ports

When SMTP was first standardized in 1982, email security wasn’t a primary concern.

The internet was a much smaller, more trusted network primarily used by academic and research institutions.

Therefore, the original SMTP specification had no built-in security mechanisms – emails were transmitted as plain text, with no encryption or robust authentication.

However, this lack of security became problematic as the internet grew and email became a critical communication tool for businesses and individuals.

Some key security issues with traditional SMTP include:

• Plain text transmission: Messages could be intercepted and read
• No encryption: Sensitive data was vulnerable
• Limited authentication: Easy to forge sender identities
• Open relay potential: Servers could be exploited to send spam

Over time, extensions and enhancements to SMTP were developed to address these shortcomings:

• SMTP AUTH: Provided authentication mechanisms
• STARTTLS: Added support for transport-level encryption
• SMTPS: Implemented SSL/TLS encryption throughout the connection

What are Ports and Why Do They Matter?

An illustration of icons representing the different email ports and why you’d use them

In networking, a port is a logical endpoint for communication.

Think of ports as specialized doorways into a computer system – each serving a specific type of traffic. Ports are identified by numbers ranging from 0 to 65535.

For SMTP communication, specific ports have been designated:

• Port 25: The original SMTP port
• Port 465: Initially designated for SMTPS (SMTP over SSL)
• Port 587: The modern message submission port
• Port 2525: An alternative port used when standard ports are blocked

The choice of port affects:

1. Security: Different ports offer varying levels of encryption and authentication
2. Deliverability: ISPs may block certain ports to reduce spam
3. Compatibility: Not all email services support all ports
4. Functionality: Some ports are designed for specific purposes in the email ecosystem

Understanding these distinctions is crucial for setting up reliable, secure email systems.

The Major SMTP Ports: A Historical Perspective

So, why these ports and why are there differences? Why not just have one secure port specifically for email that everyone uses? Let’s break that down.

Port 25: The Original Standard

Port 25 was established as the standard SMTP port in 1982 when the protocol was first defined by the Internet Engineering Task Force (IETF).

For many years, it served as the default port for all SMTP traffic, both for submitting emails from clients to servers and for server-to-server relay.

The implementation of Port 25 originated from a 1982 request by the University of Southern California to the Internet Engineering Task Force (IETF).

At that time, the focus was on establishing a standardized communication channel for email transmission with basic protection against attacks, such as man-in-the-middle interception.

Today, the role of Port 25 has narrowed significantly. Its primary function is now limited to:

• Server-to-server communication: Mail Transfer Agents (MTAs) use Port 25 to relay messages between mail servers
• Legacy system support: Some older email systems still rely on Port 25

A simple telnet connection to an SMTP server on Port 25 might look like this:

Notice the 250-STARTTLS line, indicating that this server supports encryption via the STARTTLS command, but it’s not mandatory.

However, with this in mind, Port 25 has several significant security limitations:

• No required encryption: By default, communications over Port 25 are unencrypted
• Optional STARTTLS: While supported, encryption isn’t mandatory
• Vulnerable to interception: Plain text communications can be easily read if intercepted
• Spam vector: Historically used for sending spam emails

Because of these issues, particularly its exploitation by spammers, many Internet Service Providers (ISPs) and cloud hosting providers now block outbound traffic on Port 25 from their customers.

This blocking helps prevent compromised systems from being used to distribute spam.

If you’re experiencing connection issues on Port 25, it’s likely because your ISP is blocking it. In a simple test, you might see:

This blocking is so widespread that Port 25 should no longer be used for email client submissions. Instead, it should be reserved solely for server-to-server communication.

Port 465: The SSL/TLS Implicit Encryption Port

Port 465 has perhaps the most convoluted history of the SMTP ports.

In the mid-1990s, as the need for email encryption became apparent, the Internet Assigned Numbers Authority (IANA) briefly assigned Port 465 for “SMTPS” – SMTP over SSL.

However, this assignment was short-lived.

Around 1997, the IETF decided on a different approach to secure SMTP: adding the STARTTLS command to the SMTP protocol itself, which would allow encryption to be negotiated over existing ports.

As a result, Port 465’s official assignment for SMTPS was revoked after only about a year.

Despite this official deprecation, many email services had already implemented support for Port 465, and it continued to be widely used. This created a situation where Port 465 was being used in practice even though it was no longer officially designated for SMTP.

Implicit TLS Functionality

Port 465 uses what’s known as “Implicit TLS” or “Implicit SSL”:

• The connection begins with SSL/TLS negotiation immediately
• No part of the communication occurs in plain text
• If TLS negotiation fails, the connection is terminated
• All subsequent SMTP commands are sent through the encrypted channel

This approach is similar to how HTTPS works on the web – the secure connection is established before any application data is transmitted.

Here’s a simplified communication flow for Port 465:

• Client initiates connection to server on Port 465
• SSL/TLS handshake occurs
• Upon successful handshake, SMTP communication begins
• All SMTP commands and data are encrypted

Today, Port 465 exists in a curious state:

• It’s not officially recognized by the IETF for SMTP
• It’s widely supported by email service providers
• It’s recommended by some consumer email providers
• It provides strong security through its implicit TLS approach

Port 465 is appropriate for:

• Legacy systems that were configured to use SMTPS on this port
• Scenarios where maximum protection against downgrade attacks is required
• Situations where an email provider specifically recommends it

The Internet Assigned Numbers Authority has now reassigned Port 465 to a different service (“URL Rendezvous Directory for SSM”), though in practice it continues to be primarily used for secure SMTP.

Port 587: The Modern Submission Port

In 1998, RFC 2476 (later replaced by RFC 6409) introduced the concept of a dedicated “message submission” port separate from the SMTP relay port. This separation addressed the growing need to distinguish between two different types of SMTP traffic:

• Message submission: Email clients submitting messages to their mail server
• Message relay: Mail servers transferring messages to other mail servers

Port 587 was designated for this message submission role, creating a clear distinction from Port 25’s relay function. This separation allowed for different policies and security requirements to be applied to each type of traffic.

STARTTLS Capabilities

Port 587 uses “Explicit TLS” through the STARTTLS command. Here’s how it works:

1. Client connects to the server on Port 587
2. Server identifies itself and lists its supported extensions
3. Client issues the STARTTLS command
4. Server responds, and TLS negotiation begins
5. Upon successful negotiation, the SMTP session is encrypted
6. Client typically authenticates using SMTP AUTH
7. Email submission proceeds within the encrypted channel

A typical SMTP session using Port 587 with STARTTLS might look like this:

Notice how SMTP communication begins in plain text but switches to TLS encryption after the STARTTLS command is issued.

In most cases, Port 587 will be your port of choice.

It’s emerged as the recommended standard for email submission for several compelling reasons:

• Official standard: It’s recognized by the IETF as the proper port for message submission
• Wide support: Most modern email providers support Port 587
• ISP compatibility: It’s less likely to be blocked by ISPs than Port 25
• Security with flexibility: Supports strong encryption while maintaining backward compatibility
• Required authentication: Typically enforces SMTP AUTH, reducing spam

For the vast majority of users and organizations setting up new email systems, Port 587 should be the default choice for message submission.

Port 2525: The Alternative Option

Port 2525 is not an officially designated SMTP port by either IANA or the IETF. Instead, it emerged as a practical alternative when the standard ports (25, 465, and 587) are blocked by ISPs or corporate networks.

Functionally, Port 2525 typically works identically to Port 587:

• It supports STARTTLS for encryption
• It requires authentication via SMTP AUTH
• It’s used for message submission, not relay

The primary difference is simply the port number itself, which helps bypass network restrictions.

Port 2525 should be considered in these scenarios:

• When connecting from networks that block Ports 25, 465, and 587
• In corporate environments with strict firewall policies
• When using cloud providers that restrict standard email ports
• If you consistently experience connection issues with standard ports

Many email service providers, including Mailgun, SendGrid, and others, support Port 2525 specifically to provide this fallback option for their customers.

How to Choose the Right SMTP Port from a Security Perspective

An illustration of a developer thinking about which email port they should use in their project

Let’s talk security because, from a developer perspective, this is one of your most important considerations. There are several options.

STARTTLS (Explicit TLS)

STARTTLS, used primarily on Ports 25 and 587, provides “opportunistic encryption” through these steps:

• The connection begins unencrypted
• The client issues the STARTTLS command
• If the server supports it, encryption is negotiated
• Communication continues encrypted

Advantages:

• Backward compatibility with non-TLS servers
• Works with existing ports and infrastructure

Disadvantages:

• Initial communication is unencrypted
• Vulnerable to downgrade attacks where an attacker prevents the STARTTLS command
• Not all servers require TLS, allowing plain text fallback

Implicit TLS

Implicit TLS, used on Port 465, takes a different approach:

• The connection begins with TLS negotiation immediately
• If TLS negotiation fails, the connection is terminated
• No unencrypted communication ever occurs

Advantages:

• No plain text communication at any point
• Impossible to downgrade to unencrypted connection
• Stronger protection against man-in-the-middle attacks

Disadvantages:

• Not backward compatible with servers that don’t support TLS
• Not the official IETF standard approach

Authentication Requirements

Authentication is a critical security component that verifies the identity of the sending client. The authentication requirements vary by port:

Port 25:

• Authentication often optional
• Frequently allows unauthenticated relay between servers
• May permit anonymous message submission on some servers

Port 465:

• Authentication typically required
• Usually enforced after TLS encryption established
• Rarely allows anonymous message submission

Port 587:

• Authentication required by standard
• Enforced after STARTTLS encryption
• Specifically designed for authenticated submission

Port 2525:

• Authentication requirements match Port 587
• Requires authentication for message submission

It’s worth noting that modern email servers should always require authentication for message submission, regardless of port, to prevent abuse.

Best Practices for Maximum Email Security

To ensure the highest level of email security when configuring SMTP:

1. Always use encryption:

• Configure your servers to require TLS for all connections
• Disable plain text authentication
• Use strong TLS versions (TLS 1.2 or higher)

2. Implement strong authentication:

• Require SMTP AUTH for all message submissions
• Use secure password storage (hashing with salt)
• Consider implementing two-factor authentication for email accounts

3. Stay current with certificates:

• Use trusted CA-signed certificates
• Regularly renew SSL/TLS certificates
• Monitor for certificate vulnerabilities

4. Configure proper headers and policies:

• Implement SPF, DKIM, and DMARC for authentication
• Set appropriate HSTS headers
• Configure mail servers to reject unencrypted connections

5. Monitor and audit:

• Log all SMTP transactions
• Regularly review logs for suspicious activity
• Test your email security configuration periodically

How to Implement SMTP Ports

An illustration of a developer thinking about the best way to set up their email sending SMTP ports.

Now, choosing the ports that are best for your project. We can break down this down by use case so you can find the best fit.

For Individual Users and Email Clients

If you’re configuring an email client like Outlook, Apple Mail, or Thunderbird:

1. First choice: Port 587 with STARTTLS

• Widely supported and least likely to be blocked
• Example configuration for Gmail in Outlook:
• Outgoing mail server: smtp.gmail.com
• Port: 587
• Encryption: STARTTLS
• Authentication: Yes, with username and password

2. Second choice: Port 465 with SSL/TLS

• If your provider specifically recommends it
• Example configuration for Yahoo Mail:
• Outgoing mail server: smtp.mail.yahoo.com
• Port: 465
• Encryption: SSL/TLS
• Authentication: Yes, with username and password

3. Last resort: Port 2525 with STARTTLS

• Only if ports 587 and 465 are blocked
• Not all providers support this port, so check documentation

For Business Applications and High-Volume Senders

For applications sending transactional or marketing emails:

Recommended: Port 587

• Best balance of deliverability and security
• Supported by all major email service providers
• Example for a Node.js application using Nodemailer:

Alternative: Port 465

• For providers that specifically recommend it
• Example in PHP using PHPMailer:

Backup option: Port 2525

• When deploying on platforms that block standard ports
• Example in Python using smtplib:

For Server-to-Server Communication

For mail server configuration handling relay traffic:

Standard: Port 25

• Used for MTA-to-MTA communication
• Should be configured with STARTTLS when possible
• Example Postfix configuration in /etc/postfix/main.cf:

Alternative if port 25 is blocked: Custom configuration

• Some providers allow relay on alternate ports
• Example:

Configuration Examples for Common Email Servers

Postfix Configuration (Linux)

To configure Postfix to secure SMTP submission on Port 587:

1. Edit /etc/postfix/master.cf:

2. Edit /etc/postfix/main.cf to configure TLS:

3. Restart Postfix:

Microsoft Exchange Server

To configure Exchange Server for secure SMTP submission:

1. Open the Exchange Admin Center
2. Navigate to Mail Flow > Receive Connectors
3. Create or edit a connector for client submission
4. Configure the connector to:

• Listen on port 587
• Require TLS encryption
• Require authentication
• Set appropriate permission groups (typically ‘Exchange Users’)

Testing Port Connectivity and Troubleshooting

To test connectivity to an SMTP server on a specific port, you can use simple command-line tools:

Common SMTP Port Issues and Solutions

Connection Timeouts and Authentication Failures

Problem: Connection Timeouts

Symptoms:

• Unable to establish connection to SMTP server
• Client reports “connection timed out” errors
• Email sending appears to hang indefinitely

Possible causes:

1. ISP or network blocking the port
2. Firewall restrictions
3. Server is down or unreachable
4. Incorrect server address

Solutions:

1. Try an alternative port (587, 465, or 2525)
2. Check firewall settings and network policies
3. Verify the server address is correct
4. Test on a different network to isolate ISP blocking issues
5. Increase connection timeout settings in your email client

Problem: Authentication Failures

Symptoms:

• Connection established but authentication fails
• Error messages like “535 Authentication failed” or “Invalid username/password”
• Unable to send mail despite successful connection

Possible causes:

1. Incorrect username or password
2. Authentication method mismatch
3. Account restrictions or security policies
4. TLS/SSL requirements not met before authentication

Solutions:

1. Verify credentials are correct and up-to-date
2. Check which authentication methods the server supports (PLAIN, LOGIN, CRAM-MD5)
3. Ensure encryption is properly configured before authentication
4. For Google and Microsoft accounts, you may need an app-specific password or to enable less secure apps
5. Check for account restrictions or IP limitations

Port Blocking by ISPs and Networks

Port blocking is increasingly common, especially for Port 25:

Identifying Port Blocking

Signs you’re experiencing port blocking:

• Connection timeouts consistently occur
• Other internet services work normally
• Problem persists across different email clients
• Issues occur on one network but not others

Testing for port blocking:

Solutions for Port Blocking

1. Switch to an alternative port:

• Try Port 587 for message submission
• If that fails, try Port 465
• As a last resort, try Port 2525

2. Use a VPN or different network:

• Mobile networks may have different policies than home ISPs
• Corporate networks may route through a smart host

3. Contact your ISP:

• Some ISPs will unblock Port 25 for business customers
• Be prepared to explain your legitimate need

4. Use a smart host or relay:

• Configure your mail server to relay through your ISP’s SMTP server
• Use a third-party email delivery service

TLS Negotiation Issues

TLS problems can be subtle and difficult to troubleshoot:

Common TLS Issues

1. Certificate validation failures:

• Server certificate is expired
• Certificate is not from a trusted authority
• Certificate hostname doesn’t match the server name
• Client and server cannot agree on cipher suites

2. Protocol version mismatches:

• Client using newer TLS version than server supports
• Server requiring newer TLS version than client supports
• Outdated TLS implementations with vulnerabilities

Diagnosing TLS Problems

Use OpenSSL to inspect the TLS handshake:

Solving TLS Problems

1. Server-side solutions:

• Update SSL/TLS certificates
• Configure proper certificate chains
• Support modern TLS versions (1.2, 1.3)
• Disable insecure cipher suites

2. Client-side solutions:

• Update email client or libraries to support modern TLS
• Configure the client to trust the server’s certificate authority
• Adjust TLS security settings if needed

3. Temporary workarounds (use with caution):

• Disable certificate validation for testing only
• Try different TLS versions to isolate compatibility issues

Beyond SMTP: Related Email Protocols

Someone sits at a computer with arrows pointing to icons of SMTP, IMAP, and POP3

SMTP is not the only system related to email, and it’s important to understand the rest of the system so you can build systems that work effectively, sustainably, and efficiently. Here’s a quick guide to some of the other factors you need to know.

While SMTP handles sending email, receiving email requires different protocols:

POP3 (Post Office Protocol version 3)

POP3 is one of the oldest email retrieval protocols:

• Function: Downloads messages from server to client
• Default Ports: 110 (unencrypted) and 995 (SSL/TLS)
• Behavior: Typically removes messages from server after download
• Best for: Single-device access with limited server storage

A simple POP3 session might look like:

IMAP (Internet Message Access Protocol)

IMAP is a more sophisticated protocol for accessing mailboxes:

• Function: Synchronizes messages between server and clients
• Default Ports: 143 (unencrypted) and 993 (SSL/TLS)
• Behavior: Keeps messages on server, allowing multi-device access
• Best for: Multiple devices accessing the same mailbox

An IMAP session might begin:

How These Protocols Interact with SMTP

Email’s end-to-end journey involves multiple protocols working together:

1. Composition & Sending (SMTP):

• User writes an email
• Email client sends via SMTP to the submission server
• Message is relayed via SMTP to the recipient’s mail server

2. Storage & Retrieval (POP3/IMAP):

• Recipient’s server stores the incoming message
• Recipient connects using POP3 or IMAP to access their mailbox
• Messages are downloaded (POP3) or synchronized (IMAP)

3. Response (SMTP again):

• Recipient replies to the message
• Their client sends the reply via SMTP
• The cycle continues

Port Configurations for a Complete Email System

A comprehensive email server setup requires multiple ports:

Setting up a complete email server requires configuring all these ports appropriately for both sending and receiving functionality.

Wrapping up

After exploring the complexities of SMTP ports, several clear guidelines emerge:

1. Port 587 remains the recommended standard for email submission:

• It provides secure transmission through STARTTLS
• It’s widely supported and less frequently blocked
• It follows established IETF standards

2. Port 25 should be reserved solely for server-to-server communication:

• It’s frequently blocked for client connections
• It lacks mandatory security in many implementations
• It’s the standard port for mail transfer between servers

3. Port 465 serves as an alternative for secure submission:

• It offers implicit TLS that prevents downgrade attacks
• It may be required for legacy systems
• It provides good security but isn’t the IETF standard

4. Port 2525 works as a fallback option:

• It bypasses common port blocks
• It isn’t standardized but is widely supported
• It should only be used when standard ports are unavailable

For different email users, our port recommendations are:

For individual users:

• Configure email clients to use Port 587 with STARTTLS
• Ensure proper authentication is enabled
• Use Port 465 only if specifically recommended by your email provider

For business email administrators:

• Configure mail servers to accept submissions on Port 587
• Require TLS encryption and authentication
• Use Port 25 only for server-to-server relay with TLS enabled
• Keep all security measures and certificates up to date

For developers integrating email functionality:

• Implement Port 587 as your default SMTP port
• Include fallback options to other ports (465, 2525)
• Always use authentication and encryption
• Stay current with security best practices

For email service providers:

• Support both Ports 587 and 465 for maximum compatibility
• Offer Port 2525 as a fallback option
• Implement strong security on all ports
• Stay ahead of emerging standards and security practices

By following these best practices and staying informed, you can ensure that your email infrastructure remains both secure and reliable, delivering messages successfully while protecting sensitive information from interception or compromise.

Email remains one of our most critical communication tools, and understanding the nuances of SMTP ports is essential for anyone managing email systems.

The protocols and ports we’ve explored represent decades of evolution in internet standards, adapting to growing security threats while maintaining the interoperability that makes email so universal.