The myth of "force TLS"

Force TLS sounds like a smart security setting. If the recipient doesn’t support encryption, the message won’t deliver. Simple, right?

What seems like a safeguard is often just a false sense of security.

What is force TLS supposed to do?

The idea behind force TLS is straightforward: your email system will only deliver messages if the receiving server supports Transport Layer Security (TLS). If it doesn’t, the message should bounce—ensuring that no data is sent without encryption.

In theory, this protects sensitive information from being exposed in transit. But in practice, cloud platforms like Google Workspace and Microsoft 365 don’t enforce this rule the way IT teams assume they do.

What Paubox discovered in real-world testing

In a series of TLS experiments, Paubox researchers configured Microsoft 365 and Google Workspace to send email to servers that only accepted outdated encryption protocols, like TLS 1.0 and 1.1. Here’s what happened:

• Google Workspace delivered the email using TLS 1.0 and 1.1—despite those protocols being explicitly deprecated by the NSA.

• Microsoft 365 rejected those protocols, but instead of bouncing the message, it delivered it in cleartext.

• Neither platform provided any visible indication that encryption had failed.

The most alarming part? These behaviors aren’t misconfigurations. They’re defaults.

The hidden danger of silent failure

When a message is downgraded to obsolete encryption—or worse, sent unencrypted—there’s no bounce. No alert. No audit trail. To the sender, everything looks normal. But behind the scenes, sensitive data may be exposed to interception.

Force TLS doesn’t enforce encryption strength or version. It doesn’t align with current best practices. It simply gives the appearance of protection.

As Paubox CEO, Hoala Greevy, put it: “Force TLS gives you just enough confidence to stop asking questions—until something breaks.”

Why this matters beyond healthcare

These encryption failures aren’t just a HIPAA issue. They affect any organization handling regulated or sensitive data—including financial institutions, law firms, schools, and government agencies. If your email platform silently fails, you’re not just at risk of a breach. You’re also at risk of noncompliance and reputational damage.

What to do instead

If you rely on force TLS, now is the time to reassess. Here are some steps to take:

• Inspect your message headers to confirm the TLS version and cipher used

• Disable support for TLS 1.0 and 1.1 in your server configurations

• Test your outbound messages by sending to environments with limited TLS support

• Ask your vendor what happens when TLS fails—and how that’s logged

• Consider solutions that guarantee blanket encryption without portals or plugins

Want to test your encryption for yourself?

The full findings of our TLS experiment are available in the report: How Microsoft and Google Put PHI at Risk. You’ll find message header samples, platform comparisons, and recommendations for securing your email.