Encrypted Email for Business: TLS, S/MIME, PGP and E2EE

Encrypted email for business comes in three layers: encryption in transit (TLS between mail servers and apps), encryption at rest (on the provider's disks and backups), and end-to-end encryption (S/MIME, PGP or a provider's own system, where only sender and recipient can read the message). Most businesses need enforced TLS and strong account security; end-to-end encryption suits specific, sensitive cases.

"Is our email encrypted?" sounds like a yes-or-no question. It is not. This guide explains each layer in plain terms, what it does and does not protect against, and how to choose without buying more complexity than you need.

The three layers of email encryption

Layer	What it protects	Who can still read the message	Typical technology
In transit	The message while it travels between servers and between your device and the server	Your provider and the recipient's provider	TLS, STARTTLS, MTA-STS, DANE
At rest	Stored data on disks or backups, against theft of the media	The provider's systems, when running	Disk or storage encryption, encrypted backups
End-to-end (E2EE)	The message content from sender to recipient, including against both providers	Only people holding the private keys	S/MIME, OpenPGP, provider-specific E2EE

Each layer answers a different threat. Transit encryption stops someone on the network from reading or altering mail. At-rest encryption protects stolen disks or backup files. End-to-end encryption protects against anyone in the middle, including the email providers themselves.

Encryption in transit: the layer everyone needs

Email moves in hops: from your laptop to your provider (over IMAP and SMTP), then from your provider's server to the recipient's server (over SMTP), then to the recipient's phone. TLS can protect each hop.

The weak spot has historically been the server-to-server hop. Servers use STARTTLS, which upgrades a plain connection to an encrypted one if both sides support it. By default this is opportunistic: if an attacker strips the STARTTLS offer, many servers quietly fall back to sending in clear text.

Two standards close that gap:

MTA-STS (RFC 8461) lets a domain publish a policy saying "only deliver mail to my servers over valid TLS". Sending servers that support it refuse to downgrade. TLS-RPT sends you reports when deliveries fail TLS checks.
DANE (RFC 7672) uses DNSSEC-signed TLSA records to tell senders exactly which certificate to expect, so a forged certificate is rejected.

Our MTA-STS guide explains the records and how to roll them out safely.

Encryption at rest and backups

At-rest encryption protects data when it is stored. It is valuable against stolen hardware and leaked backup files. It does not stop the provider's running systems from reading mail; they need to, in order to filter spam, scan for viruses, index search and show you your inbox.

Ask any provider two plain questions: are backups encrypted, and where do the keys live? Encrypted backups stored off-site, with keys kept separately from the backup files, are a sound baseline.

End-to-end encryption: S/MIME, PGP and provider systems

End-to-end encryption means the message is encrypted on the sender's device and only decrypted on the recipient's. Servers in between store and forward ciphertext they cannot read.

S/MIME uses X.509 certificates, usually issued by a certificate authority. It is built into Outlook, Apple Mail and many corporate mail apps, which makes it a reasonable fit inside organisations, or between partners, that already manage certificates. Its downsides are certificate issuance, renewal and the need to exchange certificates before the first encrypted message.

OpenPGP (PGP) uses key pairs that people generate themselves. Thunderbird supports it natively, and some privacy-focused providers build on it. It is flexible and does not depend on certificate authorities, but key verification and key management are left largely to users, which is hard to do well across a whole company.

Provider-specific E2EE. Privacy-focused services such as Proton Mail encrypt mail end-to-end between their own users automatically and use password-protected messages or OpenPGP for outside recipients. This is a genuine strength if confidentiality from the provider is your main goal. Some large business suites also offer message encryption or client-side encryption on higher tiers or as add-ons; check what each really encrypts and who holds the keys.

The trade-offs of end-to-end encryption

E2EE is powerful, but it is not free. Before you require it company-wide, weigh what you give up:

Server-side protection gets weaker. If the server cannot read a message, it cannot scan it for malware, phishing links or spam. Attackers can and do hide payloads in encrypted messages.
Search, AI features and previews that run on the server cannot see encrypted content.
Archiving and eDiscovery become harder. A compliance archive full of ciphertext only helps if someone can still decrypt it years later.
Key loss means data loss. If a user loses their private key and there is no escrow, their encrypted mail is gone.
Metadata is still visible. Sender, recipients, dates and, in many PGP setups, the subject line are not encrypted.
Recipients need to take part. Every external party must have compatible software or follow a portal or password flow.

There is also a bigger point. Most real-world email breaches come from stolen credentials and phishing, not from someone tapping a cable. If an attacker signs in as Anna in accounts, E2EE does not help: they read what Anna can read. Account security and anti-phishing usually give more protection per hour spent. See email security best practices and phishing protection for business.

What Zomail provides, and what it does not

To be clear about where Zomail sits:

Zomail provides

TLS for connections from your apps (IMAP, SMTP, CalDAV/CardDAV, webmail).
TLS between mail servers, with MTA-STS in enforce mode and TLS-RPT records set up through the guided DNS page.
Outbound DANE validation: when a recipient domain publishes DANE records, Zomail checks the certificate against them.
Encrypted off-site backups, plus layered spam, virus and phishing filtering on every message.
Account protection: 2FA (mandatory for admins), app passwords, remote sign-out, SSO with Google Workspace or Microsoft Entra ID.

Zomail does not provide

End-to-end encryption.
S/MIME or PGP features in webmail or the Zomail app: no key or certificate management, and no reading or creating of encrypted messages there.

If end-to-end encryption between your own users is a hard requirement, a privacy-focused provider is likely a better fit, and we would rather say so.

Practical options for sensitive information

Many businesses need to send a few sensitive files (payroll, contracts, ID scans) rather than encrypt everything. Practical options:

Share a link instead of attaching. Upload the file to Drive and send a share link with an expiry date. The file then does not sit in every mailbox it passed through, and you can revoke access.
Encrypt the file itself. A password-protected archive or PDF, with the password sent by another channel such as a phone call or messaging app.
Use S/MIME or PGP with specific partners where both sides already run desktop apps that support them and agree on how keys are handled.
Lock down the accounts. Enforce 2FA, review forwarding rules and train people to spot phishing. This protects everything, encrypted or not.

If enforced transport encryption, encrypted backups and strong phishing defences cover your needs, Zomail includes them, priced per mailbox per month, with current prices on the pricing page. The anti-spam and anti-phishing guide shows the settings.

FAQ

Is business email encrypted by default?

The connection between your app and a reputable provider is almost always encrypted with TLS. Server-to-server delivery uses TLS when both sides support it; MTA-STS and DANE make that mandatory rather than optional. The content is not end-to-end encrypted unless you use S/MIME, PGP or a provider built for it.

What is the difference between TLS and end-to-end encryption?

TLS encrypts each hop of the journey, so providers can read the message at each stop. End-to-end encryption encrypts the message itself, so only the sender and recipient can read it, and servers cannot.

Does Zomail support S/MIME or PGP?

No. Zomail provides TLS in transit with MTA-STS enforcement and outbound DANE, plus encrypted backups, but not end-to-end encryption, S/MIME or PGP.

Do small businesses need end-to-end encrypted email?

Usually not for everyday mail. Enforced TLS, 2FA and good phishing protection cover the most common risks. End-to-end encryption is worth it for specific workflows or regulated data where you can manage keys and accept the trade-offs.

Is Gmail or Outlook email encrypted?

Both use TLS in transit and encrypt stored data. Standard accounts are not end-to-end encrypted, although each offers optional S/MIME or extra encryption features on certain business tiers.