STARTTLS is the SMTP service extension defined in RFC 3207 (February 2002) that upgrades a plaintext SMTP connection to TLS-encrypted communication using an in-band command. The mechanism: client connects in plaintext, sends EHLO, server advertises STARTTLS in its 250-line response, client issues STARTTLS, server responds 220, both sides perform a TLS handshake, client sends a fresh EHLO over the now-encrypted channel. STARTTLS operates on SMTP ports 25 (server-to-server) and 587 (client submission); port 465 uses Implicit TLS instead per RFC 8314 (January 2018). STARTTLS is opportunistic by default — meaning the connection falls back to plaintext if TLS fails or isn't advertised — making it vulnerable to STRIPTLS downgrade attacks. MTA-STS (RFC 8461) and DANE (RFC 7672) are the policy and authentication overlays that close STARTTLS's structural opportunistic gap.
STARTTLS is the foundational protocol behind ~95% of inbox-bound email encryption (per Google Transparency Report). Every TLS-encrypted SMTP connection on port 25 between mail servers worldwide flows through STARTTLS — it's the universal mechanism that brought encryption to the SMTP ecosystem without requiring a flag-day cutover from the cleartext SMTP that existed since RFC 821 (1981). It's also the protocol with the most well-documented structural vulnerability in modern email: the STRIPTLS downgrade attack that MTA-STS and DANE exist specifically to address.
This entry closes the transport security cluster. With SMTP as the protocol foundation, MTA-STS as the policy layer, DANE as the cryptographic-anchor layer, and TLS-RPT as the reporting layer, STARTTLS is the underlying mechanism all of them protect or depend on. Most published material treats STARTTLS as either a one-line definition ("the SMTP TLS command") or a deep RFC walkthrough; this entry covers the operational middle ground — the actual handshake, the real attack surface, the configuration syntax, the testing commands, and how the modern email security stack closes RFC 3207's structural gap.
RFC timeline: how SMTP got TLS
SMTP encryption evolved through three RFC milestones plus the 16-year ambiguity around port 465. The complete timeline:
Jon Postel's original SMTP specification. No encryption — the protocol assumed a trusted network. ARPANET context.
IANA registers port 465 for "smtps" — implicit TLS submission. Industry-deployed but lacking formal IETF standard.
SMTP service extension for TLS upgrade. Proposed Standard. Limited downgrade-attack discussion.
Replaces RFC 2487. Adds AitM attack discussion (§5, §7), STARTTLS on submission port (§5.3), certificate validation guidance (§5.1). Still current.
IANA marks port 465 as deprecated for SMTPS. Industry usage continues despite formal deprecation, creating 16 years of ambiguity.
EFF reports ISP-level STRIPTLS attacks. Cisco IOS firewall configurations and Sandvine middleboxes documented stripping STARTTLS in production.
DNSSEC-anchored TLS authentication for SMTP. Closes the certificate-validation gap by binding the certificate fingerprint to DNS. See DANE entry.
Re-registers port 465 for Implicit TLS submissions. Formally recommends Implicit TLS (port 465) over STARTTLS (port 587) for new deployments. Closes the SMTPS/submissions ambiguity.
Policy layer: senders refuse to send plaintext to domains that publish MTA-STS policies. Closes the opportunistic gap. See MTA-STS entry.
Reporting layer: receivers send daily aggregate reports of TLS handshake outcomes, including STARTTLS failures. See TLS-RPT entry.
The STARTTLS handshake step by step
Real STARTTLS conversation between client and server, colorized to distinguish actors. This is exactly what flows over the wire:
# Step 1: Client opens TCP connection to mail.example.com:25 (plaintext) # Step 2: Server sends 220 banner 220 mail.example.com ESMTP Postfix (Debian/GNU) # Step 3: Client identifies itself with EHLO EHLO sender.example.org # Server responds with capabilities — note STARTTLS in the list 250-mail.example.com 250-PIPELINING 250-SIZE 26214400 250-VRFY 250-ETRN 250-STARTTLS ← TLS upgrade is available 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 SMTPUTF8 # Step 4: Client requests TLS upgrade STARTTLS # Server agrees 220 2.0.0 Ready to start TLS # Step 5: TLS handshake happens here — certificate exchange, # cipher suite negotiation, key derivation. After this point # everything is encrypted with the negotiated TLS session. # Step 6: Client sends FRESH EHLO over the now-encrypted channel # (RFC 3207 §4.2 requires this — server may advertise different # extensions over TLS, e.g. AUTH PLAIN) EHLO sender.example.org 250-mail.example.com 250-PIPELINING 250-SIZE 26214400 250-VRFY 250-ETRN 250-AUTH PLAIN LOGIN ← AUTH only advertised after TLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 SMTPUTF8 # All subsequent SMTP traffic flows encrypted: # MAIL FROM, RCPT TO, DATA, message body, QUIT
Notice the plaintext window between the initial TCP connection and the TLS handshake completion. Steps 1-4 happen in cleartext on the wire. This is the structural vulnerability — anything an attacker can do during that window can sabotage the upgrade.
Opportunistic vs Mandatory TLS
STARTTLS supports two distinct security postures, configured at the sending side. The choice has direct security implications:
Opportunistic TLS
Default for inbound port 25. Try STARTTLS if both sides support it; fall back to plaintext if not advertised, fails to negotiate, or certificate is invalid.
- RFC-compliant for publicly-referenced port 25 servers
- Maximizes deliverability — never blocks mail due to TLS issues
- Vulnerable to STRIPTLS downgrade attack
- Required for inbound (RFC 3207 forbids mandatory TLS on public port 25)
Mandatory TLS
Refuse the connection if TLS can't be established. No plaintext fallback under any circumstances. Use on submission ports 587/465 — NOT on inbound port 25.
- Eliminates STRIPTLS as an attack vector
- Required for client submission with credentials
- Blocks legitimate mail if recipient TLS is broken
- RFC 3207 explicitly forbids on public-facing port 25
The asymmetry is structural: inbound port 25 must remain opportunistic (you can't refuse incoming mail just because the sender can't TLS — you'd cut yourself off from senders running old MTAs); outbound submission on ports 587/465 should be mandatory (your authenticated users sending through your infrastructure should never bypass TLS, and refusing the connection is acceptable because the user controls both endpoints).
This asymmetry is exactly the operational gap that MTA-STS and DANE close: they let the receiving domain publish a policy (MTA-STS) or DNSSEC-anchored fingerprint (DANE) that tells sending MTAs "for this domain, escalate to mandatory TLS" — turning what would otherwise be opportunistic port 25 into authenticated mandatory TLS without requiring every MTA on the internet to change its default.
The STRIPTLS downgrade attack
STRIPTLS is the canonical attack against opportunistic STARTTLS. Documented at scale since 2014 with EFF reporting ISP-level interceptions and Cisco IOS / Sandvine middleboxes performing it in production. The mechanics:
STRIPTLS attack: how STARTTLS gets stripped on the wire
220 banner. Sender sends EHLO sender.example.com. All plaintext. Attacker sees the EHLO.250 response listing capabilities including 250-STARTTLS. Attacker rewrites this response — strips the 250-STARTTLS line in transit. Sender receives a modified response with no STARTTLS advertisement.The four SMTP ports and when to use each
STARTTLS interacts with SMTP's port architecture in specific ways. The current 2026 state of the four ports operators encounter:
| Port | RFC / Purpose | TLS model | Use case | Verdict |
|---|---|---|---|---|
| 25 | RFC 5321 — server-to-server SMTP relay | STARTTLS opportunistic. Mandatory TLS forbidden by RFC 3207 for public-facing servers. | Receiving mail from other MTAs. Blocked outbound by most ISPs to prevent spam. | REQUIRED for inbound MTA |
| 465 | RFC 8314 (Jan 2018) — Implicit TLS submission | Implicit TLS. Connection encrypted from the first byte. | Modern client/application submission. Recommended by RFC 8314 for new deployments. | RECOMMENDED 2026 |
| 587 | RFC 6409 — STARTTLS submission | STARTTLS, typically with mandatory TLS via smtpd_tls_security_level=encrypt. |
Universal client/application submission. Most widely supported across MUAs and ESPs. | UNIVERSAL DEFAULT |
| 2525 | No RFC — IANA assigned to "Simple Mail Transfer" | STARTTLS, configured identically to port 587 in most deployments. | Fallback when 587 is blocked (corporate firewalls, restrictive cloud policies). | UNOFFICIAL FALLBACK |
Postfix STARTTLS configuration
Postfix's TLS configuration spans main.cf for global parameters and master.cf for per-port configuration overrides. The production pattern:
# /etc/postfix/main.cf — global TLS parameters # Server certificate (used for inbound and outbound TLS) smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem # Inbound port 25 — opportunistic TLS (RFC 3207 compliant) smtpd_tls_security_level = may smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_database = btree:$data_directory/smtpd_scache smtpd_tls_session_cache_timeout = 3600s # TLS protocols and ciphers — disable old/weak protocols smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_ciphers = high smtpd_tls_mandatory_ciphers = high smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, 3DES, RC4, MD5, PSK, SRP, KRB5, IDEA, SEED # Outbound TLS — opportunistic by default, can be tightened per-destination smtp_tls_security_level = may smtp_tls_loglevel = 1 smtp_tls_session_cache_database = btree:$data_directory/smtp_scache smtp_tls_policy_maps = hash:/etc/postfix/tls_policy # Enable DANE for outbound TLS (DNSSEC required) smtp_dns_support_level = dnssec smtp_tls_security_level = dane # Use DANE where TLSA records exist, else opportunistic
# /etc/postfix/master.cf — per-service overrides # Port 25 — server-to-server inbound (opportunistic, RFC compliant) smtp inet n - y - - smtpd # Port 587 — submission with STARTTLS (mandatory TLS for clients) submission inet n - y - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt # Mandatory TLS -o smtpd_sasl_auth_enable=yes # SMTP AUTH required -o smtpd_tls_auth_only=yes # AUTH only after TLS -o smtpd_relay_restrictions=permit_sasl_authenticated,reject -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject # Port 465 — submissions with Implicit TLS (RFC 8314) submissions inet n - y - - smtpd -o syslog_name=postfix/submissions -o smtpd_tls_wrappermode=yes # Implicit TLS, no STARTTLS -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
And per-destination outbound TLS policy in /etc/postfix/tls_policy:
# /etc/postfix/tls_policy — per-destination outbound TLS # Format: destination [TAB] policy [whitespace] options example.com encrypt # Mandatory TLS to this domain [mail.partner.com]:587 encrypt protocols=>=TLSv1.2 # With protocol floor secure-supplier.com verify # TLS + certificate verification * may # Default opportunistic # Then: postmap /etc/postfix/tls_policy # And reload: postfix reload
Testing STARTTLS in production
Three primary tools for verifying STARTTLS configuration. Use these in order from low-level to high-level:
openssl s_client
Performs the STARTTLS handshake and drops you into an interactive SMTP session over TLS. Verifies certificate validity, expiration, SAN/CN coverage, cipher negotiation. openssl s_client -connect mail.example.com:25 -starttls smtp -crlf
swaks
Higher-level, full-delivery testing with verbose output. swaks --to test@example.com --server mail.example.com:587 --tls performs full STARTTLS-encrypted SMTP delivery showing every command and response.
SSL Labs / Hardenize / CheckTLS
Web-based probes that test TLS configuration, certificate validity, MTA-STS deployment, DANE TLSA records. ssllabs.com, hardenize.com, checktls.com all probe public-facing SMTP servers.
TLS-RPT aggregate reports
Daily reports from receivers showing TLS handshake outcomes from real senders. Failure types like starttls-not-supported indicate downgrade attacks or misconfigured servers; certificate-expired indicates expired certs. See TLS-RPT entry.
Production debugging usually starts with openssl s_client to verify the basic handshake works, then moves to TLS-RPT aggregate data to identify which destinations are failing in real traffic. The swaks tool is best for end-to-end delivery validation when you control both sender and receiver.
How MTA-STS and DANE close the STARTTLS gap
RFC 3207's structural weakness — opportunistic TLS on port 25 with no way to refuse plaintext fallback — is exactly what MTA-STS and DANE were designed to fix. Two complementary approaches:
MTA-STS (RFC 8461)
Receiving domain publishes an HTTPS policy file at https://mta-sts.example.com/.well-known/mta-sts.txt listing allowed MX hosts and policy mode. Sending MTAs fetch and cache the policy, then refuse plaintext fallback for that domain.
DANE (RFC 7672)
Receiving domain publishes a TLSA DNS record at _25._tcp.mx.example.com containing the certificate fingerprint. The DNS record is DNSSEC-signed. Sending MTAs verify the certificate matches the published fingerprint.
TLS-RPT (RFC 8460)
Receiving domain publishes _smtp._tls TXT record with reporting URI. Senders submit daily JSON aggregate reports of TLS handshake outcomes, including STARTTLS failures categorized by type.
Combined deployment: MTA-STS at minimum (easy, broad adoption); DANE if DNSSEC is feasible (stronger, less dependent on CAs); TLS-RPT always (visibility into what's actually happening). The combination converts STARTTLS from "opportunistic with structural weaknesses" into "authenticated mandatory TLS with operational visibility" — without changing STARTTLS itself.
STARTTLS in Cloud Server for Email infrastructure
Our managed email infrastructure uses STARTTLS as the foundational TLS mechanism, hardened by the cluster of overlay protocols:
- Outbound delivery infrastructure (PowerMTA, KumoMTA, Postfix) configured with
smtp_tls_security_level=danefor DANE-where-available and opportunistic STARTTLS as fallback. Per-destination policy overrides for known domains viatls_policymaps. Connection caching enabled to amortize TLS handshake overhead at scale. - Inbound submission infrastructure on ports 587 and 465 with mandatory TLS (
smtpd_tls_security_level=encrypt), SASL AUTH required, AUTH-only-after-TLS to prevent credential exposure. TLS 1.2 minimum, weak ciphers excluded. - Inbound port 25 servers running opportunistic STARTTLS (RFC 3207 compliant) with MTA-STS policies published for customer domains where applicable, DANE TLSA records where DNSSEC is deployed, and TLS-RPT aggregating daily handshake data into customer reporting dashboards.
- Certificate management automation via Let's Encrypt or commercial CA depending on customer compliance requirements. Automated renewal with zero-downtime certificate replacement, monitoring for expiration ≥30 days out.
- STRIPTLS detection via TLS-RPT aggregate analysis — monitoring for sudden spikes in
starttls-not-supportedfailure category for destinations that historically supported TLS, which is the signal that an intermediate network is performing STARTTLS stripping. - Postfix tuning for high-volume deployments: TLS session caching reduces handshake overhead by ~40% on connection-heavy workloads, smtp_tls_session_cache_database tuned for high IOPS, smtp_connection_cache_on_demand enabled for backlog destinations.
For most customers, STARTTLS configuration is invisible infrastructure that just works. The complexity surfaces during edge cases: STRIPTLS incidents on routes through specific networks, certificate renewals that fail due to ACME validation issues, ciphersuite negotiation failures with old peer MTAs, and DANE rollover coordination. Our managed infrastructure handles these as part of standard operations.
Related glossary concepts
- SMTP — the underlying protocol that STARTTLS extends. STARTTLS is an SMTP service extension, not a separate protocol.
- MTA-STS — policy layer that closes STARTTLS's opportunistic gap by signaling "TLS is required" via HTTPS policy.
- DANE — DNSSEC-anchored TLS authentication that closes STARTTLS's certificate-validation gap by binding fingerprints to DNS.
- TLS-RPT — reporting layer for STARTTLS outcomes; daily aggregate reports of handshake failures including STRIPTLS evidence.
- SPF, DKIM, DMARC — content-layer authentication that complements STARTTLS's transport-layer encryption.
- Postfix — the most common MTA for deploying STARTTLS configurations; this entry's syntax examples are Postfix.
- PowerMTA, KumoMTA — commercial and open-source high-volume MTAs with their own STARTTLS configuration syntax.
Frequently asked questions
Is STARTTLS the same as SMTPS?
No — they're different mechanisms for putting TLS on SMTP. STARTTLS is an in-band upgrade: connection starts plaintext, client sends STARTTLS command, server agrees, TLS handshake happens mid-session. SMTPS (Secure SMTP) is implicit TLS: connection starts encrypted from the first byte on a dedicated port, no STARTTLS command, no plaintext window. Historical context: SMTPS was originally assigned port 465 in 1996, deprecated in 2002, then restored by RFC 8314 in 2018 as "submissions" (with the 's'). The terminology gets confusing because "SMTPS on port 465" had a 16-year period where it was officially deprecated but still widely used in practice. In 2026, "SMTPS" usually refers to RFC 8314's restored port 465 (Implicit TLS submissions), and STARTTLS refers to the in-band upgrade on ports 25 and 587.
Can I use STARTTLS without a valid TLS certificate?
Technically yes for opportunistic mode, structurally problematic. RFC 3207 §4.1 says clients SHOULD verify server certificates, but doesn't mandate it — and most server-to-server SMTP traffic on port 25 doesn't enforce certificate verification because requiring it would block delivery to a substantial portion of mail servers running with self-signed or expired certificates. Postfix's default smtpd_tls_security_level=may explicitly accepts any certificate. So self-signed certificates work for opportunistic STARTTLS — encryption is provided, but authentication is weak (the connection is encrypted to whoever holds the private key for the presented certificate). For mandatory TLS on submission ports (587/465) with client authentication, certificate validity matters more because clients refuse to send credentials without it. For DANE/MTA-STS-protected destinations, certificate validity is mandatory by definition. Best practice 2026: use Let's Encrypt or commercial CA-issued certificates for all SMTP TLS deployment, both inbound and outbound, regardless of opportunistic vs mandatory mode.
Does STARTTLS protect against the recipient reading my email?
No — STARTTLS protects email in transit between mail servers, not at rest. Once the message arrives at the recipient's mail server, it's stored unencrypted (or encrypted with the recipient's storage encryption, which the recipient's provider controls and can decrypt). The recipient can read the message. This is fundamental to how email works — the recipient is the intended receiver. STARTTLS specifically addresses the "anyone in the network path between sender and receiver" threat model: ISPs, network operators, BGP-hijacking attackers, ISP middleboxes. It does NOT address: the recipient's mail provider reading the message, the recipient themselves, government subpoenas to the recipient's provider, or after-delivery storage compromise. For end-to-end encryption (only sender and receiver can read), use S/MIME or PGP — separate technologies that encrypt the message body itself, not just the transport. STARTTLS is necessary but not sufficient for confidentiality.
What TLS version should I require for SMTP?
TLS 1.2 minimum for production in 2026, TLS 1.3 preferred where supported. Disable TLS 1.0 and TLS 1.1 — they have known cryptographic weaknesses (BEAST, Lucky Thirteen) and are formally deprecated. Disable SSLv2 and SSLv3 — POODLE attack on SSLv3 made it dead in 2014. TLS 1.2 was published in 2008, has 17+ years of stable deployment, and supports modern cipher suites (AEAD with AES-GCM or ChaCha20-Poly1305) plus forward secrecy. TLS 1.3 (2018) provides faster handshakes (1-RTT or 0-RTT for resumed sessions), simpler cipher negotiation, and removes legacy primitives. Postfix configuration: smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 and smtpd_tls_mandatory_protocols with the same value. The negation syntax is Postfix-specific. Modern peer MTAs almost universally support TLS 1.2; some embedded systems and very old MTAs may still negotiate down to TLS 1.0 — accept the failure rather than support broken cryptography.
How does Gmail's "red open lock" indicator work?
Gmail's UI shows a red open-lock icon on messages that arrived without TLS encryption. The mechanism: when Gmail receives a message via SMTP, it records whether the inbound connection used TLS or plaintext. If plaintext, the message metadata is flagged. The Gmail UI uses this flag to display the red open-lock icon, signaling to the recipient that the message was not encrypted in transit. This is informational, not a deliverability action — Gmail still delivers the message to the inbox. For senders, this means: if you don't deploy STARTTLS at all, your recipients will see the red open-lock icon next to your messages, which looks unprofessional and reduces trust. The fix is operationally trivial in 2026 (Postfix or any modern MTA supports STARTTLS with a few configuration lines and a Let's Encrypt certificate). Other providers have similar indicators — Yahoo, Microsoft 365, Apple Mail all display some form of unencrypted-mail warning in their UI. The indicator is a useful signal that your sending infrastructure has a basic configuration gap.
Should I deploy MTA-STS, DANE, or both?
Both if feasible; MTA-STS at minimum. They're complementary, not redundant. MTA-STS is easier to deploy (no DNSSEC required, just HTTPS hosting and DNS TXT records) and has broad adoption (Gmail, Microsoft, Yahoo all enforce it for major domains). DANE is structurally stronger (DNSSEC-anchored, no CA dependency) but requires DNSSEC on the receiving zone — which most domains don't have. The deployment pattern: start with MTA-STS for breadth (covers 90%+ of use cases), add DANE if you have DNSSEC infrastructure (stronger guarantees, ~30 domains globally per DMARCguard's February 2026 scan of 5.5 million). Either alone is far better than STARTTLS-only. Both is the gold standard. Pair with TLS-RPT for visibility — the daily aggregate reports tell you whether your STARTTLS, MTA-STS, and DANE configurations are actually working in real traffic.
What's STARTTLS Everywhere and is it still a thing?
STARTTLS Everywhere was an EFF-led initiative (2018-2021) that maintained a curated policy list of mail servers committed to TLS. The idea: published policy means senders can refuse plaintext fallback to listed domains. The project was effectively superseded by MTA-STS (RFC 8461, 2018) which standardizes the same concept via per-domain HTTPS policy files instead of a centralized list. EFF wound down active STARTTLS Everywhere development in 2021, redirecting effort to MTA-STS adoption. Historical relevance: it demonstrated demand for STARTTLS hardening before MTA-STS was widely deployed and seeded operational expertise that fed into the MTA-STS standardization process. In 2026, MTA-STS is the answer; STARTTLS Everywhere as a project is archived but conceptually subsumed.
Last updated: May 2026 · Sources: RFC 3207 (IETF Datatracker), RFC 8314, Postfix TLS_README, APNIC: SMTP downgrade attacks, EFF STARTTLS Everywhere historical reports, Google Transparency Report email encryption metrics, smtp-pentesting.popdocs.net STRIPTLS analysis.