Key Takeaways:
- Emails sent from Microsoft 365 and Google Workspace may fail to encrypt under certain conditions, without alerting senders or administrators.
- These silent failures often occur when messages are routed to outdated or misconfigured recipient servers.
- The use of obsolete TLS versions or fallback to cleartext delivery can undermine regulatory compliance, especially in healthcare and finance.
- Neither platform offers default visibility into these failures, leaving security teams unaware.
- Organizations can mitigate the risk with strict policy enforcement, third-party gateways, and routine partner assessments.
A new report from email security firm Paubox reveals a critical blind spot in the default email encryption behavior of Microsoft 365 and Google Workspace. While both services advertise encryption in transit, under specific—but surprisingly common—conditions, that encryption can silently fail, leaving messages vulnerable to interception.
The report highlights that these failures occur without notifying the sender, the recipient, or the admin team, creating a false sense of security in environments that demand strict data protection protocols.
Encryption That Isn’t Always Enforced
Paubox’s research shows that when emails are sent to recipients whose systems support only outdated encryption protocols—such as TLS 1.0 or 1.1—Google Workspace may proceed with the delivery using those deprecated standards. Microsoft 365, in some cases, may go even further by transmitting the email entirely in cleartext if a TLS connection cannot be established.
Both outcomes fall short of expectations in sectors where encryption is not optional, but mandatory. Industries like healthcare, legal services, and financial institutions are particularly exposed, as they regularly handle personally identifiable information (PII), protected health information (PHI), and other sensitive data.
Despite the gravity of this exposure, there is no visible warning. Messages appear to have been sent as usual. Logs and audit trails typically do not reflect that the message was delivered with weak or no encryption.
“Best Effort” Encryption Fails Compliance Standards
Security and compliance professionals have long warned against using outdated TLS versions. Government agencies and standards bodies have deprecated TLS 1.0 and 1.1 for years, citing known vulnerabilities that make encrypted data potentially readable by attackers using common tools.
In this context, “best effort” encryption—where delivery is prioritized over security—may no longer be sufficient. While convenient for ensuring messages are not bounced or delayed, this behavior risks noncompliance with data protection laws and industry regulations.
The issue is not theoretical. Paubox replicated scenarios involving communications between cloud services and legacy systems still in use by many third-party partners. The failures occurred with basic configurations, without any exotic setups or edge cases.
No Alerts, No Logs, No Visibility
One of the most troubling aspects of this blind spot is how hard it is to detect.
Senders receive no error messages or bounce notifications. Admin dashboards remain silent. Unless someone inspects raw email headers or uses a monitoring gateway that checks for encryption standards, the breach in security remains invisible.
This silent downgrade behavior means organizations may be regularly transmitting sensitive data over unprotected channels—without knowing it. In the eyes of regulators, ignorance is not a defense.
What’s Behind the Failures?
These encryption downgrades often result from TLS handshake failures. This can happen if the recipient’s server lacks the required cipher suite, certificate configuration, or protocol version to complete a secure connection.
Google Workspace, when facing such a scenario, will default to older versions of TLS—even those considered insecure. Microsoft 365 might simply bypass encryption altogether if a secure handshake can’t be completed. In both cases, the message gets delivered—but not securely.
The motive is clear: avoid disrupting communication. But the cost is high. Data privacy, regulatory compliance, and security integrity are all compromised when secure delivery isn’t guaranteed.
Practical Implications for Regulated Industries
In sectors governed by HIPAA, GLBA, or GDPR, email encryption is not optional. Yet the widespread assumption is that using major cloud providers like Microsoft and Google guarantees protection by default.
That assumption, according to Paubox’s findings, does not hold.
In healthcare alone, where legacy systems are still commonplace, the chance of hitting a misconfigured recipient domain is substantial. When that happens, even PHI could be transmitted without encryption—exposing organizations to regulatory scrutiny and breach liability.
Recommendations for Security Teams
To address this issue, organizations can take several steps:
- Enforce TLS Policies: Configure mail systems to require TLS 1.2 or higher for all outbound email. Reject deliveries that do not meet this standard.
- Monitor Encryption Posture: Use third-party gateways or header analysis tools to detect when messages are sent with insufficient encryption. Raise alerts and log these events.
- Evaluate Partner Infrastructure: Periodically assess the security configurations of regular recipients, especially third-party partners with older mail systems.
- Disable Insecure Fallbacks: If using Microsoft 365 or Google Workspace, explore administrative settings or external tools that can block deliveries when encryption fails.
- Educate End Users: Make users aware that email encryption is not always guaranteed, and guide them on how to securely share sensitive information when needed.
- Implement End-to-End Encryption Where Needed: For extremely sensitive data, consider using tools that encrypt content before it ever reaches the cloud provider’s servers.
Why This Gap Exists
The root of the issue lies in balancing usability and security. Cloud providers historically prioritize message delivery—even if that means falling back to outdated or unsecured transmission methods. For most casual use, that tradeoff might seem acceptable.
But in regulated industries, or for businesses with significant IP risk, the tradeoff is too steep. Silent encryption failure creates exposure that cannot be mitigated without deeper visibility and control.
Until Microsoft and Google revise these defaults, responsibility falls to IT and security teams to close the gap.
The Bigger Picture
This issue is a reminder that default settings in cloud applications—no matter how reputable the provider—aren’t always aligned with enterprise security needs. Organizations should regularly test, review, and audit critical workflows to ensure real-world behaviors meet their compliance standards.
Encryption should never be “best effort.” It should be required—and if that requirement cannot be met, delivery should fail rather than silently degrade.
Learn how AI Agents can supercharge your company’s profits and productivity at TMC’s AI Agent Event, Sept 29-30, 2025 in DC.
If you liked this post, you’ll love one of the the leading global business communications and technology events since 1999, the ITEXPO #TECHSUPERSHOW, Feb 10-12, 2026 Fort Lauderdale, Florida.
Don’t forget the collocated MSP Expo – just for managed service providers!
Aside from his role as CEO of TMC and chairman of ITEXPO #TECHSUPERSHOW Feb 10-12, 2026, Rich Tehrani is CEO of RT Advisors and a Registered Representative (investment banker) with and offering securities through Four Points Capital Partners LLC (Four Points) (Member FINRA/SIPC). He handles capital/debt raises as well as M&A. RT Advisors is not owned by Four Points.
The above is not an endorsement or recommendation to buy/sell any security or sector mentioned. No companies mentioned above are current or past clients of RT Advisors.
The views and opinions expressed above are those of the participants. While believed to be reliable, the information has not been independently verified for accuracy. Any broad, general statements made herein are provided for context only and should not be construed as exhaustive or universally applicable.
Portions of this article may have been developed with the assistance of artificial intelligence, which may have contributed to ideation, content generation, factual review, or editing
