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.