What "encryption at rest" actually means for email

Every software vendor writes "encrypted" on their security page. On its own the word conveys almost nothing. The useful questions are more specific.

Question one: what exactly is encrypted?

For many providers the answer is full-disk encryption. The server's drive is encrypted, which protects against a stolen disk. It offers nothing at all if someone reaches your database through an application flaw or leaked credentials, because the database is running and the data reads as plaintext.

Field-level encryption is a different thing. Each value is encrypted individually, so a database dump contains only ciphertext.

Ask specifically: is the message body encrypted? The subject? Participant addresses? Attachment filenames? The mailbox credentials themselves?

Question two: which mode?

Do not stop at "AES-256". Ask about the mode of operation.

CBC encrypts but does not authenticate. If an attacker alters bytes of ciphertext you will not necessarily know; decryption may quietly produce different plaintext. This is the foundation of padding oracle attacks.

GCM authenticates as part of the operation. Alter one byte and decryption fails outright rather than silently returning something wrong.

Question three: where does the key live?

If the encryption key sits in the same database it protects, the exercise is decorative. It belongs somewhere else: environment configuration, a secrets manager, or a hardware security module.

A follow-up worth asking: is the key for mail data separate from the application's general-purpose key? Rotating an application key is routine. If the two are the same, every rotation renders historical mail permanently unreadable.

Question four: how do you search encrypted data?

This is the question that reveals the most. If email addresses are encrypted, how does a lookup by address work? Every encryption uses a random initialisation vector, so the same value produces different ciphertext each time and ordinary equality comparison cannot match.

The correct answer involves a blind index: a separate column holding a keyed hash of the value. Deterministic enough to match exactly, one-way enough to be useless in a leak, with the key held outside the database.

If a vendor hesitates on this question, it may be that they decrypt data in order to search it, or that it was never encrypted in the first place.

One closing thought

Encryption is a single layer, not a complete answer. Access control, audit logging, two-factor authentication and tenant isolation matter just as much. A vendor who talks only about encryption and goes quiet on the rest has probably only built the part they talk about.