Summary
The vast majority of modern email service providers (ESPs) and mailbox providers (MBPs) today support Transport Layer Security (TLS), an essential encryption protocol for securing email communication. However, a lingering question for email marketers and system administrators is whether any significant providers still do not support TLS, particularly older versions, which can impact deliverability and data privacy. While most major players enforce modern TLS (like 1.2 or 1.3) or have deprecated older versions, some legacy systems or smaller, niche providers may still operate without full TLS support, leading to unencrypted email transfers or delivery failures. This page explores common scenarios and insights into email services that may lack TLS support.
Key findings
- Widespread adoption: Most modern email providers, including major ones like Gmail, Outlook, and Yahoo, widely support TLS for email encryption.
- Deprecation of older TLS: Older TLS versions (1.0 and 1.1) were largely deprecated in 2020 and are no longer used by most leading ESPs, with TLS 1.2 and 1.3 being the current standards.
- Legacy systems: Some legacy email services or smaller, regional providers may still lack support for modern TLS or even any TLS at all, leading to unencrypted email delivery or bounces when forced TLS is enabled. An example identified in discussions is tiscali.it.
- Transparency reports: Resources like the Google Transparency Report offer insights into the percentage of emails encrypted by TLS for various domains.
- Impact on deliverability: If a sender configures their mail server to strictly enforce TLS, emails sent to recipients without TLS support will fail to deliver, resulting in bounces. This is critical for outbound TLS for email marketing.
Key considerations
- Security implications: Sending emails to providers without TLS means the communication will be unencrypted and vulnerable to eavesdropping, posing a significant privacy and security risk.
- Deliverability challenges: Forcing TLS (mandatory TLS) is a good security practice, but it will lead to failed deliveries for recipients on non-TLS supporting servers. This needs to be considered when configuring TLS on sending domains.
- Identifying non-compliant domains: It can be challenging to identify specific email domains that do not support TLS without comprehensive testing. Tools like CheckTLS can assist in this process.
- Adapting to new standards: As security standards evolve, email senders must regularly review their configurations to ensure compliance with modern TLS requirements to maintain optimal email deliverability.
What email marketers say
Email marketers and administrators frequently grapple with the practical implications of TLS support, especially when implementing policies like forced TLS for outgoing mail. Their primary concern is often how to reliably identify email service providers that might not support TLS, leading to message bounces or unencrypted delivery. Marketers seek efficient ways to test these scenarios and ensure their mail flows are as secure as possible, balancing security needs with deliverability expectations. They often share specific instances of domains that have presented TLS challenges.
Key opinions
- Testing for bounces: Marketers actively seek ways to test their mail servers' forced TLS settings by sending to recipients known not to support TLS, aiming to trigger a bounce and confirm behavior.
- Identifying legacy domains: Specific older domains, like @btopenworld.com, or certain government mail systems have been noted for not supporting TLS.
- Tool reliance: Tools that can test receiver TLS support are highly valued for diagnosing potential issues before widespread deployment.
- Evolving standards: Many discussions revolve around the shift from TLS 1.0/1.1 to 1.2/1.3, highlighting the need for systems to keep pace with these changes.
Key considerations
- Unintended delivery failures: Enforcing strict TLS can lead to unexpected email delivery failures if recipients are on non-compliant systems, impacting email deliverability.
- Understanding bounce codes: Interpreting bounce messages, such as 'STARTTLS is not available,' is crucial for troubleshooting deliverability problems related to TLS.
- Gmail's opportunistic TLS: Marketers note that Gmail will still deliver messages even if the receiving server doesn't use TLS, but the connection will not be secure, affecting TLS encrypted email traffic.
- Maintaining security: The push for TLS 1.2 and newer versions by major providers means older systems must be updated or email exchanges will occur over insecure channels.
Marketer view
Marketer from Email Geeks shares their experience by stating they were trying to force a bounce on their mail server by sending to a recipient without TLS.
Marketer view
Marketer from EduGeek.net recalls that @btopenworld.com, an older domain, did not support TLS encryption for email.
What the experts say
Experts in email deliverability and security largely agree that non-TLS supporting email providers are becoming increasingly rare, especially among major global players. They emphasize the security imperative of using TLS and the diminishing tolerance for unencrypted email. While isolated cases of legacy systems or less common services might still exist without modern TLS, the industry trend is strongly towards mandatory encryption. Experts often highlight that a lack of TLS support from a recipient is a significant security vulnerability and can negatively impact sender reputation and message deliverability for those enforcing secure transport.
Key opinions
- Near universal STARTTLS: Many experts cite high percentages (e.g., over 90%) of mail servers supporting STARTTLS, making complete non-support highly unusual for active domains.
- Security priority: The secure transmission of email via TLS is considered a fundamental security practice, reducing the risk of data interception. This affects how TLS inbound affects email deliverability.
- Legacy outlier: While rare, any remaining non-TLS supporting providers are typically older, less maintained systems or those in regions with different digital infrastructure priorities.
- Forced TLS implications: Experts advise that if a sender forces TLS, they must be prepared for delivery failures to any recipient domains that lack the necessary support.
Key considerations
- Data exposure: Sending unencrypted email exposes sensitive information to potential interception by third parties.
- Compliance: Many regulatory frameworks now implicitly or explicitly require encrypted communication, making TLS non-compliance a legal risk.
- Sender reputation impact: Major email providers (MBPs) prioritize security; sending unencrypted emails, if detected, could negatively impact a sender's email domain reputation over time.
- Migration strategies: Organizations with older systems need strategies to migrate to TLS-compliant infrastructure or risk deliverability failures as more MBPs enforce strict TLS.
Expert view
Expert from SpamResource.com emphasizes the broad adoption of STARTTLS, noting that over 90% of mail servers typically support it, making non-support rare.
Expert view
Expert from WordtotheWise.com highlights that modern email ecosystems largely rely on TLS for secure communication, making non-TLS endpoints a significant security risk for senders.
What the documentation says
Official documentation and industry guidelines consistently reinforce the importance of TLS for email security. Major email service providers and security bodies have progressively phased out support for older, less secure TLS versions (like 1.0 and 1.1), urging or mandating the use of TLS 1.2 or newer. This push is driven by the need for stronger encryption and protection against cyber threats. Documentation often clarifies that while unencrypted delivery might still occur in some cases (opportunistic TLS), it comes with significant security trade-offs, making secure transport the preferred and increasingly enforced standard.
Key findings
- Deprecation timelines: TLS versions 1.0 and 1.1 were officially deprecated in 2020, and major providers have subsequently ceased supporting them for email.
- Current standards: TLS 1.3 is the latest protocol, with TLS 1.2 being widely adopted as a minimum requirement for secure email communication by most providers.
- Major provider compliance: Entities like Microsoft, Yahoo, and various national cybersecurity centers (NCSC-UK, NCSC-NL) have disabled or strongly recommend against using older TLS versions.
- Conditional delivery: Some systems, like Gmail, might still deliver messages if TLS is not available at the recipient's end, but the connection will not be secure, highlighting the difference with opportunistic TLS.
Key considerations
- Mandatory updates: Email service providers must ensure their infrastructure supports current TLS versions to avoid deliverability issues and security vulnerabilities, as outlined in the updated Google bulk sender guidelines.
- Security best practices: Adhering to modern TLS protocols is a critical security best practice for all email senders and receivers to protect data in transit.
- Configuration for privacy: Configuring email systems to require TLS ensures that messages are encrypted, preventing clear-text transmission and enhancing privacy.
- Understanding STARTTLS: Documentation often clarifies that STARTTLS allows an unencrypted connection to be upgraded to an encrypted one, but if the upgrade fails, delivery may proceed unencrypted unless strict TLS is enforced. This contrasts with SSL/TLS key size errors.
Technical article
Documentation from Mailgun states that TLS versions 1.0 and 1.1 were deprecated in 2020 and are no longer actively used by the majority of email service providers.
Technical article
Documentation from Mailgun confirms that TLS 1.3 is currently the most up-to-date protocol for establishing secure email connections, reflecting industry standards.
Related resources
10 resources
Related pages
What is TLS encrypted email traffic and what causes a drop in its percentage?
Does using TLS matter for email deliverability or inbox placement?
What are the implications of disabling TLS 1.0/1.1 for outgoing email and what alternatives are available?
What causes SSL/TLS key size errors in email SMTP transactions?
Why is outbound TLS important for email marketing?
How does TLS inbound affect email deliverability and sender confidence?
Should I configure SSL or TLS on my sending domains for email marketing?
What are the updated Google bulk sender guidelines and TLS requirements for email senders?
Boost email deliverability rates: technical solutions from top performing senders
A simple guide to DMARC, SPF, and DKIM
