What this RFC defines
RFC 3207 defines the STARTTLS extension for SMTP, which upgrades a plain-text SMTP connection to an encrypted TLS connection in-band, using the same connection and port. The client sends a STARTTLS command after the EHLO greeting, and both sides then negotiate TLS before continuing.
Where you see it in practice
When your MTA logs show TLS negotiation on port 25 between two servers, that is STARTTLS as defined in RFC 3207 in action. The STARTTLS capability advertised in an EHLO response (250-STARTTLS) tells the connecting server that TLS is available. SMTP servers that do not support STARTTLS still receive mail but without encryption, which is why MTA-STS and DANE were developed to enforce encrypted delivery.
How it connects to other RFCs
RFC 3207 works on top of RFC 5321 (SMTP) and uses TLS as defined in RFC 8446. RFC 8314 recommends implicit TLS (port 465) over STARTTLS for client-to-server submission, though STARTTLS on port 587 remains widely deployed. RFC 3207 remains the standard for MTA-to-MTA opportunistic TLS on port 25.
Current status
RFC 3207 is a current standard, published February 2002. It is the most widely deployed mechanism for encrypting SMTP connections between mail servers. RFC 8314 recommends implicit TLS for client submission scenarios, but RFC 3207 STARTTLS remains the standard for inter-server delivery on port 25.
Opportunistic TLS on port 25
RFC 3207 defined the STARTTLS extension in February 2002, allowing a plaintext SMTP session to be upgraded to TLS mid-conversation. The client sees STARTTLS in the EHLO response, issues the STARTTLS command, and the server responds with a 220 code; both sides then perform a TLS handshake and restart the SMTP session inside the encrypted channel. This design was chosen over a dedicated TLS-only port (like SMTPS on 465) because port 25 was already deployed everywhere and could not be replaced quickly. STARTTLS provided an incremental upgrade path.
The opportunistic problem
Because STARTTLS is opportunistic, the initial EHLO exchange happens in plaintext. This means a man-in-the-middle attacker can strip the STARTTLS capability from the EHLO response (a “STARTTLS stripping” attack) and force the session to remain in plaintext. MTA-STS (RFC 8461) and DANE (RFC 7672) were later designed to close this hole by allowing domains to publish policies that require TLS. Without MTA-STS or DANE, STARTTLS remains vulnerable to active attackers on the network path, though it does protect against passive eavesdroppers.
Implementation status in 2026
Every major MTA supports STARTTLS by default in 2026. Google reports that over 95% of inbound mail to Gmail is delivered over TLS thanks to STARTTLS adoption. The remaining gap is small, misconfigured, or intentionally-cleartext senders. RFC 8314 declared cleartext obsolete for submission, and RFC 8461 pushed hardening further with MTA-STS. STARTTLS itself remains the transport mechanism; the surrounding policy RFCs make it harder to downgrade in practice.
RFC 3207 (February 2002) defines the STARTTLS SMTP service extension: an opportunistic upgrade of a cleartext SMTP connection to a TLS-encrypted one. The receiving MTA advertises STARTTLS in its EHLO response; the client issues STARTTLS command; both sides perform TLS handshake, then re-issue EHLO over the encrypted channel. Extends RFC 5321. Hardening layers on top: RFC 8314 (cleartext deprecated for submission), RFC 8461 (MTA-STS, policy-forced TLS), RFC 7672 (DANE, DNSSEC-backed TLS binding).
RFC 3207 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Upgrade cleartext SMTP connection to TLS mid-session |
| Advertised as | STARTTLS in EHLO response |
| Client command | STARTTLS (no arguments) |
| Server response | 220 Ready to start TLS then TLS handshake begins |
| Post-handshake | Client re-issues EHLO over encrypted channel; prior state discarded |
| Failure mode | Opportunistic: falls back to cleartext if TLS unavailable or fails |
| Hardening layers | RFC 8314, RFC 8461 MTA-STS, RFC 7672 DANE |
| Published | February 2002 |
The STARTTLS handshake
Ports and modes: STARTTLS vs implicit TLS
| Port | Mode | Purpose | Current recommendation |
|---|---|---|---|
| 25 | Cleartext + STARTTLS | Server-to-server relay (MTA to MTA) | Opportunistic TLS; hardened via MTA-STS or DANE |
| 587 | Cleartext + STARTTLS | Message submission (client to server, RFC 6409) | TLS required per RFC 8314 |
| 465 | Implicit TLS (TLS from connection start) | Message submission alternative | RFC 8314 RECOMMENDED for submission |
| 2525 | Cleartext + STARTTLS (unofficial) | Fallback when 587 is blocked | Non-standard; some providers offer it |
Threat model and downgrade attacks
STARTTLS capability from the EHLO response, causing the client to fall back to cleartext. Similarly, an attacker can reset the TLS handshake, and most SMTP clients fall back to cleartext rather than aborting. Historical incidents include ISP-level STARTTLS stripping in multiple countries in 2014 to 2015. Hardening: MTA-STS (RFC 8461) forces TLS via policy published in DNS+HTTPS, DANE (RFC 7672) forces TLS via DNSSEC-signed TLSA records, and RFC 8314 deprecates cleartext for submission entirely.Common STARTTLS implementation mistakes
STARTTLS in EHLO but responds 454 TLS not available to the command breaks the assumption that advertisement implies capability. Some clients treat this as a hard failure and refuse to send. Fix: only advertise STARTTLS when the extension is actually operational.Related standards and further reading
- RFC 8314: Cleartext considered obsolete for submission and access
- RFC 8461: MTA-STS (Mail Transfer Agent Strict Transport Security)
- RFC 8460: SMTP TLS Reporting
- RFC 7672: DANE for SMTP (SMTP TLS via DNSSEC-signed TLSA records)
- RFC 8446: TLS 1.3 (recommended TLS version)
- RFC 2595: TLS for IMAP and POP3 (sibling client protocols)
- SSL/TLS Email Setup Guide: practical configuration
- 550 Must Issue STARTTLS Error: fixing the common failure
- Postfix Guide: STARTTLS configuration on common MTA
- Email Protocols and Ports Guide: 25 vs 465 vs 587
Frequently asked questions
What is the difference between STARTTLS and implicit TLS?
STARTTLS starts with a cleartext connection and upgrades to TLS via the STARTTLS command mid-session (typical on ports 25 and 587). Implicit TLS starts with TLS from the first byte, with no cleartext phase (typical on port 465 for submission). Both provide encryption; implicit TLS is simpler and slightly more secure because it eliminates the pre-upgrade cleartext window where an active attacker could strip STARTTLS. RFC 8314 RECOMMENDS implicit TLS (port 465) for message submission over STARTTLS (port 587) going forward.
Why is STARTTLS considered opportunistic?
Because clients fall back to cleartext when TLS is unavailable or the handshake fails, in order to maximize deliverability. This trade-off (encrypt when possible, transmit anyway when not) makes STARTTLS vulnerable to active downgrade attacks: an attacker strips the STARTTLS capability from the EHLO response, and the client dutifully falls back to cleartext. Hardening layers (MTA-STS, DANE, RFC 8314 for submission) close this gap by requiring TLS via out-of-band policy.
Do I need MTA-STS or DANE if I have STARTTLS?
For submission (port 587 or 465), no: RFC 8314 already mandates TLS. For server-to-server relay (port 25), yes if you want to protect against active downgrade attacks. MTA-STS is easier to deploy (policy in DNS TXT + HTTPS-served policy file); DANE is more secure but requires DNSSEC. Gmail, Microsoft 365, and other major providers support both; deploying at least one is the current best practice for security-sensitive domains.
What is the “550 Must issue STARTTLS” error?
The receiving server requires TLS for the incoming session but the client attempted to send without issuing STARTTLS first. Fix: configure your MTA to issue STARTTLS when the destination advertises it. This is common when sending to strict Office 365 or Gmail Workspace tenants from a Postfix/Exim configuration without smtp_tls_security_level = may or equivalent. See the 550 Must Issue STARTTLS guide for provider-specific fixes.
Which TLS versions and ciphers should I support for STARTTLS?
TLS 1.2 minimum, prefer TLS 1.3 (RFC 8446) when both endpoints support it. Disable TLS 1.0 and 1.1 (deprecated in 2020). Disable SSLv3 and lower entirely. Prefer forward-secret cipher suites (ECDHE key exchange). Reject RC4, 3DES, and export-grade ciphers. Test with SSL Labs SMTP test or CheckTLS periodically. Postfix, Exim, and Microsoft Exchange all support these constraints via configuration.
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.
