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).
How it connects to other RFCs
RFC 8314 obsoletes RFC 2595 (the earlier TLS-for-IMAP-and-POP3 RFC). It works with RFC 3207 (STARTTLS for SMTP), RFC 8446 (TLS 1.3), and RFC 6409 (mail submission port 587). Together these documents define the current secure mail submission stack.
Current status
RFC 8314 is a current standard, published January 2018. It is the definitive reference for TLS requirements in email client-to-server communication. Most modern mail providers comply with its requirements, though full enforcement of implicit TLS over STARTTLS varies.
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
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.
About 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.
