S/MIME and PGP: End-to-End Email Encryption Explained

S/MIME and PGP are both end-to-end email encryption standards that use public key cryptography to protect email content. S/MIME uses Certificate Authorities for centralised trust and integrates natively with Microsoft Outlook and Apple Mail, making it the standard for enterprise deployment. Email security PGP uses a decentralised web of trust and is preferred by privacy-focused users, developers, and journalists who need control without CA dependency.

If your team sends sensitive client data, legal communications, or healthcare information by email and relies only on TLS for protection, your email is encrypted in transit but fully readable to anyone with access to the mail server at either end. For genuine end-to-end protection that keeps message content confidential regardless of which servers it passes through, S/MIME or PGP is required.

What Is End-to-End Email Encryption?

End-to-end email encryption means the email is encrypted on the sender’s device and only decrypted on the recipient’s device. No one in between, including email providers, mail server administrators, or network operators, can read the content.

TLS encrypts the connection between mail servers in transit, but email is stored in plaintext on servers at both ends. End-to-end encryption using S/MIME or PGP protects the message content throughout its entire journey, including while it is stored on servers.

Encryption Type	What It Protects	When It Applies	Example Technology
TLS in transit	Email connection between servers	During SMTP delivery	STARTTLS, MTA-STS
Server-side at rest	Email stored on server	While stored on mail servers	Provider server encryption
S/MIME end-to-end	Email body and attachments	Sender device to recipient device	S/MIME with X.509 certificates
PGP end-to-end	Email body and attachments	Sender device to recipient device	GPG, OpenPGP, Proton Mail

For how TLS fits alongside end-to-end encryption, see TLS for Email: What It Means and Why It Matters.

How Does Email Encryption Work?

Email encryption uses public key cryptography, sometimes called asymmetric encryption.

Every participant has two mathematically related keys: a public key shared openly and a private key kept secret by the owner. Data encrypted with a public key can only be decrypted by the corresponding private key.

The encryption process: the sender obtains the recipient’s public key, uses it to encrypt the email, and sends the encrypted message. Only the recipient’s private key can decrypt it. Digital signatures work in reverse: the sender uses their own private key to sign the email, and the recipient uses the sender’s public key to verify both the sender’s identity and that the message was not altered after signing.

In practice, asymmetric encryption handles the key exchange while a faster symmetric key encrypts the actual message content. This hybrid approach provides both security and performance for large emails and attachments.

What Is S/MIME and How Does It Work?

S/MIME (Secure/Multipurpose Internet Mail Extensions), defined in RFC 5751, is the dominant email encryption standard for enterprise environments. It is built natively into Microsoft Outlook, Apple Mail, and iOS Mail, requiring no additional plugins for email encryption and digital signing.

S/MIME uses the same X.509 certificate infrastructure as HTTPS websites. Each user obtains an S/MIME certificate from a trusted Certificate Authority such as DigiCert, Sectigo, or GlobalSign. The certificate contains the user’s public key and is signed by the CA to verify identity.

The workflow: the sender encrypts using the recipient’s public key from their certificate. The recipient decrypts using their private key. Senders can also sign emails with their private key to prove message authenticity.

Microsoft 365 supports S/MIME natively through Outlook and Outlook on the web. Certificates distribute via Intune or Active Directory Certificate Services. For how S/MIME integrates with the full email security architecture, see Email Security Architecture: How the Full Stack Fits Together.

What Is PGP Email Encryption and How Does It Work?

PGP (Pretty Good Privacy), created by Phil Zimmermann in 1991, is an email encryption system based on public key cryptography and a decentralised web of trust. OpenPGP, defined in RFC 4880, is the open standard derived from PGP and implemented most widely by GPG (GNU Privacy Guard), a free open-source tool available for all major operating systems.

PGP users generate their own key pairs, share public keys via PGP keyservers or direct exchange, and verify each other’s keys through mutual trusted contacts rather than through a centralized CA. Practical email client integration requires plugins: GPG Suite for Apple Mail, Gpg4win for Outlook, or Enigmail for Thunderbird.

For non-technical users, Proton Mail implements OpenPGP with automatic key generation and management. Email security pgp protection through Proton Mail is functionally equivalent to a manually configured GPG setup but requires no technical knowledge from users.

What Is the Difference Between S/MIME and PGP?

S/MIME and PGP use the same underlying public key cryptography but differ fundamentally in trust model, cost, and practical deployment. The critical operational point: they are not interoperable. Both parties must use the same standard for encrypted communication to work.

Criteria	S/MIME	PGP/OpenPGP
Trust Model	Certificate Authorities (centralised)	Web of trust (decentralised)
Cost	$20-$100 per user per year	Free using GPG
Client Support	Native in Outlook, Apple Mail, iOS Mail	Requires plugin in most clients
Enterprise Deployment	Easier with existing PKI	More complex, user-managed keys
Key Management	CA-managed certificates	User or keyserver-managed
Key Revocation	CRL and OCSP via CA	User-published revocation certificates
Interoperability	Not compatible with PGP	Not compatible with S/MIME
Best Suited For	Enterprise, regulated sectors	Privacy advocates, developers, journalists

S/MIME integrates with existing enterprise PKI infrastructure. Email security PGP through Proton Mail suits teams seeking privacy without managing technical key infrastructure.

How Do You Encrypt an Email Using S/MIME?

Setting up S/MIME requires three things: an S/MIME certificate from a trusted CA, your email client configured to use it, and a public key exchange with each contact you want to send encrypted email to.

Step 1: Obtain an S/MIME certificate from DigiCert, Sectigo, or GlobalSign, or from your organization’s internal CA.

