Current standard
What this RFC defines
RFC 8314 formally declares that cleartext email protocols are obsolete and mandates TLS for SMTP submission (ports 465 and 587), IMAP (port 993), and POP3 (port 995). It makes implicit TLS the preferred approach, deprecating the older STARTTLS upgrade mechanism for client-to-server connections.
Where you see it in practice
When your email client connects to port 465 (SMTPS) or 993 (IMAPS) instead of using STARTTLS on port 587 or 143, it is following the implicit TLS model that RFC 8314 recommends. Email providers that still allow unencrypted connections on port 25 for client submission are violating the spirit of RFC 8314. This RFC is why modern mail server configuration guides recommend disabling port 110 (POP3 cleartext) and 143 (IMAP cleartext).
Cleartext obsolete for submission and access
RFC 8314, published in January 2018, formally deprecated cleartext for email submission (port 587) and access (IMAP port 143, POP3 port 110). The document recommends implicit TLS on dedicated ports: 465 for submission, 993 for IMAPS, 995 for POP3S. Implicit TLS starts the TLS handshake as the first action after TCP connection, eliminating the plaintext window during which STARTTLS negotiation was vulnerable to stripping.
The port 465 comeback
Port 465 has a strange history: originally assigned to SMTPS in the late 1990s, it was deprecated in favor of STARTTLS on port 587, then rehabilitated by RFC 8314 for message submission with implicit TLS. Many mail clients now default to port 465 for outbound configuration because it is more resistant to STARTTLS stripping than port 587. Both ports work; the difference is whether TLS starts immediately (465) or is negotiated after cleartext EHLO (587).
Adoption and holdouts
Major mail services (Gmail, Outlook.com, iCloud, Yahoo, Fastmail, ProtonMail) all support implicit TLS on the RFC 8314 ports. Some smaller providers and hosted mail services still require STARTTLS on legacy ports, forcing users to configure port 587 with STARTTLS instead of port 465 with implicit TLS. For any new mail service deployment, following RFC 8314 recommendations (support both, prefer implicit TLS, disable cleartext connections entirely) is the modern baseline.
RFC 8314 (January 2018) declares cleartext SMTP submission and IMAP/POP3 access obsolete. It formalizes the shift to TLS-required client access: implicit TLS (port 465 SMTP, 993 IMAP, 995 POP3) preferred over STARTTLS on cleartext ports (587 SMTP, 143 IMAP, 110 POP3). Says MUAs SHOULD default to TLS-required and MUST NOT default to cleartext. Updates RFC 5321 and IMAP/POP3 base specs. Foundation for the current 2026 assumption that any authenticated mail client access uses TLS.
RFC 8314 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Deprecate cleartext for authenticated mail client access |
| Scope | Submission (SMTP), access (IMAP, POP3); NOT server-to-server relay (port 25) |
| Recommended pattern | Implicit TLS on ports 465/993/995 preferred over STARTTLS on 587/143/110 |
| Client requirement | MUAs SHOULD default to TLS-required, MUST NOT default to cleartext |
| Server requirement | Servers SHOULD offer both STARTTLS and implicit TLS ports, MUST NOT require cleartext |
| Published | January 2018 |
| Status | Best Current Practice (BCP 195) |
Recommended ports and modes
| Protocol | Cleartext + STARTTLS | Implicit TLS (preferred) | Cleartext-only (deprecated) |
|---|---|---|---|
| SMTP submission | 587 | 465 | 25 (never for submission) |
| IMAP access | 143 | 993 | Not recommended |
| POP3 access | 110 | 995 | Not recommended |
Why implicit TLS is preferred over STARTTLS
| Concern | STARTTLS on cleartext port | Implicit TLS on dedicated port |
|---|---|---|
| Downgrade attack window | Vulnerable: pre-upgrade capabilities can be stripped | None: TLS starts before any protocol data |
| Legacy cleartext fallback | Client may fall back if STARTTLS negotiation fails | No cleartext option; connection fails or succeeds under TLS |
| Detection by inspection | Cleartext session prefix visible in packet captures | All traffic encrypted from first byte |
| Client complexity | Client must handle EHLO, STARTTLS, re-EHLO sequence | Simpler: TLS handshake then protocol |
Client requirements per RFC 8314
Mail User Agents (MUAs):
MUST NOT default to cleartext for submission, IMAP, or POP3
SHOULD default to implicit TLS on the recommended port
SHOULD support both implicit TLS and STARTTLS
MUST validate server TLS certificate by default
SHOULD allow user to override certificate errors only after
warning about the security implications
MUST NOT silently downgrade to cleartext
Legacy cleartext support is permitted only for:
Explicit user configuration in specific edge cases
Backward compatibility with legacy servers on internal networks
Common RFC 8314 deployment mistakes
ssl = required or disable_plaintext_auth = yes; Postfix: smtpd_tls_auth_only = yes).Related standards and further reading
- RFC 3207: STARTTLS extension for SMTP
- RFC 2595: STARTTLS for IMAP and POP3
- RFC 8446: TLS 1.3 (current recommended TLS version)
- RFC 8461: MTA-STS (server-to-server hardening)
- RFC 7672: DANE for SMTP (DNSSEC-backed TLS binding)
- RFC 8460: SMTP TLS Reporting
- RFC 6409: Message Submission (port 587 spec)
- RFC 4954: SMTP AUTH (paired with TLS)
- SSL/TLS Email Setup Guide: practical TLS configuration
- Email Protocols and Ports Guide: choosing the right port
- 550 Must Issue STARTTLS Error: common failure when TLS not offered
Frequently asked questions
Is cleartext SMTP submission still allowed?
Per RFC 8314, no for authenticated submission on port 587 or 465. Servers SHOULD NOT offer cleartext submission; clients MUST NOT default to cleartext. In practice: mainstream providers (Gmail, Microsoft 365, Yahoo, Fastmail) enforce TLS on all authenticated submission. Some legacy self-hosted setups still permit cleartext; upgrading is essential for security. Port 25 for server-to-server relay remains cleartext-capable, but that is a different scope.
Does RFC 8314 affect server-to-server (port 25) mail transfer?
No. RFC 8314 is scoped to client-facing endpoints: submission (SMTP) and access (IMAP, POP3). Server-to-server relay on port 25 uses opportunistic STARTTLS. Hardening the server-to-server path requires MTA-STS (RFC 8461) or DANE (RFC 7672), which are separate standards. RFC 8314 addresses the client-server leg specifically.
Why is implicit TLS preferred over STARTTLS?
Two reasons: eliminates the pre-upgrade cleartext window (STARTTLS starts cleartext, can be stripped by active attacker), and simpler client logic (TLS handshake immediately, no EHLO negotiation dance). RFC 8314 recognizes both approaches as valid but recommends implicit TLS for new deployments. Servers should offer both to maintain compatibility with existing clients.
Do I need to change my email client settings after RFC 8314?
Modern email clients (Outlook 365, Thunderbird recent versions, Apple Mail, mobile mail apps) default to TLS-required per RFC 8314. If your client is configured for cleartext (rare on modern software), switch to TLS. Server ports typically: SMTP submission 465 (SSL/TLS), IMAP 993 (SSL/TLS), POP3 995 (SSL/TLS). Or 587/143/110 with “STARTTLS” or “TLS if available” option; prefer implicit TLS ports where offered.
What certificate should my mail server use?
A publicly trusted certificate from a real Certificate Authority. Let’s Encrypt is free, automated (via ACME clients like certbot, acme.sh, or built-in support in Caddy/Traefik), and universally trusted. Self-signed certificates break RFC 8314 compliance and force clients to either fail or degrade security. Modern deployments should have automated certificate renewal running; expired certificates break authenticated mail entirely.
Did this guide save you time?
SMTPedia is free and independent. A coffee helps keep every guide accurate.
Buy SMTPedia a coffeeAbout the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.