A Complete Guide to Using the STARTTLS Port for Email Encryption - Mystrika

Encrypted email you can trust. Private communications that remain private. Protecting your messages from prying eyes. In the world of email security, these are the promises of STARTTLS – a clever technology that brought encryption to the masses by upgrading existing plaintext sessions to secure TLS connections.

For 25 years, STARTTLS has delivered opportunistic email encryption to billions of users by transforming common protocols like SMTP, POP3, and IMAP into encrypted channels. Using dedicated ports like 587 combined with proper security practices, STARTTLS provides strong defenses against email interception and attacks.

This definitive guide covers everything you need to know about taking advantage of STARTTLS encryption for email privacy and security in your own systems. Let’s get started!

Page Contents

A Brief History of Email Encryption Protocols

In the early days of email, messages were transmitted in plaintext with no encryption. As email grew in popularity for personal and business use, the need for security and encryption became apparent. This section will explore the evolution of email encryption protocols like SSL, TLS, and most importantly, STARTTLS.

The Early Days of Plaintext Email

It may be hard to imagine today, but email communication was entirely plaintext and insecure when protocols like SMTP, POP3, and IMAP were first adopted in the 1980s and 90s. Encryption technology like SSL and TLS did not yet exist.

Sending a sensitive email over early protocols meant any attacker could intercept and read the entire contents with ease. And passwords or other confidential data were transmitted openly, completely visible to anyone monitoring the connection.

Of course, email adoption exploded even with these security gaps, as the benefits of fast asynchronous communication outweighed potential risks for most personal users.

But for businesses, lack of encryption posed significant problems. No company wanted confidential documents or communications leaked publicly. And password theft via email interception became increasingly common.

It was clear early on that email desperately needed a security upgrade. The only question was – how to add encryption without breaking all existing email infrastructure?

The Advent of SSL and TLS for Encryption

In the mid 90s, Netscape developed Secure Sockets Layer (SSL) encryption to secure web traffic. SSL used public key cryptography to encrypt data in transit between a client and server.

SSL certificates validated a server’s identity, preventing man-in-the-middle attacks. And the SSL handshake allowed clients and servers to establish secure connections.

SSL was quickly adopted to encrypt website traffic over HTTP. But applying SSL to existing email protocols proved more complex.

Transport Layer Security (TLS) emerged in 1999 as a more advanced encryption protocol. It included improved encryption algorithms and integrity checks compared to SSL.

Almost all modern encrypted web traffic uses TLS instead of SSL today (though the terms are still used interchangeably).

With strong encryption available, the race was on to implement SSL/TLS for email. But how could this be added without breaking existing email infrastructure and client software?

The Role of STARTTLS in Upgrading Connections

Since email protocols like SMTP were designed without encryption, they used plaintext ports by default for communication:

SMTP = Port 25
POP3 = Port 110
IMAP = Port 143

The idea arose to designate new alternative ports that required encryption:

SMTP over SSL/TLS = Port 465
POP3 over SSL/TLS = Port 995
IMAP over SSL/TLS = Port 993

But major problems quickly emerged. Many email clients only worked with the default plaintext ports. And even if they supported SSL, changing ports was complex for average users.

STARTTLS provided an elegant solution. It allowed clients to start a session in plaintext, then upgrade to TLS encryption by sending a STARTTLS command. The existing session was secured without changing ports or breaking client compatibility.

This allowed services to support both plaintext and encrypted connections simultaneously during the transition period. Users could upgrade security at their own pace.

Of course, STARTTLS has downsides too. Transmitting information before TLS upgrade leaves data briefly exposed. And the upgrade is dependent on proper client/server STARTTLS support.

But overall, STARTTLS succeeded in bringing email encryption into the mainstream. It remains widely used today across SMTP, IMAP, POP3, and other protocols.

The encryption protocols powering STARTTLS have evolved over time from SSL to TLS 1.2 and 1.3. And debates continue about the long-term role of STARTTLS vs implicit TLS for email security.

But without STARTTLS providing a flexible path to encryption, we may have been stuck in the days of plaintext email much longer. STARTTLS paved the way for encrypted email to become the universal standard it is today.

How STARTTLS Differs from Implicit TLS

STARTTLS and implicit TLS both provide email encryption, but take different approaches. Understanding how they differ in establishing connections and using ports reveals the pros and cons of each method.

Default Ports for Plaintext vs Encrypted Email

To appreciate how STARTTLS differs from implicit TLS, we first need to understand the default port conventions:

Plaintext protocols use standard ports:
SMTP = Port 25
POP3 = Port 110
IMAP = Port 143
Encrypted protocols use alternative ports:
SMTP over TLS = Port 465
POP3 over TLS = Port 995
IMAP over TLS = Port 993