Step 2: Install the certificate in your email client by importing it through Outlook’s Certificate Manager or Apple Mail via Keychain Access.

Step 3: Send a digitally signed email to each recipient you want to exchange encrypted email with. The signed email automatically delivers your public key to the recipient.

Step 4: Import recipients’ public keys when they send you signed emails or share their certificates directly.

Step 5: When composing an email to a contact whose certificate you have imported, select the encryption option before sending.

Enterprise deployment uses Exchange Admin Center for centralized S/MIME configuration and Microsoft Intune for certificate distribution.

How Do You Encrypt an Email Using PGP?

PGP setup requires more user involvement than S/MIME but delivers equivalent encryption strength.

The technical setup using GPG:

• Download and install GPG for your operating system: gpg4win.org for Windows, GPG Suite for macOS
• Generate your PGP key pair using the GPG key generation wizard with a 4096-bit key for strong security
• Upload your public key to a PGP keyserver or share it directly with contacts
• Import recipients’ public keys into your GPG keyring
• Install your email client plugin and select the encrypt option before composing sensitive messages

For teams that need the security of OpenPGP without technical setup, Proton Mail handles all key generation and management automatically within its encrypted email platform.

What Is an Email Encryption Certificate?

An email encryption certificate is a digital X.509 certificate containing the owner’s public key for S/MIME encryption and digital signing. Certificates are issued by Certificate Authorities and come in three validation classes that most S/MIME guides never explain.

Class 1 S/MIME certificates verify only that the applicant controls the email address. No identity is verified beyond inbox access. The certificate proves someone controls that inbox, not who that person is or what organization they represent. Class 2 certificates verify both the email address and the organization’s existence and registration. Class 3 requires in-person identity verification, providing the strongest available identity assurance.

For legal professionals, healthcare providers, and financial services firms using S/MIME to protect privileged or regulated communications, Class 1 certificates provide weaker identity assurance than the use case demands. Class 2 or Class 3 is appropriate when the counterparty’s identity matters legally or for compliance purposes.

The private key loss scenario is equally underaddressed. If a user’s S/MIME private key is lost, whether through device failure, employee departure, or hardware replacement without backup, every email encrypted to that user’s public key becomes permanently unreadable. No Certificate Authority can recover it. For organizations archiving encrypted email for legal discovery or compliance purposes, private key backup through a key escrow procedure is mandatory. Without it, encrypted email archives become permanently inaccessible when keys are lost.

Certificate lifespans typically run one to three years. Renewal must complete before expiry to prevent TLS negotiation failures and decryption errors for archived email.

What Are the Limitations of End-to-End Email Encryption?

End-to-end email encryption provides strong message-level protection but carries operational limitations organizations must plan for before deploying S/MIME or PGP at scale.

The conflict between E2EE and email security scanning is the limitation that almost no competitor article covers.

When S/MIME or PGP encrypted email arrives at a recipient’s mail gateway, the security gateway, anti-malware scanner, and DLP system cannot read the encrypted content. They see an opaque message and pass it through. A malicious actor who knows the target uses E2EE can deliberately encrypt a message containing a malware attachment. The encrypted attachment bypasses every gateway security control because decryption only happens on the recipient’s device after the message has passed through all scanning infrastructure. This is not a theoretical concern. It is the direct and documented trade-off between content confidentiality and content security that organizations must explicitly plan around when deploying E2EE.

The second underaddressed limitation is metadata exposure. S/MIME and PGP encrypt the email body and attachments but leave the subject line, sender address, recipient address, and timestamps completely unprotected. An organization that deploys E2EE and believes its communications are fully confidential may not realize that subject lines such as “Re: merger with XYZ Corp” or “Patient case notes for [Name]” remain visible in plaintext to every mail server administrator in the delivery chain.

Remaining practical limitations include: both parties must use the same standard before any encrypted communication is possible; private key loss permanently destroys access to archived encrypted email; mobile device setup for S/MIME and PGP is more complex than desktop; and user friction from certificate and key management leads to inconsistent adoption without enterprise-level enforcement.

For DLP compliance alongside encrypted communications, see Email DLP: How to Prevent Data Leaks Through Email.

When Do You Need End-to-End Email Encryption?

End-to-end email encryption is appropriate when email content must remain confidential even from email providers and server administrators.

Use cases where E2EE is mandatory or strongly recommended include:

• Legal communications with solicitor-client privilege, where unauthorized disclosure carries professional and legal consequences
• Healthcare email transmitting protected health information (PHI) under HIPAA Security Rule technical safeguard requirements
• Financial services handling merger and acquisition information, client investment data, or price-sensitive communications
• Executive board-level communications covering personnel matters, acquisition plans, or strategic decisions
• Intellectual property disclosure including trade secrets, product development details, and competitive intelligence
• Any data subject to GDPR Article 32 requirements for appropriate technical measures, where encryption is specified as the standard

For HIPAA-specific email encryption requirements and implementation guidance, see HIPAA Email Security: Requirements for Covered Entities. Cyber Security Solutions Ltd can advise on choosing and deploying the right encryption approach for your specific compliance obligations.

Conclusion

S/MIME provides the most practical path to end-to-end email encryption for enterprise organizations, while email security PGP through Proton Mail or GPG suits privacy-focused individuals and technical teams. Both deliver genuine message-level protection that TLS cannot. The trade-off between E2EE and security scanning must be understood before deployment at scale. To get expert guidance on implementing the right email encryption approach for your compliance requirements, visit cybersecuritysolutionsltd.com.