Which email service providers do not support TLS?
Published 23 Jul 2025
Updated 29 Oct 2026
12 min read
Summarize with
Updated on 29 Oct 2026: We clarified SMTP delivery and submission, corrected mandatory TLS failure handling, and tightened the MX testing steps.
There is no dependable permanent list of email providers that do not support inbound SMTP TLS. Most major consumer mailbox providers support it. The historical results below date to 2019 or 2022 and do not establish current support.
Treat historical results as candidates for testing. TLS support changes at the MX level, and the same brand can use different mail infrastructure for different domains. To test mandatory TLS on your mail server, check every recipient MX immediately before using it and record the delivery log. A failed TLS connection can cause queuing and retries before an eventual bounce, depending on the sender's policy.
- Use a controlled test MX for a repeatable no-TLS result, or live-test a historical candidate first.
- Major consumer mailbox providers such as Gmail and Outlook.com are poor choices for a no-TLS test.
- Check the exact recipient domain and every MX host behind it, including backup servers.
Historical no-TLS candidates and current limits
For a mandatory TLS outbound test, the receiving MX is what matters. A sending platform can support TLS and still fail delivery to a recipient domain whose MX does not advertise STARTTLS.
A public inbound TLS snapshot dated July 8, 2022 warned that its results were not guarantees. A separate 2019 SANS test identified tiscali.it as lacking STARTTLS at that time. First confirm that a candidate domain still accepts email: a retired domain or unreachable MX cannot demonstrate missing STARTTLS. Then test every current MX host.
|
|
|
|---|---|---|
tiscali.it | No STARTTLS in a 2019 test | Historical candidate |
hotmail.ru | Listed as no inbound TLS in July 2022 | Historical candidate |
inbox.com | Listed as no inbound TLS in July 2022 | Historical candidate |
rogers.blackberry.net | Listed as no inbound TLS in July 2022 | Legacy ISP candidate |
rr.com | Listed as no inbound TLS in July 2022 | Legacy ISP candidate |
sprint.blackberry.net | Listed as no inbound TLS in July 2022 | Legacy ISP candidate |
Historical observations only. No current TLS status is established for these domains.
Google Workspace Secure transport TLS settings for certificate validation and connection testing.
Major providers are rarely useful for this test. Google requires senders to use TLS when transmitting mail to personal Gmail accounts. Gmail also tries TLS by default and can enforce Secure transport TLS rules for specified domains through the Gmail TLS setting. Without an applicable mandatory TLS policy, Gmail can still send to a receiving server that does not use TLS. Other major consumer mailbox domains have also supported inbound TLS in public tests. A custom domain still needs its own MX and policy checks.
SMTP delivery and SMTP submission use different ports
A provider that accepts unencrypted SMTP submission from a legacy app does not necessarily lack TLS for incoming mail. These are different connections. RFC 8314 distinguishes SMTP submission using STARTTLS on port 587 from implicit TLS on port 465.
|
|
|
|---|---|---|
Server-to-server SMTP delivery | 25 | The receiving MX advertises STARTTLS and negotiates TLS after the SMTP greeting. |
App-to-server SMTP submission | 587 | The app upgrades to TLS with STARTTLS before authentication and message submission. |
App-to-server SMTP submission with implicit TLS | 465 | The TLS handshake begins immediately, before SMTP commands are exchanged. |
Webmail in a browser | 443 | HTTPS protects the browser connection. It does not prove that server-to-server delivery uses TLS. |
Check the connection that matches the problem. Webmail encryption does not establish MX TLS support.
For a printer or scanner without TLS support, use a restricted internal SMTP relay that accepts only approved devices and requires TLS for onward delivery. Keep the unencrypted device connection inside a trusted network, restrict permitted destinations, and do not expose an open relay. Do not disable TLS across a production mail service to accommodate one device.
Why no-TLS lists age quickly
A no-TLS list ages quickly because SMTP TLS is opportunistic by default and depends on live infrastructure. The sender looks up MX records, connects to a host, reads the SMTP banner, sends EHLO, and checks whether STARTTLS appears in the capability list. If it is missing and the sender requires TLS, that MX cannot accept the message over an encrypted SMTP connection. Test every active MX host and each published IPv4 and IPv6 address, including backup MX hosts.
No STARTTLS
The recipient MX accepts SMTP but never advertises STARTTLS. This is the cleanest negative test for a force-TLS policy.
- A strict sender refuses delivery through that MX before message data is transferred.
- The SMTP capability list has no STARTTLS line.
TLS negotiation or validation failure
The MX advertises STARTTLS, but the sender cannot negotiate an acceptable TLS version or cipher, or cannot validate the certificate and hostname. A certificate error can occur even after encryption has been negotiated.
- A strict sender refuses that connection, then tries another permitted MX or queues the message according to its policy.
- The log identifies a handshake error or certificate validation failure rather than missing STARTTLS.
Keep these outcomes separate. Missing STARTTLS means that particular MX offers no encrypted SMTP path. A certificate validation failure means the sender cannot establish the identity required by its policy. Contact the recipient to correct the certificate or server configuration rather than disabling verification. Another permitted MX can still accept the message if it passes the required checks.
Do not use an old no-TLS list as a production rule source. A domain that failed in 2022 can pass today, and a domain that passes today can fail after an MX change. Test every active MX host when you make the policy decision.
How to test before enforcing TLS
Inspect the recipient domain the same way a sending MTA does. Look up the MX records, test each host on port 25, and confirm whether STARTTLS is advertised. Ports 465 and 587 test SMTP submission, not inbound server-to-server delivery. For your own domain, run Suped's domain health check so DMARC, SPF, DKIM, and mail security issues are visible in one place before you change enforcement behavior.
MX and STARTTLS checksbash
dig +short mx recipient.example openssl s_client -brief -starttls smtp \ -connect mx1.example:25 \ -servername mx1.example \ -verify_hostname mx1.example \ -verify_return_error \ -min_protocol TLSv1.2 < /dev/null
Replace recipient.example with the recipient domain and mx1.example with each returned MX hostname. These commands check the connection without submitting a message. A no-TLS target answers EHLO without offering STARTTLS; if STARTTLS is advertised, inspect the negotiated protocol and certificate result. The -verify_return_error option stops on certificate verification errors, while -min_protocol TLSv1.2 excludes obsolete TLS 1.0 and TLS 1.1. A timeout or a local outbound port 25 restriction does not prove the recipient lacks TLS.
A successful handshake without certificate verification proves encryption to an endpoint, not its identity. Validate both the trusted certificate chain and the MX hostname. When connecting directly to an IP address, retain the MX hostname in -servername and -verify_hostname.
If the source IP matters, run the test through the host or NAT path that actually uses that IP. A public web check tests through its own infrastructure, so it cannot prove that the receiver behaves the same way for your sender network, allowlist, blocklist (blacklist), or firewall path.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For a delivery test, use harmless content and a recipient address under your control. Record whether the sending MTA refuses the connection, queues the message, or generates a non-delivery report. A nonexistent recipient can produce an unrelated address error, so it is not proof that TLS enforcement works.
Illustrative mandatory TLS log entry, not a universal SMTP responsetext
TLS required, but recipient MX did not advertise STARTTLS. Message not transmitted through this MX; delivery deferred.
TLS enforcement readiness
Evaluate all MX hosts that the sender is permitted to use; a single failed host does not establish a domain-wide delivery failure.
Ready
All MX hosts pass
All intended MX hosts support TLS 1.2 or later and pass certificate and applicable MX policy checks.
Repair
Partial failure
A host fails TLS checks, but another permitted MX still provides a valid delivery path. Repair the failed host before it is needed as a backup.
Undeliverable under strict TLS
No valid TLS path
No permitted MX provides a valid TLS path. The sender follows its queuing or rejection policy without sending in cleartext.
Build a controlled no-TLS test target
A controlled negative target is safer and more repeatable than depending on an unrelated public mailbox domain. Use an isolated SMTP listener that answers on port 25 but does not advertise STARTTLS, then route a test-only domain to it through lab DNS or a temporary internal DNS override.
- Create a disposable SMTP listener with STARTTLS disabled and relay access denied.
- Restrict port 25 to the sending MTA addresses used for the test.
- Route only a test domain to the listener, give it no alternate working MX, and confirm EHLO has no STARTTLS capability.
- Send harmless test mail and confirm the strict route defers or rejects before message data is transferred. Check the sender's queue as well as its bounce output.
- Remove the DNS override and shut down the listener after recording the SMTP result.
Keep this listener isolated. Do not expose a relay, reuse a production recipient domain, or leave a deliberately unencrypted SMTP path in service after the test.
What mandatory TLS changes
Without a strict sender rule, an MTA-STS enforce policy, or DNSSEC-validated DANE TLSA records, SMTP delivery generally uses opportunistic TLS. The sender tries encryption but can fall back to cleartext if TLS is unavailable. Mandatory TLS removes that fallback for the traffic covered by the rule. Certificate verification must also be required when the policy needs an authenticated receiving server. An encryption-only rule does not establish server identity.
Enable TLS on every outgoing route. Decide separately which traffic must remain undelivered when the recipient cannot meet mandatory TLS requirements, and define how the sender handles those failures. This is why outbound TLS belongs in delivery planning alongside bounce handling and customer notifications.
A strict TLS policy changes delivery as much as security. Before you enable it, define which traffic must fail closed, who owns exceptions, and how non-delivery reports are routed.
- For partner mail, agree on recipient domains and certificate requirements before enforcing mandatory TLS.
- For bulk mail, test recipient domains and define how delivery failures are handled before applying blanket mandatory TLS.
- For transactional mail, stage mandatory TLS enforcement by domain and monitor queues so essential notices do not fail silently.
A 2019 SANS test found that 90% of the servers checked supported STARTTLS, while several did not and one lacked TLS 1.2. Those results are historical. Use TLS 1.2 or TLS 1.3 for modern connections; RFC 8996 deprecated TLS 1.0 and TLS 1.1. Base enforcement on current mail logs and recipient testing.
TLS protects an individual connection between mail servers. It does not provide end-to-end message encryption or protect messages stored in a mailbox. DMARC evaluates SPF or DKIM authentication; a DMARC pass does not establish that TLS was used.
Where MTA-STS and Suped fit
Mandatory TLS on outbound mail is a sender-side rule. MTA-STS is a recipient-published policy that supporting senders check. In enforce mode, those senders refuse delivery through an MX when STARTTLS is missing, the certificate is invalid, or the MX does not match the policy. A cached enforce policy protects against STARTTLS stripping on subsequent delivery attempts. Suped's hosted MTA-STS workflow simplifies policy hosting with two CNAME records and no separate web hosting.
Hosted MTA-STS/TLS-RPT configuration dialog showing policy mode, MX hosts, CNAME records, TLS reporting, and verification
MTA-STS testing mode lets supporting senders deliver as though a policy validation failure were absent. TLS-RPT is separate. The domain publishes a _smtp._tls TXT record that tells participating senders where to send aggregate TLS reports, normally covering a day of traffic. Publish TLS-RPT before moving MTA-STS to enforce so transport failures are visible during rollout. These are aggregate reports, not real-time delivery alerts.
Under RFC 8461, senders should treat MTA-STS validation failures as temporary and retry delivery. They must check for an updated policy before permanently failing the message. A local mandatory TLS rule can instead reject immediately, so test the actual sender's behavior.
Suped hosts the MTA-STS policy and collects TLS-RPT alongside DMARC reporting. Use those reports to identify failures affecting mail sent to your domain, then investigate the affected MX or policy. They do not show every outbound failure when you send to other domains; use your sending MTA's logs to investigate Gmail TLS errors and other recipient-side problems.
- Collect TLS-RPT reports and review MTA logs before changing transport policy; review DMARC separately for authentication.
- Move outbound mandatory TLS rules by recipient domain group rather than changing every route at once.
- Route transport failures to the team that can fix DNS, MTA configuration, or partner exceptions.
Views from the trenches
Best practices
Test each recipient MX directly before setting a force-TLS rule for any live domain.
Keep force-TLS failures out of production campaigns until bounce handling is confirmed.
Use TLS reports and mail logs together because each one catches different failure modes.
Common pitfalls
Inferring server-to-server TLS support from secure webmail or a working submission port.
Testing one MX host and missing a secondary host that does not offer STARTTLS on port 25.
Treating old no-TLS lists as current without retesting every MX for the recipient domain.
Expert tips
Stage TLS enforcement by partner domain so a single weak recipient does not block all mail.
Record the full TLS error and queue status because a status code alone is not a diagnosis.
Monitor MTA-STS and TLS-RPT before enforcing, then keep transport alerts tied to clear owners.
Marketer view
Marketer from Email Geeks says a purpose-built no-TLS recipient is the cleanest way to verify that a force-TLS policy fails closed.
2024-12-06 - Email Geeks
Marketer view
Marketer from Email Geeks says public transparency data helps find low-TLS destinations, but the exact MX still needs direct testing.
2024-12-06 - Email Geeks
Frequently asked questions
Yes. Gmail and Outlook.com are poor no-TLS test targets. The exact behavior for custom domains still depends on the recipient MX records and policy.
No. The 2019 SANS test identified it as a no-STARTTLS domain, and a December 2024 Email Geeks discussion described it as a test target. Neither establishes current support. Check that the domain still accepts email and test every current MX before relying on it.
The log should identify the TLS failure, such as missing STARTTLS or certificate validation failure. The sender then tries another permitted MX, queues the message, or generates a non-delivery report according to its policy. Exact text and enhanced status codes vary; a bounce is not always immediate.
No. MTA-STS applies only when the sending system supports and checks it. Enforce mode tells participating senders to require a policy-compliant TLS connection for mail sent to your domain.
Enable TLS for all outgoing mail. Requiring delivery to fail when TLS is unavailable is a separate decision based on the sensitivity of the message and recipient requirements. For broad consumer lists, test recipient domains and define queue monitoring and non-delivery handling before blanket enforcement.
No. SMTP TLS encrypts a connection between mail servers. Mail servers still process the message, and TLS does not encrypt the stored mailbox copy. End-to-end message encryption is a separate control.