These alternative ports were designated for implicit TLS – encryption is required from the start of the connection. Trying to communicate in plaintext on these ports will fail.

Upgrading Existing Connections with STARTTLS

STARTTLS allows clients to establish a normal plaintext session on the standard unencrypted ports first.

Once connected, the client issues a STARTTLS command to upgrade the existing insecure session to encrypted TLS:

Client connects to server on a standard plaintext port
Client sends STARTTLS command
Client and server perform TLS handshake to encrypt session
Session continues securely over the upgraded encrypted channel

This makes STARTTLS backwards compatible – it works on the default ports without breaking older client software that doesn’t support alternative encrypted ports.

Forcing Encryption with Implicit TLS

Implicit TLS takes a different approach – it enforces encryption by only allowing secure connections on special alternative ports like 465, 993, and 995.

With implicit TLS:

Client attempts to connect to the alternate encrypted port
The server immediately performs a TLS handshake to encrypt the session
If encryption fails, the connection is rejected

This guarantees encryption since plaintext connections are not allowed. But both client and server must support the alternate port and implicit TLS.

However, some email servers block alternate ports, which can cause connection failures. And many old email clients don’t work with the alternate ports meant for implicit TLS.

Key Differences Summarized

In summary, the key differences between STARTTLS and implicit TLS are:

STARTTLS	Implicit TLS
Upgrades plaintext sessions on standard ports	Forces encryption on alternate ports
Encryption is negotiated on an existing connection	Encryption required from the start
Compatible with old software and firewalls	Rejected if handshake fails
Brief data exposure before TLS upgrade	Fully encrypted session

So in essence:

STARTTLS maintains backwards compatibility by upgrading old ports
Implicit TLS prioritizes security by enforcing encryption on new ports

Over time, implicit TLS is gaining favor as the most secure approach. But STARTTLS remains widely used to support legacy systems and allow transitional upgrades.

Which method a client uses depends on software capability and port availability. Apps with modern encryption support often default to implicit TLS for enhanced security.

But STARTTLS provides the flexibility to connect from restrictive networks and use old devices that cannot handle the newer implicit TLS ports.

Using Port 587 for STARTTLS-Enabled SMTP

For submitting outgoing email, SMTP port 587 has emerged as the recommended standard to support STARTTLS encryption. Let’s examine why port 587 is favored over other options, how STARTTLS enables secure SMTP connections on this port, and some key compatibility considerations.

Why Port 587 is Recommended for SMTP Submission

Briefly, the history of SMTP port conventions is:

Port 25 was originally used for all SMTP traffic
Port 465 was designated for implicit SMTP over TLS
Port 587 was added specifically for SMTP submissions

Today, port 587 is recommended for client submissions for these reasons:

Port 25 is reserved for communication between mail servers only
Port 465 has compatibility issues with some mail services
Port 587 is dedicated to client submission with STARTTLS

Relegating client submissions to port 587 allows mail providers to restrict port 25 to just server-to-server SMTP transactions. This reduces abuse from spammers and botnets exploiting open relays on port 25.

And while port 465 supports implicit TLS, some providers block this port. Port 587 overcomes this issue by using STARTTLS for opportunistic encryption.

So port 587 provides the best of both worlds – support for secure STARTTLS connections while avoiding port blocks.

How STARTTLS Works with Port 587

On port 587, the SMTP transaction begins as plaintext before being upgraded to TLS:

Client establishes connection on port 587
Server offers STARTTLS option in SMTP banner
Client issues STARTTLS command
Server and client perform TLS handshake to encrypt session
Session continues over encrypted connection

Requiring clients to authenticate with a username and password before enabling STARTTLS protects against any sensitive data leakage.

Once STARTTLS is negotiated, all further SMTP commands and data transmit securely. The message contents are encrypted until delivery.

Compatibility Considerations for Port 587

Port 587 is well-supported today across most major mail clients and servers:

Web clients like Gmail, Outlook.com, Yahoo Mail all use port 587 by default for sending
Mail apps like Thunderbird and Apple Mail also default to 587
Mail servers like Exchange and Postfix enable 587 with STARTTLS

However, some legacy systems and older clients still fail to connect over port 587 for various reasons:

Very old servers may not be updated to support submission on port 587
Legacy clients hard-coded to use port 25 will reject other ports
Firewalls may allow port 25 but block ports 465 and 587

Workarounds exist like configuring port forwarding rules. But ideally, legacy email software should be updated to support modern security standards.

Fortunately, as outdated mail systems fade out, port 587 is reaching near universal adoption. When configured properly, it offers a future-proof SMTP submission solution with opportunistic TLS encryption through STARTTLS.

