[mh_key_takeaways]
Most email delivery today runs over TLS. That protects the connection between mail servers, but it does not protect the message body itself.
Understanding tls encryption email is the difference between assuming a message is safe and knowing where it is exposed. For compliance-driven senders, TLS alone may not satisfy the requirement, and layering an encrypted email service on top closes the fallback gap that opportunistic TLS leaves open.
This guide covers what TLS actually does, where it falls short, and how to verify a mail flow is using TLS the way the sender expects.
TLS encrypts the connection, not the content
Transport Layer Security is the same protocol that secures HTTPS. In email, it secures the SMTP session between two mail servers.
When a sending server hands a message to a receiving server, both sides negotiate a TLS session. Once negotiated, all traffic on that connection is encrypted, including the message headers and body.
The receiving server decrypts the connection and stores the message. Whatever protection the message had during the transfer ends at that point. If the receiving mailbox is unencrypted at rest, the message sits in cleartext until the recipient reads it.
TLS protects against passive network eavesdropping between servers. It does not protect against the receiving server, an administrator on the receiving side, or anyone with legitimate mailbox access.
Opportunistic TLS is the default and its weakness
The default SMTP delivery model is opportunistic TLS. The sending server offers TLS, and the receiving server accepts if it supports the protocol.
If the receiving server does not support TLS, the message falls back to plain SMTP. The sending server delivers the message in cleartext rather than bouncing it.
The fallback is intentional. It preserves delivery in a world where not every mail server supports current standards. It also opens a downgrade attack path.
A network attacker who can intercept the SMTP conversation can strip the STARTTLS command from the greeting, and both sides will proceed in cleartext. This is called STRIPTLS and is well-documented in the mail security research community.
MTA-STS and DANE close the fallback gap
MTA-STS publishes a policy in DNS and at a well-known HTTPS URL that tells sending servers to enforce TLS to a specific domain. If the handshake fails, the sender bounces the message rather than falling back to cleartext.
Google, Microsoft, and most large providers publish MTA-STS records and honor them on outbound. Smaller domains often do not, though adoption is climbing.
DANE uses DNSSEC-signed records to publish TLS certificate fingerprints. It provides similar downgrade protection with a different mechanism. DANE requires DNSSEC on the recipient’s domain, which limits deployment.
Both standards are documented in RFCs. MTA-STS is RFC 8461, and SMTP DANE is RFC 7672. Practices sending regulated content to unknown domains should publish MTA-STS on their own domain and consider DANE if their DNS provider supports DNSSEC.
Office 365 uses TLS on both directions with enforcement options
Microsoft 365 supports TLS 1.2 and 1.3 on inbound and outbound mail. TLS 1.0 and 1.1 were disabled across the platform in 2020, and legacy connections that try to use them fail.
Administrators can enforce TLS to specific recipient domains through Exchange Online connectors. A connector configured to require TLS refuses to deliver if the handshake fails, bouncing the message back to the sender.
Enforcement is useful for delivery to known partners and providers. Enforcing TLS globally is not practical, because it would bounce messages to any receiver that does not support current standards.
The Microsoft 365 admin center publishes TLS statistics in the mail flow reports. Practices can see the percentage of outbound and inbound mail using each TLS version and identify low-TLS destinations.
[mh_example]
Outlook covers the client-to-server hop only
Outlook is a mail client, not a mail server. Its TLS coverage is the connection from the desktop or mobile app to the mail server it authenticates against.
Every current version of Outlook enforces TLS 1.2 or higher for that connection. The client-to-server hop is encrypted regardless of what any downstream mail server does.
What happens after the message reaches the Microsoft 365 or Exchange server is out of Outlook’s control. The server handles delivery, and that delivery depends on the sending server’s TLS enforcement and the receiver’s TLS support.
Sending an encrypted-looking message from Outlook does not guarantee end-to-end TLS. It only guarantees the first hop. For full-path assurance, the sender needs message-level encryption or verified TLS enforcement on every hop.
TLS alone does not fully satisfy HIPAA
The HIPAA Security Rule requires encryption of PHI in transit when reasonable and appropriate. TLS 1.2 or higher meets the technical standard for cipher strength and key length.
The gap is opportunistic delivery. A message sent from a compliant server can still travel in cleartext if the receiving server does not support TLS and the sender does not enforce it.
HHS has never issued a rule that TLS alone is insufficient. It has fined practices for unencrypted PHI transmission when opportunistic TLS was assumed but not verified.
The safer approach is layered. Use TLS for the transit layer, and use message-level encryption for the content. That way the message is protected regardless of what any intermediate server does. Practices reviewing the boundary between the two often look at the difference between tls encryption and email encryption to make the case internally.
How to verify a mail flow is using TLS
The Received header of any email shows the TLS status of the last hop. Look for a line like “using TLSv1.3” or “with STARTTLS.” A missing TLS notation means the hop was cleartext.
Google Postmaster Tools shows outbound TLS percentage per receiving domain. Practices sending large volumes can see which destinations regularly downgrade.
CheckTLS runs an on-demand test against any receiver. Enter a destination address, and CheckTLS attempts a full delivery, reporting the TLS version, cipher, and certificate details.
Microsoft 365 admins can enable connection logging under the Exchange admin center. The logs show per-message TLS status and are useful for troubleshooting a specific destination that keeps downgrading.
[mh_protip]
When a receiver does not support TLS, options are limited
A sender cannot force a receiving server to support TLS. If a specific destination refuses TLS, the sender has to work around it.
Option one is message-level encryption. Send the message through a service that encrypts the body and delivers a portal link. The receiver opens the link in a browser, and the connection to the portal uses HTTPS regardless of the receiving mail server’s capabilities.
Option two is contacting the receiving organization. Ask them to enable TLS 1.2 on their server. Small clinics, universities, and government agencies sometimes run outdated infrastructure and are open to fixing it when asked.
Option three is choosing a different channel for that specific recipient. A patient portal upload, a secure file transfer, or physical mail may be more appropriate than fighting a mail server that will not encrypt.
Configuring outbound TLS enforcement on the sender side
On Microsoft 365, administrators create a partner connector under Exchange admin center, Mail flow, Connectors. The connector points to the recipient domain and enables the option to require TLS.
On Google Workspace, administrators configure Compliance rules under Apps, Google Workspace, Gmail, Compliance. TLS requirements are set per recipient domain.
Enforced connectors bounce messages if TLS fails. That is the trade-off. The bounce is a clear signal that the destination is not honoring TLS, and it prevents the practice from accidentally sending PHI in cleartext.
For frequently-contacted partners, enforced TLS is worth the small operational overhead. For one-off external contacts, message-level encryption is usually simpler than configuring a connector.
Practical setup for a healthcare practice
Start with the inbound side. Confirm the practice’s mail server accepts TLS 1.2 or higher, publishes MTA-STS, and rejects deprecated cipher suites. Test with CheckTLS.
Move to the outbound side. Verify that outbound mail uses TLS 1.2 or higher and honor MTA-STS records from receiving domains. Google and Microsoft handle this automatically for tenants on current versions.
Add message-level encryption for external PHI transmission. Layer a service like Mailhippo or Purview on top of TLS. That way the content is protected even if any hop along the way downgrades to cleartext.
Practices that want the broader security posture to match the email layer often work with an agency familiar with healthcare marketing and healthcare website security features. Consistent security across email, forms, and website matters to auditors and to patients. The NIST SP 800-52 Rev. 2 guidelines outline the cipher and version baselines to match.
- Confirm inbound and outbound TLS 1.2 or higher on the mail server.
- Publish MTA-STS on the practice’s own domain.
- Enforce TLS to known partners through Exchange or Gmail connectors.
- Add message-level encryption for external PHI mail.
- Run quarterly TLS verification tests and log the results.
TLS encryption email covers the network path between servers. It does not cover the content once the message lands, and it can fall back to cleartext when a receiver refuses to negotiate. Understanding those limits is what separates a working mail flow from a compliant one.
[mh_faqs]
