You assume your email is private because you see a padlock icon in your browser. That icon means your connection to your mail provider is encrypted, not that your message is hidden from the provider itself. The standard encryption for email is transport-layer, protecting data as it moves. The companies that handle your mail can still read every word. To hide the content from everyone except the intended recipient, you need end-to-end encryption. This is what systems like PGP and S/MIME attempt to provide for email, but their protection is narrow and their adoption is fraught. Understanding the gap between what they encrypt and what they leave exposed is essential for knowing when to use them and when to choose a different tool entirely.
Transport Encryption is Not End-to-End
When you send an email from your Gmail account to a colleague's Outlook address, the padlock signifies Transport Layer Security (TLS). This encrypts the connection between your browser and Google's servers, and, if the receiving service supports it, between Google's servers and Microsoft's servers. It is a tunnel, not a sealed envelope. At every stop—your provider's servers, the recipient's provider's servers—the email is decrypted, processed, logged, and potentially scanned. The providers have full access to the plain text of your message, its attachments, and all associated metadata. This architecture is why a court order or a breach at the email company can expose your entire correspondence. Transport encryption protects against a wiretapper on the network, not against the postmaster reading your mail.
The Two Paths to End-to-End Email Encryption
To prevent the providers from reading your message, you must encrypt the content yourself before it leaves your device, in a way that only the recipient can decrypt. This is end-to-end encryption. For email, two main systems exist: PGP and S/MIME. They work on the same principle—asymmetric cryptography using a public and private key pair—but differ fundamentally in how they establish trust.
PGP, which stands for Pretty Good Privacy, is a decentralised system. You generate your own key pair. You share your public key freely, perhaps by posting it on your website or a keyserver. The recipient uses that public key to encrypt a message to you, which only your corresponding private key can decrypt. Trust is established through a "web of trust," where people sign each other's keys to vouch for their authenticity. It gives you full control but places the entire burden of key management and verification on you.
S/MIME, or Secure/Multipurpose Internet Mail Extensions, relies on a centralised trust model: the X.509 certificate system, the same one that secures websites. You obtain a digital certificate from a trusted Certificate Authority (CA). Your public key is embedded within this certificate. When you send an S/MIME-signed email, the recipient's client can verify the certificate's validity against the CA's root of trust. This model is common in corporate and governmental environments where an organisation can issue and manage certificates for its employees, integrating with existing directory services. The trust is outsourced to the CA.
What Encrypted Email Still Reveals
Even with PGP or S/MIME correctly implemented, a significant portion of your communication remains in plain sight. This is the metadata, the data about the data, which can be as revealing as the content itself. End-to-end encryption typically only protects the body of the email and its direct attachments.
The following elements are almost always left unencrypted and visible to every server that handles the message:
- Sender and recipient addresses: The 'From', 'To', and 'Cc' fields.
- The subject line: While it is technically possible to encrypt the subject with PGP, most common implementations and all S/MIME usage leave it in plain text.
- Timestamp: The date and time the message was sent.
- Message size.
This metadata creates a detailed map of your contacts, habits, and relationships. As explored in the analysis of communication patterns, who you talk to and when can reveal a great deal, even if the 'what' remains secret. An adversary seeing a flurry of encrypted emails with subjects like "Urgent: Board Meeting Follow-up" between a CEO and a law firm can infer a crisis without reading a single line of the body text.
The Practical Hurdles of Key Management
The security of any asymmetric encryption system rests entirely on the protection of private keys and the assurance that public keys are genuine. This is the core challenge. If you lose access to your private key—through a device failure without a backup, for instance—every message ever encrypted to that key is lost forever. There is no "password reset" for PGP.
Conversely, if someone else steals your private key, they can decrypt all your future messages and impersonate you by signing messages as you. Protecting this key is paramount. In the S/MIME model, if an organisation's certificate authority is compromised, an attacker can issue fraudulent certificates to impersonate any employee. The security of the system is only as strong as the weakest point in its key management, a principle central to understanding who holds the decryption key in any system.
Furthermore, both systems require all parties to participate. You cannot send an end-to-end encrypted email to someone who has not set up PGP or obtained an S/MIME certificate. This creates a network effect problem: the tool is useless until a critical mass of your contacts adopt it.
Alternatives and When to Use Encrypted Email
Given these limitations, when does it make sense to use PGP or S/MIME? They are most viable in defined, technical communities where participants are motivated to manage keys, or in structured organisations that can deploy and manage S/MIME certificates centrally for internal communication. They are solutions for encrypting the content of an email channel that must, for legacy or compliance reasons, remain an email channel.
For the vast majority of personal and sensitive communications, you are better served by moving the conversation to a platform designed for end-to-end encryption from the ground up. A dedicated private messaging app like Signal handles key exchange, verification, and encryption transparently, protects metadata more aggressively, and works smoothly across contacts. For sending a sensitive document, consider using a service with client-side, browser-level encryption for a file, and sending the decryption link via a separate channel.
Use encrypted email when you must prove the authenticity of a formal communication (via S/MIME signing) or when you are corresponding with a known entity in a context where email is the mandated protocol. For spontaneous, private conversation with friends, colleagues, or sources, choose a tool where privacy is the default, not a complex add-on.
Questions people ask
What's the difference between the padlock in my webmail and PGP?
The padlock in your browser indicates Transport Layer Security (TLS), which encrypts data between your device and the email provider's server. It does not stop your provider from reading your emails. PGP is an add-on that provides end-to-end encryption, meaning you encrypt the message content on your device so that only the recipient with the correct private key can read it. The provider only sees encrypted gibberish.
Can I use PGP with my normal webmail like Gmail or Outlook?
You can, but it requires extra steps. Standard webmail interfaces do not natively support PGP. You need to use a browser extension (like Mailvelope) or a dedicated desktop email client (like Thunderbird with the Enigmail add-on) that can manage your PGP keys and perform the encryption and decryption before the mail is handed to the web service. It is not a smooth experience.
If I lose my PGP private key, can I recover my old emails?
No. There is no recovery mechanism. Messages encrypted to a lost private key are permanently inaccessible. This is a fundamental property of proper end-to-end encryption: if the key is gone, the data is gone. This underscores the absolute necessity of securely backing up your private key in a safe location.
Do companies like ProtonMail offer real end-to-end encryption?
Yes, but with an important caveat. Services like ProtonMail provide end-to-end encryption between their own users transparently. However, when you send an email to someone using Gmail, they cannot force end-to-end encryption on the other side. In such cases, they typically send an unencrypted email or provide a link to a ProtonMail-encrypted portal, which requires the recipient to take an extra step. The encryption is smooth only within their own ecosystem.
Close
PGP and S/MIME are powerful tools for a specific problem: applying end-to-end encryption to the email protocol. They are not, however, a general solution for private communication. Their complexity, their failure to protect metadata, and their reliance on universal adoption are significant barriers. For most people, the pursuit of email encryption is a distraction from simpler, more effective alternatives. The real lesson is to match the tool to the task. Use encrypted email for its narrow, formal purposes. For actual private conversation, use a system built for that purpose from the start, where the encryption is invisible to you and comprehensive in its protection. Your security should not depend on your ability to manage cryptographic keys; it should be woven into the fabric of the tool you use every day.