Configuring Clients and Servers for STARTTLS

To use STARTTLS encryption, both the email client and server must be properly configured. We’ll cover the key settings needed to enable STARTTLS on servers, configure client software, and troubleshoot connection issues.

Enabling STARTTLS Support on Email Servers

Most modern mail servers like Exchange, Postfix, and G Suite support STARTTLS by default for SMTP, IMAP, and POP3. But some legacy servers require enabling STARTTLS manually.

On open source SMTP servers like Postfix, look for SMTP settings like:

smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/mail.pem 
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_use_tls = yes

This specifies the server should use opportunistic TLS, require auth before STARTTLS, and points to the SSL/TLS cert files.

For IMAP/POP3, Postfix configs would be:

imap_tls_security_level = may 
imap_tls_cert_file = /etc/ssl/certs/mail.pem
imap_tls_key_file = /etc/ssl/private/mail.key
pop3_tls_security_level = may
pop3_tls_cert_file = /etc/ssl/certs/mail.pem  
pop3_tls_key_file = /etc/ssl/private/mail.key

Consult your server docs for details on enabling STARTTLS support. A valid TLS certificate is required.

Settings for Email Clients to Use STARTTLS

Email clients should have an option like “Use STARTTLS when available” under account settings. This enables opportunistic TLS.

Some clients have a “Use TLS” option which enforces implicit TLS only. This conflicts with servers lacking implicit support.

Clients should connect on the standard SMTP, IMAP, and POP3 ports of 25, 143, 110 rather than alternate encrypted ports when using STARTTLS.

Troubleshooting STARTTLS Connection Issues

To diagnose STARTTLS problems:

Verify the server offers STARTTLS – connect with Telnet and check for the STARTTLS banner
Try an encrypted TLS connection test with OpenSSL s_client
Inspect client/server logs to confirm STARTTLS use and see any TLS errors
Test with port 587 for SMTP since this is dedicated to STARTTLS submission
Update old SSL/TLS versions as needed – TLS 1.2+ is recommended
Check firewalls, antivirus, proxies for interference with TLS handshakes
Confirm trusted valid certificates – expire or self-signed certs cause problems

With robust server and client STARTTLS implementations, opportunistic email encryption should negotiate smoothly without disruption. Pay attention to any TLS errors and upgrade outdated software to maintain secure connections.

Best Practices for Using STARTTLS Securely

While STARTTLS facilitates encrypted email sessions, additional steps are needed to utilize it safely. Follow these best practices to maximize your STARTTLS security:

Validating Server Certificates and Identities

When initiating a STARTTLS handshake, the server provides a digital certificate to prove its identity.

Clients should validate these certificates to avoid man-in-the-middle attacks:

Verify the certificate is issued by a trusted certificate authority
Check that the domain in the certificate matches the server domain
Confirm the certificate is not expired or revoked
Use certificate pinning to detect unauthorized certificates
Consider using DANE TLSa to validate certificates against DNS records

Scrutinizing certificates before encrypting traffic ensures you are communicating with the legitimate server.

Keeping Up with Encryption Standards and Protocols

As attacks against SSL and TLS progress, new versions aim to stay ahead of vulnerabilities.

Make sure your software is up-to-date with modern encryption standards:

Use TLS 1.2 or higher (disable outdated SSL and TLS 1.0/1.1)
Ciphers should use perfect forward secrecy and 2048+ bit keys
Prefer elliptic curve cryptography (ECC) ciphers for performance
Disable NULL, MD5, SHA-1, RC4 and other weak ciphers
Watch for new TLS 1.3 adoption and implementation best practices

Proactively updating your TLS configuration prevents downgrade attacks and known protocol weaknesses.

Monitoring for Plaintext Leaks with STARTTLS

A common STARTTLS misconfiguration is allowing unauthorized plaintext transmission:

Sensitive information sent before STARTTLS negotiates encryption
Clients not validating server certificates properly
Buggy clients attempting TLS on plaintext ports

Monitor your traffic to catch any unintended plaintext leaks:

Inspect packet captures for plaintext secrets on TLS ports
Log traces of SMTP, POP3, IMAP sessions to confirm proper STARTTLS use
Test externally by transmitting plain “canaries” and watch for exposure
Script port scans to confirm non-TLS ports reject unencrypted sessions

With vigilance, you can enforce that communications only flow through secure encrypted channels as intended.

By validating certificates, hardening TLS, and detecting misconfigurations, you can trust that STARTTLS connections provide rock-solid security. Keep your knowledge sharp and configurations current to maximize protection.

The Future of Email Encryption with STARTTLS

