Suped

Which email service providers do not support TLS?

Matthew Whittaker profile picture
Matthew Whittaker
Co-founder & CTO, Suped
Published 23 Jul 2025
Updated 17 Aug 2025
9 min read
Email security is a constantly evolving landscape, and Transport Layer Security (TLS) plays a critical role in encrypting email traffic during transit. Ideally, all email communications would be secured with the latest TLS versions, ensuring that messages remain private and untampered with as they travel across networks. However, the reality is that not every email service provider (ESP) or recipient domain fully supports modern TLS, or even TLS at all.
When an email is sent to a domain that doesn't support TLS, or only supports outdated versions, the message might be sent unencrypted. This can expose sensitive information to interception, affecting data privacy and potentially leading to deliverability issues. Understanding which providers still lack full TLS support is crucial for anyone managing email communications, especially for bulk senders where security and deliverability are paramount.

The diminishing landscape of non-TLS support

The vast majority of major email service providers and mailbox providers (MBPs) now support TLS encryption. Companies like google.com logoGoogle and microsoft.com logoMicrosoft have been at the forefront of pushing for ubiquitous TLS adoption, with many now mandating TLS 1.2 or higher for incoming connections. This means that if you're sending emails to popular services such as Gmail, Outlook, or yahoo.com logoYahoo Mail, your messages are almost certainly being transported via an encrypted connection.
However, pockets of non-compliance still exist, particularly among smaller, older, or less actively maintained mail servers. These might include legacy systems, internal corporate mail servers, or some older regional internet service providers (ISPs) that have not updated their infrastructure to meet modern security standards. Identifying these specific providers can be challenging because there isn't a single, regularly updated public list of all domains that do not support TLS.
Some domains, such as tiscali.it, have historically been cited as not supporting TLS, or only supporting very old, vulnerable versions. Similarly, some forums mention specific legacy domains like btinternet.com as having issues. These tend to be isolated cases rather than widespread trends among major providers. The general trend is towards stronger encryption, not weaker.
While most modern email providers and their guidelines strictly enforce TLS 1.2 or higher, there are still instances where older systems might default to less secure protocols or even clear-text. This means that even if your mail server is configured for robust TLS, the connection might downgrade to a weaker protocol or no encryption at all if the recipient's server does not support it, a scenario known as opportunistic TLS. This is why outbound TLS is important for email marketing.

Identifying non-TLS email providers

Pinpointing email service providers that completely lack TLS support requires active checking. One of the most effective ways is to use online tools designed for this purpose. The Google Transparency Report provides a broad overview of TLS adoption rates across various domains, offering insights into which domains are more or less likely to receive encrypted mail. While it doesn't give a definitive list of non-TLS domains, it highlights general trends and potential areas of concern.
For more specific testing, tools like CheckTLS allow you to test individual recipient domains to see their TLS support. This is particularly useful if you need to confirm encryption capabilities for a specific client or partner. Running a test to a domain like tiscali.it, as previously mentioned, might yield a result indicating no TLS support or an inability to establish a secure connection.
The information provided by these tools can help you understand the security posture of your email recipients and identify any potential weak points in your email delivery chain. Knowing where your emails might be sent unencrypted allows you to take proactive steps, such as establishing alternative communication methods for sensitive information or adjusting your sending practices. Checking how inbound TLS affects deliverability is a good first step.

Implications for email deliverability

The implications of sending email to providers that do not support TLS are significant for both security and email deliverability. Unencrypted email traffic can be intercepted and read by malicious actors, compromising the privacy of your communications. This is a major security vulnerability, especially if you're sending confidential business information or personal data.
From a deliverability perspective, major mailbox providers are increasingly prioritizing security as a ranking factor for inbox placement. Sending emails unencrypted, even opportunistically, can negatively impact your sender reputation. If a recipient server is known for not supporting TLS, or for relying on outdated versions, your emails might be flagged as less secure, increasing the likelihood of them landing in the spam folder or even being rejected outright. This can lead to a drop in your overall deliverability rates, which can seriously impact your email marketing efforts. You can learn more about this in how TLS impacts deliverability.
Furthermore, being associated with unencrypted email traffic can indirectly lead to your sending IPs or domains being added to email blocklists (or blacklists). Many blocklists track malicious activity, and a lack of encryption can be a red flag, even if you are not directly engaged in malicious sending. It's a risk that no sender should take, especially given the increased scrutiny from mailbox providers regarding email security. Being placed on a blacklist (or blocklist) can severely impede your ability to reach inboxes.
The risk of sporadic TLS encryption rates also highlights the difference between opportunistic TLS and forced TLS. With opportunistic TLS, your mail server will attempt to use encryption but will fall back to an unencrypted connection if the recipient server doesn't support it. Forced TLS, on the other hand, means the email will not be sent at all if a secure connection cannot be established, providing stronger security but potentially leading to undelivered mail. This distinction is critical for senders balancing security with guaranteed delivery.

