Not on its own. Amazon Web Services (AWS) will sign a business associate agreement (BAA) that covers Amazon Simple Email Service (SES), which is required to send protected health information (PHI) through it. But a BAA is a legal contract, not a security configuration, and Paubox testing found that SES delivers PHI in plaintext, over retired encryption protocols, and to servers with invalid certificates, even with its "Require TLS" setting enabled. Signing the paperwork does not close those gaps.

What a HIPAA BAA with AWS actually covers

A business associate agreement is the contract that lets a vendor process PHI on a covered entity's behalf. AWS offers a BAA and lists SES among its HIPAA-eligible services, so a healthcare organization can use SES for PHI without violating HIPAA on the paperwork alone.

What the BAA does not do is describe how encryption is configured on any given message. It assigns legal responsibility. The technical question, whether each email actually leaves over a secure connection, is answered by the configuration and the receiving server, not the contract.

That distinction is where most teams get a false sense of security. A vendor can hold a current BAA with AWS and still send every message with the gaps documented below.

Where Amazon SES falls short of HIPAA's encryption expectations

Paubox ran 14 controlled tests against Amazon SES sending infrastructure and read the result of each from the recipient-side Received header. The report, How Amazon SES puts PHI at risk, documents three findings that matter for compliance.

First, default SES sends in plaintext when the receiving server offers no encryption. The message crosses the open internet unprotected, and the sender gets no signal that it happened.

Second, SES delivers over Transport Layer Security (TLS) 1.0 and 1.1, the protocols the Internet Engineering Task Force retired in 2021. Encryption that old is not the floor HIPAA's security standards point to.

Third, SES accepted invalid security certificates in every test. Self-signed and expired certificates all received the message, which means an encrypted email could reach an impostor instead of the intended recipient.

None of these are edge cases for healthcare. Paubox's 2026 Healthcare Email Security Report counted 170 email-related breaches reported to HHS in 2025, and most followed the same shape SES makes possible: a sender that did not require encryption paired with a receiver running an outdated mail server. The configuration gap and the breach pattern are the same story.

Why "Require TLS" does not make SES HIPAA compliant

AWS offers a configuration called "Require TLS" that sounds like it resolves this. In testing, it closed one of the four failure modes: the no-encryption case, which it bounced instead of sending in plaintext.

It did not set a minimum TLS version, and it did not validate certificates. Delivery over retired TLS 1.0 and 1.1 and to servers with invalid certificates continued with the setting on. As a compliance control, it covers one gap and leaves the others open.

What HIPAA actually requires for email encryption

The HIPAA Security Rule currently treats encryption in transit as "addressable," meaning an organization must either implement it or document a reasonable alternative. That flexibility is ending. The rule the U.S. Department of Health and Human Services (HHS) proposed in December 2024 makes encryption required, and HHS targeted May 2026 to finalize the change.

The federal benchmark for what counts as adequate encryption is already clear. The National Institute of Standards and Technology, in SP 800-52 Revision 2, sets TLS 1.2 as the minimum and calls for TLS 1.3 support. A sending path that drops to TLS 1.0 or 1.1, or to no encryption at all, does not meet that benchmark.

For the foundational rules that apply to every channel carrying patient data, see our guide to HIPAA compliant email.

How to evaluate whether your SES setup is compliant

A few checks surface the exposure before an auditor or an incident does.

  • Confirm a current BAA with AWS is in place. This is necessary but not sufficient.
  • Check 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.
  • Ask whether the sending path validates the receiving server's certificate. SES does not.

If those checks turn up plaintext, retired protocols, or unvalidated certificates, the configuration does not meet where HIPAA encryption requirements are heading, regardless of the BAA.

Frequently asked questions

Can you send PHI through Amazon SES at all?

Yes, with a signed BAA and the right controls around it. The BAA makes SES eligible. Closing the encryption gaps documented in Paubox's testing is what makes a given setup defensible.

Does enabling "Require TLS" make SES HIPAA compliant?

No. It stops the plaintext-to-an-unencrypted-receiver case, but SES still delivers over retired TLS 1.0 and 1.1 and to servers with invalid certificates.

What is the difference between HIPAA eligible and HIPAA compliant?

AWS describes SES as HIPAA eligible, meaning it can be used for PHI under a BAA. Compliant describes how you actually configure and operate it. Eligibility is the starting line, not the finish.

What should a vendor risk assessment ask about email?

Go past "do you have a BAA." Ask what minimum TLS version the sending path enforces, whether it validates the receiving server's certificate, and what it does when a receiver cannot support modern encryption. A vendor that has configured these protections can answer in specifics. A vague "we use TLS" usually means the defaults are in control.