Paubox Says Amazon SES Can Send “Require TLS” Emails in Plaintext, Even When TLS 1.2 Is Listed as Required

Amazon Simple Email Service, or SES, has long been marketed as a way to send email over encrypted connections. But a new set of tests from Paubox, a provider focused on HIPAA-regulated email, argues that SES can still deliver sensitive health information in ways that fail to meet the security assurances customers may assume from Amazon’s documentation. Paubox said its researchers ran controlled experiments against SES in the second quarter of 2026 and used the recipient-side “Received” email headers to determine what encryption actually occurred.

In Paubox’s account, Amazon’s SES documentation says the service “requires TLS 1.2 and recommends TLS 1.3,” yet Paubox reported that SES delivered email using whatever TLS version the receiving server offered, including encryption protocols it said were considered retired by the Internet Engineering Task Force. Paubox also said the problem does not require an attacker, because it tied the failures to SES’s default “opportunistic TLS” behavior, where encryption is attempted but the message is sent even if a secure session cannot be established.

Paubox further claimed that SES’s “Require TLS” setting, which is designed to prevent delivery when TLS cannot be established, blocked only one of four failure modes Paubox says it tested. The company also said SES did not block tests involving invalid certificates, meaning an email could be delivered in encrypted form to servers that, in Paubox’s tests, could not prove their identity. Paubox’s chief executive, Hoala Greevy, was cited saying that “TLS being on is not the same as PHI being protected,” and that “Require TLS” does not enforce a minimum encryption version or certificate validation in the way many compliance teams expect.

Amazon SES’s own documentation describes a model that can help explain part of the dispute. For the SMTP interface, Amazon says clients must encrypt the connection using TLS, with TLS established either through STARTTLS or a TLS wrapper. More importantly for outbound delivery, Amazon says SES uses “opportunistic TLS” by default, which starts as plaintext and then upgrades to a TLS-encrypted session only if both sides support STARTTLS. Amazon also says that if SES cannot establish a secure connection, it sends the message unencrypted. Amazon notes that customers can change that default by using configuration sets and setting a TLS policy to “Require,” in which case SES will only deliver if it can establish a secure connection and will drop the message if it cannot.

The controversy lands as the United States moves toward stricter HIPAA cybersecurity expectations. On December 27, 2024, the Department of Health and Human Services Office for Civil Rights issued a notice of proposed rulemaking to strengthen the HIPAA Security Rule. In a published factsheet, HHS said the proposal would remove the distinction between “required” and “addressable” implementation specifications and would require encryption of electronic protected health information (ePHI) both at rest and in transit, with limited exceptions.

Paubox’s argument is that organizations may believe they are covered when they configure SES to “require TLS,” but that the actual protection level may vary depending on what the receiving server supports, and whether certificate checks are enforced. If that is accurate, the operational risk is not only confidentiality exposure, but also compliance uncertainty, because HIPAA security assessments often depend on evidence that required safeguards work as intended across real-world delivery paths.

Amazon did not respond in the reporting reviewed for this article, and Paubox did not provide full methodological details in the text available publicly here about which specific failure conditions were covered in all 14 tests, beyond describing the use of Received headers and categories of encryption and certificate behavior. As a result, the precise scope of what SES will do in every configuration, and whether differences depend on receiving-server behavior or SES API versus SMTP paths, remains something customers would likely need to verify directly in their own environments.