TL;DR: STRIPTLS attacks exploit opportunistic SMTP encryption by forcing mail flow to fall back to cleartext when STARTTLS is missing, misconfigured, or not validated properly. DigiCert cites research showing 82% of 700,000 Alexa Top Million SMTP servers encrypt traffic, but only 35% of those configure authentication correctly. That gap keeps email privacy and credential protection fragile.
NHIMG editorial — based on content published by DigiCert: STRIPTLS Attacks and Email Security
By the numbers:
- 82% of the 700,000 Alexa Top Million SMTP servers actually encrypt traffic.
- Only 35% have configured encryption protocols correctly for server authentication.
- 1% of organisations lack full visibility into third-party vendors connected via OAuth apps.
Questions worth separating out
Q: What breaks when SMTP relies on opportunistic encryption?
A: SMTP confidentiality breaks when the transport can be downgraded to cleartext or when certificate validation is weak.
Q: Why do email credentials remain exposed even when STARTTLS is enabled?
A: STARTTLS only protects the session if the handshake completes and the server validates the peer correctly.
Q: How can security teams tell whether SMTP encryption is actually working?
A: Teams should test whether mail servers fail closed when TLS negotiation fails, confirm certificate validation across all relays, and inspect whether any path still permits plaintext delivery.
Practitioner guidance
- Enforce fail-closed SMTP negotiation Configure mail paths so STARTTLS failure blocks delivery rather than silently downgrading to cleartext.
- Verify certificate validation on every SMTP hop Check that servers validate certificates consistently, not just that TLS is advertised.
- Separate transport security from content protection Use message-level encryption for sensitive communication so confidentiality survives if the transport path is intercepted or downgraded.
What's in the full article
DigiCert's full blog post covers the protocol detail this post intentionally leaves for the source:
- How STARTTLS negotiation works at the SMTP command level and where downgrade behaviour appears
- The specific example of STRIPTLS attacks against Google and Yahoo servers in Thailand
- Why opportunistic encryption fails when certificate validation is absent or misconfigured
- How S/MIME certificates change the confidentiality boundary for sensitive email
👉 Read DigiCert's analysis of STRIPTLS attacks and SMTP email security →
STRIPTLS and SMTP security: are your email controls enough?
Explore further
Opportunistic encryption is a trust assumption, not a control. STARTTLS only protects SMTP when both sides negotiate correctly and certificate validation works as intended. That means the security outcome depends on cooperative behaviour from every server in the path, which is exactly what attackers exploit in downgrade attacks. Practitioners should read this as a boundary problem, not a protocol problem.
A few things that frame the scale:
- 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, followed by 37% citing inadequate monitoring and logging and 37% citing over-privileged accounts.
A question worth separating out:
Q: Who is accountable when email is downgraded and messages are exposed?
A: Accountability sits with the organisation operating the mail path, because transport security depends on its configuration choices and validation practices. If third-party relays are involved, ownership must still be assigned across procurement, security, and messaging teams. Controls like S/MIME, certificate governance, and fail-closed policies need a named owner.
👉 Read our full editorial: STRIPTLS attacks expose the limits of opportunistic SMTP encryption