SMTP Port 25, 465, 587 or 2525 – how to choose the right SMTP Port?
SMTP Port 25, 465, 587, 2525.. Which port should I use?
Choosing an SMTP Port can be tricky. The first question that comes in our mind when we are setting up the Simple Mail Transfer Protocol (SMTP) Server is
“Which is the best port for SMTP connectivity?”
There are multiple port options available, but which one should you use? Let me take you through the history of each port. It will give you a clear idea about all the ports and then we’ll discuss which one is best for SMTP connectivity.
History of SMTP Ports
In August 1982, USC/Information Sciences Institute submitted a proposal to the Internet Engineering Task Force (IETF). Request For Comments (RFC) 821 was published, establishing port 25 as the default transmission channel for internet email.
What do you mean by Transmission channel?
The SMTP transmission channel is a TCP connection established between the sender process port U and the receiver process port L. This connection is used as the transmission channel. This protocol is assigned the port 25, that is L=25 as the default transmission channel for communication between mail servers. Even after 3.5 decades, Port 25 is used as the primary means for transmitting emails between two mail servers.
In December of 1998, R. Gellens and J. Klensin submitted RFC 2476. This specifies the Internet standards track protocols for the internet community. SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished messages. However, SMTP is now also widely used as a message *submission* protocol, that is, a means for message user agents to introduce new messages into the MTA routing network. The RFC proposed a splits message submission from message relay. This will benefit developers and network administrators by making it easy to implement authenticated submission, security policies and guard against unauthorized mail relaying. The RFC defined that Port 587 is reserved for email message submission.
Later on in early 1997, the IANA registered 465 for SMTPS. It was initially planned for the SMTPS encryption and authentication “wrapper” over SMTP. But the end of 1998, this was revoked in favor of STARTTLS over SMTP (RFC 3207). With STARTTLS, this port can be used with or without TLS. Despite that fact, there are many servers that support the deprecated protocol wrapper, primarily to support older clients that implemented SMTPS. Unless you need to support older clients, SMTPS and its use on port 465 should remain nothing more than a historical footnote.
Common SMTP Ports
From 1982 till date, Port 25 is used as the default port to communicate email across the Internet using the SMTP. But the trend is changing now. Most SMTP clients are not using Port 25 because of many ISPs and hosting providers block or restrict SMTP connections on port 25. This is done to cut down a number of unsolicited emails that are sent from their networks. Unless you are specifically managing a mail server, you should have no traffic traversing this port on your server.
//Type the following command to see if Port 25 is blocked on your network. telnet pepipost.com 25 //If Port 25 is not blocked, you will get a successful 220 response (text may vary). Trying 22.214.171.124... Connected to pepipost.com. Escape character is '^]'. 220 pepipost.com ESMTP Postfix //If Port 25 is blocked, you will get a connection error or no response at all. Trying 126.96.36.199... telnet: connect to address 188.8.131.52: Connection refused telnet: Unable to connect to remote host
Almost every ESP does not accept connections on port 465. This port was initially used for the SMTPS encryption and authentication “wrapper” over SMTP. By the end of 1998, IANA has reassigned this port number for a new service. But, still many services continue to offer the deprecated SMTPS interface on port 465. Service providers that maintain port 465 do so because older Microsoft applications do not support STARTTLS.
Don’t use port 465, because this port is no longer an accepted standard for SMTP.
You should use port 587 as default SMTP port. Almost all mail servers support this port. In fact, Port 587 is the one recommended for mail submissions instead of port 25 as per RFC 2476. But even if the mail server supports it, it may or may not be open for mail submissions. For that, you need to check with your administrator or with your hosting service provider. Because all larger hosting services do not support port 587. You can use the same technique like port 25 to check if Port 587 is blocked or not. Just use the following command:
telnet example.com 587
This port, coupled with TLS encryption, will ensure that email is submitted securely and following the guidelines set out by the IETF.
Pepipost supports TLS connections, which you can verify by connecting and issuing an EHLO command from the command line interface. The resultant “250 STARTTLS” confirms the endpoint accepts TLS connection requests.
telnet smtp.pepipost.com 587 Trying 184.108.40.206... Connected to smtp.pepipost.com. Escape character is '^]'. 220 pepipost.com ehlo pepipost.com 250-smta2.pepipost.com 250-PIPELINING 250-SIZE 20783082 250-VRFY 250-ETRN 250-STARTTLS
Almost every ESP supports the use of Port 2525, even though this is not an official SMTP port and not endorsed by neither the IETF nor IANA. Port 2525 is used as an alternative to port 587 for SMTP, you can use this port if all the above ports are blocked. Let’s suppose, your services hosted on Google Compute Engine and you are experiencing connectivity issues on Port 587. In that case, you can try Port 2525. This port also supports TLS encryption.
– SMTP port 587 is one of the best choices for nearly every use case for connecting to Pepipost
– Port 25 is the default port used for relaying
– Port 465 should no longer be used at all
– Port 2525 used when all other port is blocked
I hope this information was helpful to make the right decision on the SMTP port.
Want to configure Pepipost for your SMTP relay and email delivery? We have some good news. Apart from the best delivery and clean infrastructure, we also offer the best pricing that goes unmatched.
Found this blog useful? Please rate us
We are at the Hacktoberfest! If you are a developer, an Open Source lover then…Read More