Best practices for secure email sending

Given the declining number of email service providers that do not support TLS (or only outdated versions), the best practice is to always aim for the highest possible level of encryption. Configuring your mail server to use modern TLS versions, specifically TLS 1.2 or 1.3, should be a standard practice. Many major providers, including apple.com logoApple, have deprecated support for older TLS versions, meaning connections using TLS 1.0 or 1.1 will be rejected.
You should regularly monitor your TLS encryption rates through tools like Google Postmaster Tools. If you observe a drop in your TLS encryption percentage, it could indicate an issue with your mail server configuration or that you're sending to a significant number of domains that do not support modern TLS. This proactive monitoring helps identify potential problems before they escalate into major deliverability or security incidents.
Finally, ensure your email authentication protocols (SPF, DKIM, and DMARC) are correctly set up. While these don't directly handle TLS encryption, they work in tandem to establish sender trustworthiness. A strong authentication setup, combined with consistent TLS usage, paints a clear picture to recipient servers that your emails are legitimate and secure, reducing the chances of them being flagged as suspicious or ending up on a blacklist (or blocklist). You can verify your DMARC settings and policies via a DMARC record generator if you are unsure.

Securing your email communications

While most email service providers today support TLS encryption, a small number of older or less maintained systems may still not. This poses a risk to email security and can negatively impact deliverability. Proactive identification of such domains through testing tools and continuous monitoring of TLS encryption rates are essential practices for maintaining a strong sender reputation and ensuring your emails reach their intended recipients securely. Prioritizing modern TLS configurations and robust email authentication will help mitigate these risks and contribute to overall email ecosystem security.

Views from the trenches

Best practices
Always configure your mail server to prioritize the latest TLS versions, such as TLS 1.2 or 1.3, to ensure the strongest possible encryption for your email traffic.
Regularly monitor your email encryption rates using transparency reports and dedicated TLS checking tools to identify any dips or issues with secure delivery.
Implement a DMARC policy that instructs recipient servers how to handle emails that fail authentication, ensuring better control over your domain's security.
For extremely sensitive communications, consider using end-to-end encryption or secure file transfer methods instead of relying solely on opportunistic TLS.
Common pitfalls
Assuming all recipient mail servers support TLS 1.2 or higher, leading to unencrypted deliveries to older systems.
Not monitoring TLS encryption rates, which can hide underlying deliverability or security issues.
Ignoring DMARC reports, missing critical insights into email authentication failures and potential unencrypted transmissions.
Overlooking legacy email addresses in your lists that might belong to domains with poor or no TLS support, impacting overall security.
Expert tips
Consider configuring your mail server to enforce TLS for all outgoing mail, even if it means some emails might bounce if the recipient server doesn't support encryption.
Educate your team on the importance of TLS and secure email practices to foster a security-first mindset.
Keep your mail server software updated to ensure it supports the latest security protocols and patches.
When integrating with third-party services, always verify their email security practices, including TLS support, before relying on them for sending.
Expert view
Expert from Email Geeks says that CheckTLS is a reliable tool to verify if a recipient's mail server supports TLS, which is useful for testing forced TLS configurations.
2024-12-06 - Email Geeks
Expert view
Expert from Email Geeks says that the Google Transparency Report provides valuable insights into global TLS adoption rates, helping to understand where encryption is less common.
2024-12-06 - Email Geeks

Frequently asked questions

DMARC monitoring

Start monitoring your DMARC reports today

Suped DMARC platform dashboard

What you'll get with Suped

Real-time DMARC report monitoring and analysis
Automated alerts for authentication failures
Clear recommendations to improve email deliverability
Protection against phishing and domain spoofing