← RFC Reference

RFC 8314: Cleartext Considered Obsolete

Why This Exists

Email has historically used three cleartext ports for client-to-server communication:

All four start as cleartext connections. STARTTLS was bolted on to upgrade these connections to TLS mid-stream. But STARTTLS has systemic weaknesses:

• Downgrade attacks. An attacker can strip the STARTTLS capability from the server's response, and many clients will silently fall back to cleartext.
• Pre-TLS command injection. The cleartext phase before STARTTLS is complete allows an attacker to inject SMTP commands that the server processes after the TLS handshake.
• Credential exposure. If STARTTLS fails or is stripped, the client may send AUTH credentials (username and password) in cleartext.

RFC 8314 declares these cleartext connections obsolete for email submission and mailbox access, and mandates implicit TLS as the replacement.

How It Works

Implicit TLS vs. STARTTLS

STARTTLS (the old way): Connect on a cleartext port, exchange greetings in plaintext, send a STARTTLS command, negotiate TLS, then proceed with the encrypted session.

-- STARTTLS on port 587 (submission) --
220 mail.example.com ESMTP          ← cleartext greeting
EHLO client.example.com             ← cleartext
250-mail.example.com                ← cleartext
250-STARTTLS                        ← attacker can strip this line
250 OK
STARTTLS                            ← cleartext
220 Go ahead                        ← cleartext
-- TLS handshake happens here --
EHLO client.example.com             ← now encrypted
AUTH PLAIN dXNlcjpwYXNz            ← encrypted (safe)

Implicit TLS (the RFC 8314 way): Connect to a dedicated TLS port. TLS handshake is the very first thing that happens. No cleartext phase at all.

-- Implicit TLS on port 465 (submissions) --
-- TLS handshake happens immediately on connect --
220 mail.example.com ESMTP          ← encrypted from first byte
EHLO client.example.com             ← encrypted
AUTH PLAIN dXNlcjpwYXNz            ← encrypted

The New Port Assignments

Port 465 has a complicated history. It was originally assigned for "SMTPS" in the late 1990s, then revoked in favor of STARTTLS on 587. RFC 8314 re-assigns it as submissions (note the 's') for implicit TLS submission. This time it's official and permanent.

What About Port 25?

Port 25 is for server-to-server relay, not client submission. RFC 8314 does not change port 25 behavior. Server-to-server SMTP still uses opportunistic STARTTLS, with MTA-STS or DANE providing enforcement. The distinction matters: clients authenticate with credentials (which must be protected), while servers authenticate via DNS, DKIM, and SPF.

Key Technical Details

TLS Version Requirements

RFC 8314 requires TLS 1.2 or later. TLS 1.0 and 1.1 are deprecated by RFC 8996. In practice, you should require TLS 1.2 minimum and prefer TLS 1.3.

Certificate Validation

With implicit TLS, clients must validate the server certificate against the expected hostname using standard Web PKI rules. This is a significant change from the STARTTLS era where many clients accepted any certificate. The certificate must:

• Be issued by a trusted Certificate Authority.
• Match the server hostname (the name the client connects to, not necessarily the MX hostname).
• Not be expired or revoked.

SRV Records for Service Discovery

RFC 8314 works alongside RFC 6186 for automatic client configuration via SRV records:

Client Configuration

For application developers integrating SMTP submission:

# Python example: implicit TLS on port 465
import smtplib

# Correct: SMTP_SSL connects with TLS immediately
with smtplib.SMTP_SSL('mail.example.com', 465) as smtp:
    smtp.login('user', 'password')
    smtp.send_message(msg)

# Avoid: STARTTLS on port 587 (legacy)
# with smtplib.SMTP('mail.example.com', 587) as smtp:
#     smtp.starttls()
#     smtp.login('user', 'password')

Common Mistakes

• Confusing port 465 with port 25. Port 465 is for client submission with implicit TLS. Port 25 is for server-to-server relay. Never use port 465 for MX delivery.
• Still offering cleartext on port 587 without STARTTLS enforcement. If you must support port 587, require STARTTLS before AUTH. Never allow credentials over a cleartext connection.
• Disabling certificate verification. Implicit TLS requires proper certificate validation. Setting verify=False or equivalent defeats the purpose entirely. Fix the certificate instead.
• Using TLS 1.0 or 1.1. These are officially deprecated. Configure your server to accept TLS 1.2+ only.
• Treating port 465 as "SMTPS" (the 1990s version). The old SMTPS was revoked. Port 465 is now submissions per RFC 8314 — same underlying behavior (implicit TLS), but officially standardized with proper IANA registration.
• Not publishing SRV records. Without _submissions._tcp SRV records, clients can't auto-discover your implicit TLS endpoint. Many still default to STARTTLS on 587.

Deliverability Impact

• Protects sender credentials. For applications using SMTP submission (your app connecting to Mailer To Go, for example), implicit TLS on port 465 ensures your API credentials never traverse the network in cleartext — not even briefly during a STARTTLS upgrade.
• Faster connection establishment. Implicit TLS saves one round-trip compared to STARTTLS (no cleartext EHLO + STARTTLS exchange). For high-volume senders, this adds up.
• Required by major providers. Google Workspace and Microsoft 365 both support implicit TLS on port 465. It is the recommended submission method for new integrations.
• Eliminates a class of attacks. STARTTLS stripping, command injection, and credential sniffing are all impossible with implicit TLS. For compliance-sensitive environments, this matters.

Related RFCs