Email encryption: TLS, end-to-end and storage protection
“Encrypted email” can describe several different protections. The connection may be encrypted while a provider can still access the message. Stored data may be encrypted on disk while an authenticated user can read it normally. End-to-end encryption aims to restrict content access to the intended endpoints.
Choose the protection for the information and workflow, rather than relying on the word “encrypted” in a product description.
Three layers to distinguish
| Layer | What it protects | What it does not establish |
|---|---|---|
| Transport encryption | Data travelling across a particular connection | That every storage location or endpoint is safe |
| Encryption at rest | Stored data against defined storage-level threats | That an authorised account or service cannot read it |
| End-to-end encryption | Message content between intended endpoints | That recipients' devices or private keys cannot be compromised |
A message may travel from an email client to a sending server, across receiving infrastructure and then to the recipient. It can also be stored in multiple mailboxes, archives and backups. Consider the whole journey.
TLS protects connections
TLS can protect client connections and mail-server connections. With opportunistic SMTP TLS, a server attempts an encrypted connection but delivery behaviour depends on policy and the capabilities of the systems involved.
Ask your provider how it handles transport security, certificate validation and recipients that do not support the expected connection. Do not assume the browser's HTTPS connection to webmail proves the onward delivery route was encrypted.
Transport encryption does not prevent an authorised mailbox session, a compromised endpoint or a provider with appropriate access from reading message content. Account protection and data handling remain separate concerns.
What MTA-STS adds
MTA-STS lets a receiving domain publish a policy describing its acceptable MX hosts and TLS requirements. Supporting senders can use that policy to resist downgrade and impersonation attempts on the mail-server route. It does not force every mail system on the internet to implement the policy. RFC 8461 defines the mechanism.
Deployment needs the appropriate DNS signal, an HTTPS policy endpoint, certificates and matching mail-server configuration. Start with a testing and monitoring plan before enforcing a policy. Keep the policy current when changing mail providers: this is ongoing infrastructure, not a one-time DNS trick.
A broken policy can delay legitimate delivery. Establish who maintains the HTTPS endpoint and who checks reports. Connecting your domain to email explains the underlying DNS dependencies.
When message-level encryption is useful
Consider message-level protection when the sensitivity of the content or an agreed business requirement demands stronger restrictions on who can read it. S/MIME and OpenPGP are examples of approaches used for signed or encrypted mail, with different deployment and key-management requirements.
The practical questions include recipient compatibility, key distribution, mobile access, recovery and what happens when a member of staff leaves. A technically strong scheme that users bypass because it is unusable will not meet the intended purpose.
A secure portal can be convenient for exchanging confidential documents with customers. It is not automatically end-to-end encrypted: check who can decrypt the content, how recipients authenticate and how access expires.
Plan access and recovery together
Losing a private key can make encrypted archives unreadable. Recovery arrangements need appropriate access controls and a clear decision about who may recover keys or data. Retention needs and employee departure procedures should be designed before rollout.
Protect administrative and user accounts with strong authentication. Review forwarding rules and connected applications. Encryption does not stop an attacker who has gained authorised access to a mailbox from acting within that access.
For attachments that do not need to travel by email, a controlled file-sharing workflow may be easier to manage. Our business file storage guide compares those options.
Encryption is different from sender authentication
SPF, DKIM and DMARC help receivers assess sending identities. They do not encrypt message content. Likewise, encrypted mail can still contain a fraudulent request, and a compromised legitimate account can send authenticated messages.
Use a separate verification channel for changes to payment details and other sensitive instructions. The technical controls support that process rather than replacing it.
ResaHost's business email service is a starting point for discussing your mail requirements. Confirm the supported transport policies and any specialist encryption or portal arrangement explicitly before treating them as part of a package.