Amazon Simple Email Service (SES) will encrypt an email and hand it to a server that has not proven it is the intended recipient. In Paubox testing, SES delivered to receivers presenting self-signed and expired certificates in every attempt, under both its default configuration and "Require TLS." Encryption without verification is the gap, because an encrypted message delivered to the wrong server is still exposed to whoever controls that server.

TLS does two jobs, and SES only does one reliably

Transport Layer Security (TLS) is doing two things at once when an email is delivered. It encrypts the connection so the contents cannot be read in transit, and it verifies that the receiving server is who it claims to be. Verification depends on the server's certificate, the credential that proves its identity.

Encryption without verification is a half-measure. The message is scrambled, but it may be scrambled to the wrong party. SES handles the encryption step and, in Paubox testing, skipped the verification step.

Verifying server identity is a defined standard, not a Paubox preference. The Internet Engineering Task Force describes how a sender should confirm it is talking to the right server in RFC 6125. The check exists precisely so that an encrypted connection cannot be quietly redirected to an impostor.

What the certificate tests found

Paubox ran four certificate-failure tests as part of the research published in How Amazon SES puts PHI at risk: a self-signed certificate and an expired certificate, each under SES default and under "Require TLS."

SES blocked none of them. The self-signed certificate received the message. The expired certificate received the message. Enabling "Require TLS" did not change the outcome. In each case the Received header recorded a fully encrypted session, so from the sender's side the delivery looked clean.

This runs against the expectation the Amazon SES Developer Guide sets elsewhere, where AWS documents TLS as a security control for outbound mail. SES applied the encryption but skipped the identity check that should accompany it.

Why an encrypted message to an unverified server is a man-in-the-middle risk

A self-signed or expired certificate is exactly what an attacker positioned between sender and recipient would present. They cannot produce a valid certificate for the real recipient's domain, so they offer one that is invalid but still completes an encrypted handshake.

A sending path that accepts that certificate hands the message over and encrypts it directly to the attacker. That is the structure of a man-in-the-middle attack. The protected health information (PHI) inside is readable by the party that intercepted it, and the sender sees a successful, encrypted delivery either way.

This is distinct from the plaintext and protocol-downgrade problems in the same testing. Here the encryption worked as designed, but the recipient on the other end of it was never confirmed.

Email is already the dominant breach surface in healthcare. Paubox's 2026 Healthcare Email Security Report counted 170 email-related breaches reported to the U.S. Department of Health and Human Services in 2025. A sending path that delivers to unverified servers adds another way for PHI to reach the wrong hands while every log on the sender's side reads as a clean, encrypted success.

What proper certificate validation looks like

A platform that handles PHI should reject the connection when the certificate does not check out, not deliver anyway. Standard practice includes checking the certificate against trusted authorities, validating that it matches the receiving server's hostname, and refusing expired certificates outright. These are the controls Paubox applies before sending sensitive data over email.

The federal encryption benchmark assumes this. NIST SP 800-52 Revision 2 treats certificate validation as part of a correctly configured TLS connection, not an optional extra. A connection that encrypts to an unverified server is not the secure delivery the standard describes.

For the broader rules on protecting patient data over email, see our guide to HIPAA compliant email.

How to check your own SES setup

Certificate behavior is harder to see than a plaintext send, but a few steps surface it.

  • Review whether your sending path validates the receiving server's certificate at all. SES does not reject invalid certificates, so the absence of bounces is not evidence of safety.
  • Test against a receiver with a known-bad certificate in a controlled environment and confirm whether the message is delivered or refused.
  • Treat "the connection was encrypted" as an incomplete answer. The question that matters for PHI is whether the recipient was verified.

If your current path delivers to unverified servers, the fix is a sending model that makes verification a precondition rather than checking whether any handshake completed.

Frequently asked questions

Does "Require TLS" make Amazon SES validate certificates?

No. In Paubox testing, "Require TLS" did not change the certificate outcome. Self-signed and expired certificates still received the message.

Is an encrypted email to a bad certificate still a breach risk?

Yes. If the certificate belongs to an attacker rather than the intended recipient, the message is encrypted straight to them. Encryption does not help when the other end is the wrong party.

How is this different from the plaintext finding?

Plaintext means no encryption at all. The certificate finding is the opposite surface: the message is encrypted, but to a server whose identity was never confirmed.