STARTTLS has provided a robust way to incrementally add encryption to email over the last 20 years. But what does the future hold for STARTTLS and email security?

Wider Adoption of Implicit TLS Expected

As legacy mail software fades out, services are pushing clients toward implicit TLS with required encryption ports like 465, 993, 995 rather than opportunistic STARTTLS.

The advantages of implicit TLS include:

Encryption guaranteed from the start of the session
No risk of accidentally leaking plaintext data before STARTTLS
Simpler configuration without STARTTLS handshakes

The downside is reduced compatibility with older systems lacking support for the alternate implicit TLS ports.

But as clients and servers are steadily updated to support implicit TLS, its usage will likely eclipse STARTTLS over time. Email providers will also continue locking down port 25 for server-only communication to limit exploits.

New Protocols May Eventually Replace STARTTLS

While TLS 1.3 currently powers most encrypted web traffic, QUIC and HTTP/3 may begin taking over as they support encryption by default.

The IETF has also proposed EMAIL, a new secure email transport protocol designed as a potential successor to SMTP, POP3, and IMAP.

If these newer protocols gain adoption, they could eventually replace opportunistic STARTTLS for email encryption as well.

However, given the slow pace of upgrading email infrastructure, don’t expect STARTTLS to disappear anytime soon even if other standards emerge.

Continued Importance of Encryption for Email Privacy

Regardless of the specific protocol, end-to-end email encryption will only grow in importance for privacy and security:

Surveillance capitalism fuels demand for encrypted communications
Regulations like GDPR require safeguarding personal data
Email scams and phishing require stronger authentication
Politically sensitive correspondence needs protection
Businesses want to avoid email data breaches

So while the technology powering email encryption may change, the fundamental need for security is not going away.

Even if STARTTLS itself is eventually superseded, it helped bring ubiquitous email encryption into the mainstream. And any successor protocols will build on this foundation of opportunistic TLS that STARTTLS established.

The specific path forward is unclear, but the overarching trend toward universal encrypted email is certain. STARTTLS paved the way by retrofitting encryption into existing email systems, a contribution that will reverberate for decades to come.

Key Takeaways on Using the STARTTLS Port

The key points to remember about using port 587 and STARTTLS for email encryption are:

STARTTLS allows opportunistic encryption by upgrading an insecure session to TLS on the standard email ports.
Port 587 is the recommended standard for STARTTLS-enabled SMTP submissions.
Implicit TLS differs by requiring encryption from the start on special ports like 465.
Always validate server certificates and identities before encrypting STARTTLS connections.
Keep client and server TLS configurations up-to-date and disable outdated protocols.
Monitor for misconfigurations that allow unintended plaintext transmissions.
Migration toward implicit TLS on clients and servers is gradually progressing.
STARTTLS paved the way for ubiquitous email encryption and remains widely supported.
Encryption will only grow more important for email privacy, regardless of the specific protocols used.

Following security best practices for STARTTLS allows businesses and individuals to encrypt email in a backwards compatible way during the encryption transition period. As implicit TLS gains adoption, STARTTLS provides a flexible path to incrementally securing legacy email systems.

Frequently Asked Questions About STARTTLS

Let’s review some common questions about using STARTTLS for email encryption:

What is the difference between STARTTLS and implicit TLS?

STARTTLS upgrades an existing insecure session to encrypted TLS, while implicit TLS requires encryption from the start on special ports. STARTTLS works on the standard email ports and provides opportunistic encryption.

Is STARTTLS secure?

Yes, when configured properly STARTTLS provides secure encrypted communication. The encryption is negotiated after the session starts, so some initial data may leak before STARTTLS activates. Always validate server certificates to avoid interception.

Do email clients support STARTTLS?

Most modern email clients and servers have support for STARTTLS to enable encrypted SMTP, POP3, and IMAP sessions. Some very old legacy systems may lack STARTTLS capabilities.

What port should I use for STARTTLS SMTP?

Port 587 is the recommended standard port for STARTTLS-enabled SMTP submission by clients. Port 25 is for server-to-server mail transactions only.

How can I tell if STARTTLS is working?

Check application logs to confirm STARTTLS is negotiated properly during sessions. Watch for any TLS errors. You can also use packet captures or protocol analyzers to validate encryption is activated after STARTTLS commands.

Is STARTTLS being phased out?

STARTTLS remains widely supported, but a gradual transition is happening toward implicit TLS for enhanced security. STARTTLS may eventually be phased out as legacy systems with compatibility requirements are decommissioned.

What TLS version should I use with STARTTLS?

TLS 1.2 or higher is recommended. TLS 1.3 is ideal if supported. Avoid outdated protocols like SSLv3 or TLS 1.0.