What is encryption in transit (TLS) and at rest?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

You send a campaign. It travels from your ESP to Gmail's servers, then sits in a database somewhere until your subscriber opens it. At two different points in that journey, your data could be exposed. That's what encryption in transit and encryption at rest are designed to prevent.

Encryption in transit (TLS) protects your email while it's moving. TLS (Transport Layer Security) wraps the connection between mail servers so that anyone intercepting the traffic along the way can't read what's inside. When your ESP hands off a message to a receiving server, that handshake happens over an encrypted channel. You can spot it in email headers. Look for "with ESMTPS" in the Received lines. That tells you TLS was used for that hop.

Most major mailbox providers now use TLS and many prefer or require it. It's worth knowing that TLS protects the connection, not the message itself. If you want the message content encrypted end-to-end regardless of what servers it passes through, that's a different technology (S/MIME or PGP). Those aren't practical for standard marketing email, but they're worth understanding exist.

Encryption at rest protects your data when it's not moving anywhere. Subscriber lists, message logs, campaign data, backups. All of that sits on physical or cloud storage somewhere. Encryption at rest means that even if someone walks off with a drive or gets unauthorized access to a storage system, the data is unreadable without the encryption keys.

This one matters a lot if you're in healthcare (HIPAA), handle payment data (PCI), or have European subscribers (GDPR). Compliance frameworks often explicitly require data at rest to be encrypted, and auditors will ask for documentation of it.

And Here's the practical split for most senders. Your ESP handles the heavy lifting on both sides. They manage TLS certificates for delivery, and they encrypt their databases and backups. What you're responsible for is choosing an ESP that actually documents these practices, and auditing that documentation before you hand over subscriber data.

If you're vetting an ESP and you can't find a clear security page explaining their encryption standards, that's a red flag. Good ESPs publish this. Ask specifically whether subscriber data is encrypted at rest, whether TLS is enforced on inbound and outbound connections, and what their key management practices look like.

Still unsure what to look for in your current setup? Our email header analyzer can help you confirm whether TLS is being used on your outbound mail. Or if you're in a compliance-sensitive industry and want a second pair of eyes, our SOS hotline is free.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Check my email encryption setup

I send email through an ESP and I want to understand whether my subscriber data and messages are properly protected. Based on my situation, help me figure out what TLS in transit and encryption at rest actually mean for my setup, what my ESP should be handling, and what I need to verify or ask them. Here's my context: - My industry (e.g. healthcare, ecommerce, SaaS): INDUSTRY - My ESP: ESP NAME - Whether I've seen a security or compliance page for my ESP: YES / NO / NOT SURE - Any compliance requirements I'm aware of (HIPAA, GDPR, PCI, none): COMPLIANCE Please give me a ranked list of what to check first, what questions to ask my ESP, and any red flags I should watch for.

Edit the yellow boxes, then send to the AI of your choice.