What Is a Secure SMTP SSL Port? Here’s What to Know About SMTP Security
(11 votes, average: 3.91 out of 5)
Loading...All you need to know about secure SMTP SSL ports 587, 25, 465 and 2525, and the roles they play in email security
Simple mail transfer protocol (SMTP), which many email clients use to transfer outbound email messages, has fought a long and tedious fight to get where it is today. Several RFCs later, we finally have a standard that talks not just about reliable mail transfer but also looks at how to secure email communications. But none of it will help you if, while configuring your mail servers, you continue using the non-encrypted ports!
In the following sections, we’ll look at how SMTP security evolved in terms of some of the authentication methods that are available for use today. We’ll also talk about secure SMTP port 587, port 465, port 2525, etc. But before any of that, let’s get an overview of SMTP security.
SMTP Security
In and of itself, SMTP is an insecure protocol. It essentially lacks any real security features, which is why other methods of authentication and secure transmissions are required.
Around 2004, researchers were trying to solve the problem of how to trust where the message was originating because SMTP was designed in a way that the displayed sender “From” field need not match the envelope sender “Mail From” field. So then how would you verify if your friend Jerry was sending you the email or whether someone was impersonating him?
This is why authentication methods like Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), etc. came into the picture in an attempt to prevent the sharing of fraudulent emails via phishing attacks or spoofed addresses.
Email signing certificates, which not only can utilize end-to-end email encryption but also help to verify the identity of the sender, is another method of increasing email security. SSL/TLS certificates also add additional layers of security by encrypting the email servers themselves.
SPF, DKIM, and DMARC: The Three DNS Records That Are Your Key to Email Security
Sender Policy Framework
SPF records map IP addresses to specific domains indicating to the receiving client which addresses can send emails on behalf of a domain. Irregular SPF records (with permerror, fail, etc.) could be an indication of spoofed email addresses. The DNS records (the system that translates domain names to IPs) linked to a domain lets the client know which server wants to communicate with them, or if a client is sending a message, which server it’s talking to.
A TXT record, a type of DNS record, can hold SPF data and is used to indicate to a mail exchange server which hosts from a domain are authorized to send emails. However, this isn’t a foolproof method, and it also requires administrative efforts to maintain the records and time for any changes to propagate across the internet every time the fields update.
Most of the time, instead of implementing a hard fail that may block vital emails, organizations employ a soft fail mechanism that displays a warning message whenever an email with unverified values gets delivered.
DomainKeys Identified Mail
DKIM, on the other hand, is a digital signature that’s used to assert authenticity and verify if the content of an email message was modified.
Domain-based Message Authentication, Reporting, and Conformance
DMARC was defined in RFC 7489 in the year 2015 and is meant to work alongside SPF and DKIM as a mechanism that describes how to respond to potentially spoofed emails. It essentially relies on one method or the other to authenticate an email. Depending on the value of the “p” flag in DMARC, the receiving server can either reject or quarantine the email. They can also opt to do nothing by setting the value as none and merely gain visibility without impacting the flow.
The “rua” is another prominent flag that can be used to specify the list URIs where feedback can be sent (like the email address of a security group in the form “mailto:[email protected]”). Another flag worth mentioning is the “pct” tag that describes the percentage of your email to which an action will be applied. For instance, if your DMARC record is set as “p=reject, pct=0” it translates to the reject policy will be applied to zero percent of the domain’s messages.
A word of caution: Be wary when you see this flag, or about using it if you’re a domain owner. It can completely undermine the value that DMARC provides for email security.
Secure SMTP SSL Ports
Simple mail transfer protocol secure (SMTPS), in the days long gone, used port 465 to secure SMTP at the transport layer by wrapping it inside a TLS (transport layer security) connection. The confusion around secure SMTP ports is understandable since the Internet Assigned Numbers Authority (IANA) at one point had taken the liberty to register port 465 to be used for SMTPS.
Let’s take a look at each of these ports individually to gain a better understanding of secure SMTP ports:
Port 465
Port 465 was never officially recognized by the IETF as an SMTP port, but since IANA had registered it to be used for SMTPS, it may still be used as an SMTP SSL port in some legacy systems. However, by the end of 1998, IANA had assigned a new service to this port. As such, it’s better to not use it as a secure SMTP communication even if your service provider extends support for it.
Port 25
In a nutshell, port 25 is still used for SMTP relaying. In fact, with SMTP STS, which segregates message submission and message relaying, port 25 continues to be used for relaying a message from one mail server to another. However, unless you’re in charge of managing a message transfer agent (MTA) or a mail server, this port may be blocked for you, and normally you should see no traffic on this port.
Port 587
Port 587 should be used as the default port for submitting email messages to a mail server along with TLS encryption as per the guidelines laid out by the Internet Engineering Task Force (IETF). Transport layer security can be implemented in two ways — opportunistic (explicit) TLS or through forced (implicit) TLS.
With opportunistic TLS, first, an attempt is made to transfer the message in an encrypted form by switching from a non-encrypted channel to a secure one using the STARTTLS command. However, if both client and email servers can’t agree upon an encryption standard, the message is transmitted in plaintext.
In the case of forced TLS, on the other hand, if the negotiation fails, and the email client and server can’t support the same encryption standards, the message delivery then fails as well.
Port 2525
Port 2525 is not recognized officially by either IETF or IANA, but it is commonly supported by most email service providers in case port 587 has been blocked for some reason.
In Summary
Hopefully, your questions around SMTP security and secure SMTP ports that enable encrypted email communications have been answered. Though email security is still a work in progress, we’ve come a long way from the days of open relay. As you’ve discovered, we can now sign our emails, block IPs, have the server perform a consistent action if verification fails and share feedback to gain visibility into where we might be going wrong.
New email security standards are continually being developed, the latest being SMTP STS, defined by RFC 8461. It works alongside STARTTLS and is a mechanism that tries to avoid encryption downgrades. Gmail was the first email provider to adopt SMTP MTA STS and SMTP TLS reporting.
No comments