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

Why Understanding Protocols Matters

When IT managers or business owners talk about 'encrypting email', the conversation quickly divides into fundamentally different approaches. A salesperson claiming their product 'encrypts all your email' may be describing transport encryption, end-to-end message encryption, or something in between. Understanding the protocols involved allows you to evaluate claims accurately and choose the approach that matches your actual security requirements.

TLS: Transport Layer Security

How TLS Works

TLS is a protocol that encrypts the connection between two mail servers when an email is in transit. When your mail server sends a message to another server, TLS establishes an encrypted tunnel for that connection, preventing interception of the message as it travels between the two servers.

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

STARTTLS

STARTTLS is the mechanism by which mail servers negotiate whether to use TLS for a given connection. Opportunistic STARTTLS means: use TLS if available, send unencrypted if not. Enforced TLS means: reject or hold the message if TLS is not available on the receiving end.

For businesses that regularly exchange sensitive information with known partners (a law firm and its client, a GP practice and a hospital), enforced TLS between those specific domains provides a meaningful transport security guarantee.

When to Use TLS

• As a baseline for all outbound email (most modern mail services use opportunistic TLS automatically)
• Enforced TLS with specific trusted partner domains for sensitive communications
• As part of compliance with NCSC mail check and DMARC recommendations

S/MIME: Secure/Multipurpose Internet Mail Extensions

How S/MIME Works

S/MIME provides end-to-end encryption using asymmetric cryptography. Each user has a key pair: a public key (shared with others) and a private key (kept secret). When someone wants to send you an encrypted email, they encrypt it with your public key. Only your private key — which never leaves your device — can decrypt it.

S/MIME also provides digital signatures. When you sign an email with your private key, recipients can verify with your public key that the message genuinely came from you and has not been altered in transit. This is valuable for anti-spoofing and non-repudiation — the sender cannot later deny having sent a signed message.

Certificate Requirements

S/MIME requires each user to have a personal email certificate issued by a trusted Certificate Authority (CA). These certificates are available from providers such as Sectigo, GlobalSign and DigiCert, typically costing £20–£80 per user per year. The certificate ties the user's identity (email address) to their public key and is validated by the CA.

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

Integration

S/MIME integrates natively with Microsoft Outlook, Apple Mail and most enterprise email clients. Configuration requires certificates to be installed in the user's email client and on their device's certificate store. In a managed environment, this can be automated via Group Policy or Mobile Device Management (MDM).

When to Use S/MIME

• Organisations that regularly exchange sensitive information with identified external parties willing to use S/MIME
• Legal, financial and healthcare sectors where end-to-end encryption and non-repudiation are required
• Internal communications within an organisation where a certificate infrastructure is already in place

PGP: Pretty Good Privacy

How PGP Works

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

The OpenPGP standard (RFC 4880) is the open version implemented by tools such as GnuPG. ProtonMail uses PGP for email encryption between ProtonMail users automatically.

Practical Limitations for Business

PGP is technically sound but poorly suited to most business email environments. Key management — distributing, verifying and revoking keys — requires user technical literacy. There is no native support in Outlook without third-party plugins. The web-of-trust model does not translate well to corporate environments where staff change and IT manages identity centrally.

PGP is appropriate for specific use cases: secure communications with security researchers or journalists, or environments where both parties are technically proficient and have an existing PGP key infrastructure.

Comparing the Three Protocols

A practical comparison:

• TLS: Transport-only, hop-by-hop. Easy to deploy, widely supported. Does not protect stored messages or provide end-to-end guarantees.
• S/MIME: End-to-end message encryption and digital signatures. Requires certificate management. Best integration with business email clients. Suitable for most UK business use cases requiring end-to-end encryption.
• PGP: End-to-end message encryption. No CA dependency. Complex key management. Best for technical users and specific use cases.

Choosing for Your Organisation

For most UK SMEs, the practical recommendation is:

1. Ensure TLS is active on all outbound mail (it almost certainly is if you use Microsoft 365 or Google Workspace)
2. Configure enforced TLS with any specific partner domains where sensitive data is regularly exchanged
3. Implement Microsoft 365 OME for ad-hoc encrypted messaging where S/MIME infrastructure is not in place
4. Consider S/MIME for teams that regularly exchange sensitive correspondence with identified external parties

AMVIA's email security team can assess your current configuration and recommend the appropriate encryption approach for your specific business context and regulatory requirements.