Differences between ports 25, 587, and 465 and their use cases

The SMTP protocol uses multiple ports for email delivery. This article discusses each port's differences, rationale, and use cases. It discusses five different use cases related to email delivery and explains the best port to use in each scenario.

Assumptions

This article assumes you are familiar with:

Why Does SMTP User Multiple Ports

The answer to this question has more to do with history than technology. If the SMTP protocol were redesigned, it would probably use just one port that can accommodate every scenario. The protocol was introduced in the 1980s, and only port 25 was used for communication. Those were the days when folks trusted each other. Later, features like authentication and encryption were introduced, which resulted in the addition of more ports. Port 465 was introduced to handle encryption, while port 587 was introduced for authentication.

Today, even port 25 can be encrypted and optionally authenticated, confusing novice administrators when deciding on the correct value. This article addresses multiple use cases to tackle this problem by discussing them one at a time.

Differences

The following table summarizes some key differences between each port regarding encryption and authentication.

Port Encryption Authentication
25 Communication is initially started without encryption but quickly switched to encryption using the STARTTLS option. Sensitive data, including authentication, email addresses as well as actual message is transferred with encryption. Although you can configure port 25 to accept authentication after encryption is established, many administrators do not allow authentication on this port.
587 SMTP authentication is availble and expected on these ports.
465 Communication is encrypted from the beginning.

Use Cases

The following image visually displays the rationale for every use case. Each case is numbered and later discussed below.

Use Case 1 - Receiving emails from the Internet

Servers on the Internet will always send emails to port 25. You cannot receive inbound emails for your domain on any other port. This also assumes you're running your email server on a network with a static IP address. Click here if you do not have a static IP.

Encryption
Encryption is used if your server supports the STARTTLS option. You can enforce encryption on port 25 using the MTA-STS feature.

Authentication
Authentication is not required because your server will only accept emails destined for local users on your system. Configuring your server to accept emails for foreign domains is considered relaying, which should be prohibited on your server.

Preferred Port
You don't have a choice but to use port 25.

Use Case 2 - Users, devices and applications on your LAN want to send emails to internal as well as users online.

Users, devices, and application servers within your LAN need to send emails to your corporate email server, which is also running on-premise and will relay messages to their final destination.

Although encryption is less crucial because the email client and server are within a trusted environment, many organizations prefer encryption for added security or compliance.

Encryption
Encryption is enabled on port 25 or 587 using STARTTLS, or entire communication is encrypted on port 465.

Authentication
Authentication is not required when the recipient of an email message is an in-house user. It is only needed when relaying emails to foreign domains/users. Additionally, you can configure your SMTP server to accept relaying from specific IP addresses as an alternative to authentication.

Preferred Port
The preferred port is 587 if email delivery is more important than encryption. Although you can also use 465, some older devices may face problems if the SSL certificate is not trusted, an older protocol (SSLv1, TLS1.0, or TLS1.1), or an older cipher is used. Such devices will not use SSL on port 587 if they run into SSL-related issues when using the STARTTLS option. In other words, your corporate email server will accept emails even if encryption is not used on port 587. Email delivery will fail on port 465 if the device encounters an SSL-related problem.

Use Case 3 - Remote employees want to send emails to internal as well as users online.

This is similar to use case# 2, but the employee connects remotely over the Internet. In this case, encryption is essential.

Encryption
Similar to use case# 2, you can enable encryption on any port.

Authentication
You will need to enable SMTP authentication for these users. Accepting emails without authentication can leave your SMTP server open for relay, and unknown users can misuse it to send their junk emails.

Preferred Port

Port 465 is preferred. You can use port 587, provided the email client is configured to enforce STARTTLS. Clients such as MS Outlook will warn users if encryption cannot be used on port 587.

Using 465 enforces encryption, and emails cannot be delivered if there is a communication problem between an email client and server, forcing the administrators to figure out what is wrong with SSL.

Some email servers, such as Xeams, can warn administrators if a client connects to the server without encryption.

Use Case 4 - Your on-premise SMTP server relays emails to other servers on the Internet.

Your corporate email server will deliver the emails received from users, devices, and applications (use cases 2 and 3) to their final destination. Before sending the message, your server will perform an MX lookup against the recipient's domain to determine the destination server's hostname/IP address.

Encryption
Your server will use STARTTLS, provided the destination server supports it. The destination server can enforce STARTTLS by publishing an MTA-STS policy. In such cases, your email server will only deliver the message if encryption can be used.

Authentication
Authentication is not required.

Preferred Port
Communication can only occur on port 25 with STARTTLS.

Use Case 5 - Your on-premise SMTP server relays emails for foreign domains through MS Exchange Online or Google Workspace.

In this case, you use Microsoft Exchange Online or Google Workspace as your primary email system. However, you have an on-premise SMTP server, such as Xeams, that accepts emails from in-house users, devices, and applications. A few benefits of running an on-premise server are:

  • Your in-house devices/applications cannot speak OAuth 2.0, which Microsoft and Google now require.
  • You want to monitor emails going out of your network.
  • SMTP servers usually have a built-in queue that can deliver emails asynchronously. In other words, offloading message delivery to servers that can continuously retry delivering emails alleviates your applications from implementing an email delivery queue.

There are two methods to relay outbound emails through Microsoft or Google from your local SMTP server.

Method 1 - Direct
In this case, your server will send emails directly to the destination server. Messages destined for in-house recipients will go to Microsoft/Google. The following must be true for this method to work:

  • You will need a static IP address when connecting to the Internet.
  • You must add this static IP address to your domain's SPF record.
  • You must sign outbound emails with a DKIM signature.

The communication will occur on port 25, and STARTTLS will be used for encryption. SMTP authentication is not needed.

Method 2 - Relaying
In this case, your on-premise SMTP server will send every outbound email to Microsoft/Google, which will then deliver it to the final destination. You will configure your on-premise server to use OAuth 2.0, which is now required by both providers.

The following conditions must be met for this to work:

  • Your on-prem server must support OAuth 2.0, such as Xeams.
  • The sender's email address must match the user account used for authentication. This requirement is usually the biggest hurdle when using this method. If the sender of the email does not match the user ID for authentication, additional configuration is required for Microsoft and Google.
  • These providers limit the number of emails you can send daily. Your outbound email count must be lower than this limit.

The communication will occur on port 587, and STARTTLS will be used for encryption. OAuth 2.0 will be used for authenticating users.

Method# 1 is easier to configure than method# 2

Encryption
Yes, with STARTTLS

Authentication
No authentication is required for method #1 but is required for method# 2

Preferred Port
25 for method# 1 and 587 for method# 2

Use Case 6 - You use an SMTP service provider to send your outbound emails.

In this case, your service provider will dictate the ports, encryption protocol, and authentication method you can use.

You can configure your devices to connect directly to the service provider or send messages to your on-premise server, as mentioned for use case# 2, which will then be sent to the service provider.

This method is a good choice if you do not have a static IP address or if your ISP blocks outbound ports.

Encryption
Dictated by the service provider

Authentication
Yes

Preferred Port
Either 587, 465 or any other specified by the service provider.

Conclusion

In short, use the following points as a rule of thumb when deciding which ports to use for SMTP.

  • When communicating between an email client, such as MS Outlook or Mozilla Thunderbird, and an email server, use port 587 with STARTTLS or 465 with SSL/TLS. Users will use SMTP authentication before the server accepts messages destined for foreign domains.
  • Port 25 is used when two SMTP servers on different networks communicate. If both ends support the STARTTLS option, which most SMTP servers do, the servers will use encryption. SMTP authentication is not required if the destination server is the authorized server for the recipient's domain.