Opportunistic TLS
What is Opportunistic TLS?
Opportunistic TLSAn encryption posture in which two parties use TLS when both support it and fall back to plaintext otherwise, typical of SMTP between mail servers using STARTTLS without strong authentication.
Opportunistic TLS is the default behavior of SMTP STARTTLS (RFC 3207) and similar protocols where TLS is preferred but not mandatory. If the peer does not advertise TLS, certificate validation fails, or the handshake errors out, the sender silently retries in cleartext to preserve delivery. This protects against passive eavesdropping but not active attackers, who can strip the STARTTLS announcement, present untrusted certificates, or downgrade ciphers. To harden opportunistic TLS, operators deploy MTA-STS (RFC 8461) for policy-based enforcement, DANE/TLSA (RFC 7672) for DNSSEC-anchored authentication, SMTP TLS Reporting (RFC 8460) for visibility, and TLS 1.2/1.3 with strong cipher suites.
● Examples
- 01
An outbound MTA encrypts mail to a partner domain when STARTTLS works but falls back to plaintext if the handshake fails.
- 02
Postfix configured with smtp_tls_security_level=may, illustrating the default opportunistic posture.
● Frequently asked questions
What is Opportunistic TLS?
An encryption posture in which two parties use TLS when both support it and fall back to plaintext otherwise, typical of SMTP between mail servers using STARTTLS without strong authentication. It belongs to the Network Security category of cybersecurity.
What does Opportunistic TLS mean?
An encryption posture in which two parties use TLS when both support it and fall back to plaintext otherwise, typical of SMTP between mail servers using STARTTLS without strong authentication.
How does Opportunistic TLS work?
Opportunistic TLS is the default behavior of SMTP STARTTLS (RFC 3207) and similar protocols where TLS is preferred but not mandatory. If the peer does not advertise TLS, certificate validation fails, or the handshake errors out, the sender silently retries in cleartext to preserve delivery. This protects against passive eavesdropping but not active attackers, who can strip the STARTTLS announcement, present untrusted certificates, or downgrade ciphers. To harden opportunistic TLS, operators deploy MTA-STS (RFC 8461) for policy-based enforcement, DANE/TLSA (RFC 7672) for DNSSEC-anchored authentication, SMTP TLS Reporting (RFC 8460) for visibility, and TLS 1.2/1.3 with strong cipher suites.
How do you defend against Opportunistic TLS?
Defences for Opportunistic TLS typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Opportunistic TLS?
Common alternative names include: Opportunistic Encryption, Best-Effort TLS.
● Related terms
- network-security№ 1098
STARTTLS
An SMTP, IMAP, POP3, and XMPP extension defined in RFC 3207 that upgrades a plaintext connection to TLS after the protocol greeting, enabling opportunistic encryption between mail servers and clients.
- network-security№ 707
MTA-STS
An email security mechanism defined in RFC 8461 that lets a domain require TLS for inbound SMTP and pin a list of trusted MX hostnames, defeating downgrade and STARTTLS-stripping attacks.
- network-security№ 270
DANE
A protocol family defined in RFC 6698 that uses DNSSEC-signed TLSA records to bind TLS server certificates or public keys to a service, removing reliance on the public CA system.
- network-security№ 1159
TLS (Transport Layer Security)
The IETF-standardized cryptographic protocol that provides confidentiality, integrity, and authentication for traffic between two networked applications.
- network-security№ 984
Secure Email Gateway
A perimeter or cloud service that filters inbound and outbound email for spam, phishing, malware, data leakage, and policy violations before it reaches user mailboxes.
- network-security№ 1091
SSL Stripping
A man-in-the-middle attack that silently downgrades a victim's HTTPS connection to plain HTTP so the attacker can read and modify the traffic.