Amazon SES can send PHI in plaintext, even with Require TLS enabled

Paubox ran 14 controlled tests against Amazon Simple Email Service (SES) and found that it delivered protected health information (PHI) in plaintext when the receiving server offered no encryption, sent email over TLS protocols that standards bodies retired in 2021, and accepted invalid security certificates without blocking a single one.

Amazon's documentation tells developers the service requires TLS 1.2. The behavior recorded in the message headers does not match that promise.

What Amazon SES tells developers vs. what it does

The Amazon SES Developer Guide states the service "requires TLS 1.2 and recommends TLS 1.3."

In testing, even with the "Require TLS" setting enabled, SES delivered email over TLS 1.1 when the receiver offered up to TLS 1.1, and over TLS 1.0 when the receiver offered up to TLS 1.0.

The recipient-side Received header recorded each version, leaving an audit trail that contradicts the documented requirement.

The "Require TLS" setting reads like a minimum version guarantee. What it actually does is check whether any encryption handshake completed, regardless of how outdated the negotiated protocol was.

The protocols SES still uses were retired five years ago

The Internet Engineering Task Force (IETF) deprecated TLS 1.0 and TLS 1.1 in RFC 8996 in March 2021, moving both to "Historic" status.

The National Institute of Standards and Technology (NIST) reached the same conclusion in Special Publication 800-52 Revision 2, setting TLS 1.2 as the minimum for U.S. federal systems and requiring TLS 1.3 support by January 1, 2024.

Five years past that retirement, a commercial email service that healthcare teams rely on still delivers over both protocols whenever the receiver supports them.

Default SES sends PHI in plaintext

"Require TLS" is opt-in. By default, SES uses opportunistic TLS, which attempts encryption and delivers the message regardless of the result.

When the receiving server offers no TLS at all, the default configuration sends the message in plaintext across the open internet.

Any healthcare organization or healthtech vendor running default SES is one outdated receiving server away from sending PHI without encryption. That server does not have to belong to a bad actor. It could be a small clinic, a specialty lab, or a partner running an older mail server.

This is the pattern behind the breaches Paubox documented last year. The 2026 Healthcare Email Security Report counted 170 email-related breaches reported to HHS in 2025, and the configuration gaps behind them follow the same shape: a sender that does not require encryption paired with a receiver that has not kept its mail server current.

Encrypted is not the same as authenticated

TLS does two jobs. It encrypts the message, and it verifies that the receiving server is who it claims to be. Verification depends on the server's certificate.

Paubox tested SES against four certificate failure scenarios: a self-signed certificate and an expired certificate, each under both SES configurations. SES blocked none of them.

A message encrypted to a server with an invalid certificate could be heading to an impostor instead of the intended recipient. The encryption succeeds while the recipient goes unverified, which is the definition of man-in-the-middle exposure.

What "Require TLS" actually closes

Across every test, the "Require TLS" setting changed the outcome in exactly one scenario: the case where the receiver offered no encryption at all. There, SES bounced the message instead of sending plaintext.

It did not require a minimum TLS version, and it did not validate certificates. Delivery over TLS 1.0 and 1.1 and to invalid certificates all continued.

As Hoala Greevy, founder and CEO of Paubox, put it: "TLS being on is not the same as PHI being protected. 'Require TLS' on Amazon SES enforces neither a minimum version nor certificate validation."

Why this matters more now

The HIPAA Security Rule currently treats encryption in transit as "addressable," meaning an organization can implement it or document a reasonable alternative.

The rule HHS proposed in December 2024 makes encryption required, and HHS targeted May 2026 to finalize the change.

A service that treats encryption as best-effort does not meet a hard requirement. For teams sending PHI, the gap this report documents becomes harder to justify as the standard tightens.

What healthcare teams should check

For teams sending PHI through SES, a few steps surface the exposure.

• Audit whether "Require TLS" is enabled. Without it, outbound PHI can send in plaintext whenever a receiver offers no encryption.
• Review the Received header from bounce notifications, DMARC reports, and recipient-side logs for the negotiated TLS version. If TLS 1.0 or 1.1 appears, you have confirmed delivery over a retired protocol.
• Recognize that "Require TLS" alone does not close the version-downgrade or certificate gaps.

Closing the gap fully takes a sending path that enforces a TLS 1.2 minimum and validates certificates, rather than checking whether any handshake completed. For Paubox, TLS 1.2 or higher with a valid certificate is required, and anything weaker routes to a patented Secure Message Center instead of crossing the internet under weak encryption.

For a deeper foundation on the standard healthcare email is held to, see our guide to HIPAA compliant email.

The full findings, including the test matrix and the Received headers captured as evidence, are in the report: How Amazon SES puts PHI at risk.

Frequently asked questions

Does a HIPAA business associate agreement with AWS fix this?

No. A business associate agreement (BAA) is a legal contract that lets AWS process PHI on a vendor's behalf. It says nothing about how encryption is configured. A vendor can hold a BAA and still send every email with the gaps described here.

Is enabling "Require TLS" enough for HIPAA compliant email?

No. It closes the plaintext case, but SES still delivers over retired TLS 1.0 and 1.1 and to servers with invalid certificates.

How can I tell if my own SES email went over a weak protocol?

Review the Received header from bounce notifications, DMARC reports, and recipient-side logs. The header records the negotiated TLS version for each hop.