Email Encryption Protocols Explained: TLS, S/MIME and PGP

Why do email encryption protocols matter to a business?

Because "encrypting email" means three different things, and a vendor claiming to "encrypt all your email" could mean any of them. The protocol determines whether you are protecting the connection between servers or the message contents end-to-end. Knowing the difference lets you evaluate claims accurately and match controls to real risk.

When an IT manager talks about encryption, the conversation splits along protocol lines. A salesperson describing "encrypted email" may mean transport encryption, true end-to-end message encryption, or something in between. Understanding the protocols below is the difference between buying confidence and buying confidentiality. It also underpins broader email security decisions and your Microsoft 365 security posture.

How does TLS (Transport Layer Security) work?

TLS encrypts the connection between two mail servers while a message is in transit. When your server sends an email, TLS opens an encrypted tunnel for that hop, preventing interception as the message crosses the public internet. It protects email on the wire, not email at rest.

The defining characteristic of TLS is that it is hop-by-hop. It encrypts each server-to-server connection, but the message itself is stored unencrypted on every mail server it passes through. If an attacker has access to a mail server, TLS provides no protection for the messages sitting on it.

What is STARTTLS, and what is enforced TLS?

STARTTLS is the mechanism mail servers use to negotiate whether to encrypt a given connection. The two modes matter:

• Opportunistic STARTTLS: use TLS if the receiving server supports it, send unencrypted if not.
• Enforced TLS: reject or hold the message if TLS is unavailable on the receiving end.

For businesses that routinely exchange sensitive data with known partners — a law firm and its client, a GP practice and a hospital — enforced TLS between those specific domains gives a meaningful transport guarantee. The NCSC recommends TLS as a baseline through its Mail Check guidance (ncsc.gov.uk).

When should you use TLS?

• As a baseline for all outbound email — most modern services use opportunistic TLS automatically.
• Enforced TLS with named partner domains where sensitive data is exchanged regularly.
• As part of meeting NCSC Mail Check and DMARC recommendations.

How does S/MIME (Secure/Multipurpose Internet Mail Extensions) work?

S/MIME provides end-to-end encryption using asymmetric cryptography. Each user holds a key pair: a public key shared with others and a private key kept secret. A sender encrypts with your public key, and only your private key — which never leaves your device — can decrypt the message. The mail servers in between never see plain text.

S/MIME also delivers digital signatures. When you sign with your private key, recipients verify with your public key that the message genuinely came from you and was not altered in transit. That is valuable for anti-spoofing and non-repudiation: a signer cannot later deny having sent a signed message. It pairs naturally with strong phishing protection.

What certificates does S/MIME require?

S/MIME requires each user to hold a personal email certificate issued by a trusted Certificate Authority (CA). Certificates are available from providers such as Sectigo, GlobalSign and DigiCert, typically costing £20–£80 per user per year at 2026 UK market rates. The certificate binds the user's email address to their public key and is validated by the CA.

Certificates must be exchanged between correspondents before encrypted messages can flow — each party needs the other's public key. In practice this is done by sending a digitally signed email first, letting the recipient extract and store the sender's public key for future encrypted correspondence.

How does S/MIME integrate with business email?

S/MIME integrates natively with Microsoft Outlook, Apple Mail and most enterprise clients. Configuration requires certificates installed in the user's email client and device certificate store. In a managed environment this is automated via Group Policy or Mobile Device Management. Microsoft documents native S/MIME support across Outlook (learn.microsoft.com).

When should you use S/MIME?

• Organisations regularly exchanging sensitive data with identified external parties willing to use S/MIME.
• Legal, financial and healthcare contexts where end-to-end encryption and non-repudiation are required.
• Internal communications where a certificate infrastructure already exists.

How does PGP (Pretty Good Privacy) work?

PGP also uses asymmetric cryptography for end-to-end encryption, but differs from S/MIME in key distribution. Instead of Certificate Authorities, PGP uses a web-of-trust: users sign each other's public keys to vouch for authenticity, and trust builds through the network of signatures rather than a central CA.

The OpenPGP standard (RFC 4880) is the open specification implemented by tools such as GnuPG. ProtonMail, for example, uses PGP to encrypt email between ProtonMail users automatically.

Why is PGP a poor fit for most businesses?

PGP is technically sound but awkward in most business email environments. Key management — distributing, verifying and revoking keys — demands real user technical literacy. There is no native Outlook support without third-party plugins. The web-of-trust model translates badly to corporate settings where staff turn over and IT manages identity centrally.

PGP earns its place in specific cases: secure contact with security researchers or journalists, or environments where both parties are technically proficient and already run a PGP key infrastructure.

How do TLS, S/MIME and PGP compare?

In short: TLS protects the connection, while S/MIME and PGP protect the message. TLS is trivial to deploy but stops at the server door. S/MIME gives end-to-end protection with the best business-client integration. PGP gives end-to-end protection without a CA, at the cost of heavier key management.

What should a UK SME actually do?

For most UK SMEs, layer the protocols rather than picking one. Start with transport encryption everywhere, enforce it with sensitive partners, add Microsoft 365 Message Encryption for ad-hoc secure messaging, and reserve S/MIME for teams with genuine end-to-end requirements.

The practical sequence AMVIA recommends:

1. Ensure TLS is active on all outbound mail — it almost certainly is on Microsoft 365 or Google Workspace. 2. Configure enforced TLS with any partner domains where sensitive data is exchanged regularly. 3. Implement Microsoft 365 Message Encryption (OME) for ad-hoc encrypted messaging where no S/MIME infrastructure exists (microsoft.com/en-gb/security). 4. Adopt S/MIME for teams that routinely exchange sensitive correspondence with identified external parties.

Encryption is one layer. It works alongside authentication (SPF, DKIM, DMARC), Microsoft Defender for Business and your wider GDPR cybersecurity obligations. One provider, security-first, Microsoft-certified — that is how AMVIA assembles the full picture.