Email Encryption for Business: TLS, S/MIME, and What Actually Protects You

Email was not designed with privacy in mind. The original SMTP protocol sends messages in plaintext by default, which means anyone with access to the right network path could potentially read them. Over the decades, several layers of encryption have been added to address this — but they protect different things, work in fundamentally different ways, and not all of them are relevant to every business. Understanding email encryption starts with knowing what you're actually trying to protect and from whom.

Encryption in Transit vs. Encryption at Rest

These are two separate concepts that often get conflated in conversations about email security.

Encryption in transit protects your message while it travels from server to server across the internet. If the connection between sending and receiving mail servers is encrypted, a network eavesdropper can't read your message as it moves. TLS handles this layer.

Encryption at rest protects messages that are stored on servers — your mail server's disk, your provider's infrastructure, your email client's local database. If a server is compromised, encryption at rest determines whether stored messages are readable by an attacker. This is handled by full-disk encryption, encrypted storage volumes, or message-level encryption like S/MIME.

Most business email setups have reasonable encryption in transit. Far fewer have meaningful encryption at rest or end-to-end message encryption — which means a server compromise can still expose stored messages even when transit is secure.

TLS: The Foundation of Encrypted Email Delivery

TLS (Transport Layer Security) is what protects the connection between mail servers when your email travels from your provider to the recipient's provider. When both servers support TLS, the connection is encrypted and your message can't be read in transit by a passive observer on the network.

The challenge is that standard TLS for email is opportunistic — if the receiving server doesn't support it, most sending servers will fall back to an unencrypted connection rather than refuse delivery. This is where standards like MTA-STS come in. MTA-STS lets you publish a policy declaring that your domain will only accept TLS-encrypted inbound connections, preventing opportunistic downgrades to plaintext.

For most businesses, ensuring TLS is properly configured on your sending infrastructure is the single highest-impact step for email security in transit.

STARTTLS vs. Implicit TLS

Two common encryption modes appear in email settings, and they're often confused:

• STARTTLS: The connection starts unencrypted, then upgrades to TLS mid-session using an explicit command. Standard on SMTP submission port 587 and IMAP port 143.
• Implicit TLS (sometimes called SSL/TLS): The connection is encrypted from the very first byte. Used on SMTP port 465 and IMAP port 993.

Both provide strong encryption when implemented correctly. The meaningful difference is that STARTTLS has a theoretical vulnerability if the upgrade step can be stripped by a man-in-the-middle — which is why MTA-STS and STARTTLS Everywhere initiatives exist at the server-to-server level.

S/MIME: End-to-End Encryption for Email Content

S/MIME (Secure/Multipurpose Internet Mail Extensions) provides genuine end-to-end encryption for message content. When you send an S/MIME-encrypted email, the message body is encrypted using the recipient's public key. Only the recipient's private key can decrypt it — not your email provider, not their email provider, not any server in between.

S/MIME also supports digital signatures. A signed message proves to the recipient that it genuinely came from you (because only your private key could have produced the signature) and wasn't modified in transit.

Practical requirements for S/MIME:

• Both sender and recipient need S/MIME certificates issued by a trusted certificate authority
• Both email clients must support S/MIME — Outlook, Apple Mail, and most enterprise clients do natively
• You need to exchange certificates before encrypted communication can begin (the recipient's public key must be in your client)

S/MIME works well in closed business environments where the same set of partners communicate regularly. It's less practical for ad-hoc external communication because the certificate exchange step adds friction for both parties.

PGP: The Developer-Favorite Alternative

PGP (Pretty Good Privacy) achieves similar end-to-end encryption to S/MIME but uses a decentralized trust model — the "web of trust" — rather than certificate authorities. PGP has historically been more popular in technical communities and open-source circles.

For most businesses, S/MIME is the more practical choice because it integrates natively into enterprise email clients without additional software or plugins. PGP typically requires separate tools or browser extensions and is harder to deploy across a non-technical team.

What About Webmail and Hosted Email?

When you read email in a browser, the connection between your browser and the webmail server is encrypted via HTTPS. That protects against network eavesdropping on your active session. It does not mean the stored messages on the server are encrypted — it means the connection you're using to access them is private.

For genuine at-rest encryption of sensitive business email, the options are: a provider that offers encrypted storage using keys you control (not the provider's keys), or S/MIME so that messages arrive already encrypted before they land on the server.

Practical Recommendations by Business Size

Small businesses

Focus on TLS in transit and strong authentication. Ensure your email provider enforces TLS on inbound connections and supports MTA-STS. Enable two-factor authentication on every mailbox. This covers the overwhelming majority of realistic email security risk without adding operational complexity.

Mid-size businesses handling sensitive data

Add S/MIME for executive accounts and any role that handles financial, legal, or personal data. Work with your IT team to deploy certificates and build a simple enrollment process for relevant staff. Document which accounts are covered.

Regulated industries

Healthcare, legal, and financial organizations typically have specific compliance requirements around email encryption. Check your applicable framework — HIPAA, SOC 2, PCI DSS — to understand what's required, and document how your email infrastructure meets those requirements. Generic TLS in transit may not be sufficient for all data types.

Email encryption doesn't have to be complex to be effective. Start with the fundamentals — proper TLS configuration through a reliable SMTP infrastructure, strong account authentication, and current security settings on every email client. You'll have addressed the most likely threat vectors before adding any additional layers.

Explore how MailDog's DNS security features support encrypted email delivery, or visit maildog.io to learn more about the platform.