98% of measured outbound email and 100% of measured inbound email used TLS, but TLS alone doesn't make an email end-to-end encrypted. To protect the message from providers and mailbox administrators, you need content encryption with OpenPGP or S/MIME, not merely a “secure send” button in webmail.
That distinction is the part most popular guides get wrong. A padlock can mean your browser has a protected connection to Gmail or Outlook, while the message still arrives as readable content at the participating mail providers. Transport protection matters, but it solves a narrower problem than many people assume.
The right answer depends on your threat model. If you're trying to stop someone on public Wi-Fi from reading traffic, TLS is a useful baseline. If you need to prevent a provider, employer, compromised mail server, or other intermediary from reading the message body, use a dedicated key-based system such as OpenPGP or S/MIME.
Understanding How Email Encryption Actually Works
Email encryption follows two separate paths. Transport encryption protects a connection while a message moves between your mail client and server, or between the sender's and recipient's mail servers. End-to-end encryption protects the message content itself, starting on the sender's device and ending only when the recipient uses a private key to decrypt it.
TLS is valuable because it reduces the risk of interception during delivery. Google reported that outbound email encrypted in transit rose from 73% to 88%, while inbound encrypted email rose from 61% to 88% by July 2017, demonstrating the broad adoption of opportunistic TLS in measured Gmail traffic (Google's email encryption measurements). More recent measured traffic reported 98% outbound and 100% inbound TLS encryption, but those figures still describe transport protection rather than mailbox-to-mailbox confidentiality (Google's TLS transparency data).
TLS protects the route, not necessarily the message
TLS works only when both participating providers support it. STARTTLS can upgrade an SMTP connection after a server advertises encryption, but advertising the capability doesn't force the connection to remain encrypted. CISA recommends that Internet-facing mail servers offer STARTTLS, disable obsolete SSLv2 and SSLv3, and remove weak 3DES and RC4 ciphers (CISA email and web security guidance).
After delivery, the provider may store the message in readable form. TLS also doesn't stop a provider, employer, or administrator with legitimate mailbox access from viewing content. A browser padlock confirms a protected browser connection, not that only the recipient can decrypt the message.
End-to-end encryption changes who holds the keys
With OpenPGP or S/MIME, the sender encrypts the message using the recipient's public key. The recipient then decrypts it with the corresponding private key. The mail provider can deliver the encrypted package, but it shouldn't be able to read the protected body without the private key.
Public-key concepts can feel abstract at first, especially if you've only used passwords. A practical introduction to cryptographic keys explained through public, private, and seed phrases is useful background before configuring email encryption.
Encryption still doesn't hide every detail. Sender, recipient, timing, and often the subject line can remain visible. If those details are sensitive, put as little information as possible in the subject and consider whether email is the right channel at all.
Practical rule: Treat TLS as a secure delivery channel. Treat OpenPGP or S/MIME as protection for the message itself.
Comparing OpenPGP and S/MIME Standards
OpenPGP and S/MIME both provide message-level encryption, but they make different assumptions about trust and administration. Choosing between them isn't mainly a question of which algorithm sounds stronger. It's a question of who manages identity, how much setup your recipients can tolerate, and whether you need a system that works across an informal network or inside a managed organization.
| Concern | OpenPGP | S/MIME |
| Trust model | Users verify public-key fingerprints and decide whom to trust | Certificates are issued and validated through certificate authorities |
| Key material | Public and private key pair | X.509 certificate with a corresponding private key |
| Best fit | Technical users, researchers, journalists, and privacy-focused correspondents | Businesses, institutions, and managed mail environments |
| Main friction | Key discovery, fingerprint verification, and client compatibility | Certificate issuance, renewal, installation, and certificate exchange |
| Signatures | Authenticate a key holder and help detect changes | Provide authentication, integrity, and proof of origin under the standard |
| Recipient experience | Requires compatible OpenPGP support | Usually integrates more naturally with organizational mail clients |
OpenPGP favors user-controlled trust
Phil Zimmermann developed PGP in 1991. The Internet Engineering Task Force later standardized PGP/MIME through RFC 2015 in 1996, followed by RFC 3156 in 2001, which defined content types for encrypted data, signatures, and keys (OpenPGP's standards history).
OpenPGP lets users generate and control their own keys. That flexibility is its strength, but it also creates responsibility. You must obtain the correct public key, verify its fingerprint through an independent channel, protect the private key, and prepare for key loss or compromise. OpenPGP historically lacked a standardized method for securely discovering a person's public key, although RFC 9787 describes DNS-based publication through an OPENPGPKEY record (RFC 9787 on OpenPGP key discovery).
S/MIME fits managed environments
S/MIME uses certificates issued through a trust hierarchy. An organization can issue certificates, publish them through its directory, and configure compatible clients to sign or encrypt messages. That centralized model usually works better when an employer controls the mail accounts and can help users with installation and renewal.
S/MIME 4.0, specified in RFC 8551 in April 2019, separates the jobs clearly. Encryption provides confidentiality, while signatures provide authentication, integrity, and proof of origin (RFC 8551 S/MIME specification). The trade-off is operational. Certificates expire, certificate chains need validation, and the sender still needs the recipient's public certificate before encryption can work.
If you're emailing a small group of technically capable people, OpenPGP gives you direct control. If your recipients work inside a managed organization, S/MIME usually creates less confusion.
Setting Up OpenPGP Encryption Step by Step
OpenPGP works best when both people agree on the workflow before sending sensitive material. Use a maintained implementation, such as a current mail client with OpenPGP support, and make sure the recipient can decrypt and verify messages before relying on it.
Build and protect your key pair
- Generate a modern key pair. Your software creates a public key for sharing and a private key that must stay under your control. Current OpenPGP formats are defined by RFC 9580, which requires AES-128 implementation and recommends AES-256. The specification also includes modern options such as X25519 and Ed25519.
- Protect the private key. Use a strong, unique passphrase that you don't reuse elsewhere. Anyone who obtains both the private key and its passphrase may be able to decrypt messages intended for you or impersonate you through signatures.
- Create a revocation certificate immediately. Store it securely and separately from the private key. If the key is lost or compromised, the certificate gives you a way to tell others that they must stop trusting it.
- Share the public key. Send it directly, publish it through a trusted channel, or use a compatible key-discovery method. A public key is safe to share, but its identity still needs verification.
Verify identity before encrypting
The most important step happens outside the email client. Compare the recipient's key fingerprint through a second channel, such as a phone call, a face-to-face meeting, or a known secure messaging conversation. Don't accept a key merely because it arrived in an email claiming to belong to your contact.
An attacker who substitutes a different public key may receive a message that appears encrypted and technically valid. The cryptography can work perfectly while protecting the wrong recipient. Verification connects the key to the person you intended to contact.
Send a signed and encrypted test message
After verifying the fingerprint, compose a short test message and select the recipient's verified public key. Enable both encryption and signing. Encryption hides the content, while the signature helps the recipient check that the message came from the expected key holder and wasn't changed after signing.
Ask the recipient to decrypt the test message and validate the signature. Only then send sensitive material. If the recipient changes devices, loses a key, or switches mail clients, repeat the compatibility check rather than assuming the old setup still works.
A browser extension or OpenPGP-capable client can make composition easier, but the trust decisions remain yours. The software can select a key, yet it can't confirm that the key belongs to the right person unless you verify it independently.
Use this short demonstration as a visual reference after you've understood the key workflow:
OpenPGP doesn't make a bad process safe. Encrypting to an unverified key, losing your private key, or leaving the subject line descriptive can still expose information. The method is strong when key ownership, client compatibility, and recovery planning are handled as part of the setup.
Configuring S/MIME Certificates for Secure Email
S/MIME is often the smoother choice when your organization already manages mail clients, employee identities, and certificates. Instead of asking every recipient to participate in a web of trust, the workflow relies on an X.509 certificate and a recognized certificate chain.
Obtain and install the certificate
Start by obtaining an X.509 certificate from your employer's IT department or a trusted certificate authority. The certificate binds your email identity to a public key. Your compatible mail client stores the certificate and its private key, which must be protected like any other credential capable of decrypting messages or creating signatures.
Install the certificate in the client or operating-system certificate store according to the software's documented process. Confirm that the client recognizes both the certificate and its private key. A certificate that appears in an account but lacks its private key may support verification without allowing you to decrypt incoming messages.
Exchange certificates with recipients
You need the recipient's public certificate before sending encrypted S/MIME email. A common way to exchange it is for the recipient to send a digitally signed message first. Your client can then use the public certificate associated with that signature for future encryption.
Certificate validation matters. Check the certificate chain, the email identity, its validity status, and whether the issuing authority is trusted by your client. Organizations should also establish a clear process for renewal and replacement, because an expired or replaced certificate can interrupt access to new messages.
Operational habit: Sign a test message before encrypting anything sensitive. A successful signature test confirms that your identity, private key, certificate chain, and recipient compatibility are working together.
Encrypt only after signing works
Once the recipient's certificate is available, compose a test message and enable encryption. The recipient uses the corresponding private key to decrypt it. Your signature lets the recipient verify identity and message integrity.
S/MIME's advantage is integration. In a managed environment, mail clients can expose familiar Sign and Encrypt controls, and administrators can help distribute certificates. Its weakness appears at the boundary of the organization, where external recipients may not have S/MIME support or may use webmail that can't process the message correctly.
Don't assume that a client's lock icon means every recipient will receive a readable encrypted message. Send a test, confirm the recipient's client can open it, and document the process for certificate renewal, device changes, and private-key recovery.
Addressing Privacy Caveats and Common Pitfalls
End-to-end encryption protects the message body, not your entire communication pattern. The subject line, sender, recipient, timestamps, routing information, and message size can remain exposed depending on the system. A subject such as “medical diagnosis attached” can reveal more than the encrypted body, so use neutral subjects and put sensitive context inside the protected message.
Encryption doesn't authenticate every request
A signed or encrypted message can still be part of a phishing attack. An attacker may compromise a trusted mailbox, persuade you to accept a malicious public key, or send a legitimate-looking request after taking control of an account. Encryption protects confidentiality and signatures can support integrity and origin checks, but neither one proves that a payment request, password reset, or file-sharing instruction is legitimate.
Phishing remains a serious problem. APWG recorded about 3.8 million phishing attacks in 2025, compared with 3.76 million in 2024, while only 7.7% of top domains were reported as fully protected by a strict DMARC reject policy in 2025 (reported phishing and DMARC figures). Those figures describe separate defenses, not a reason to replace encryption with domain authentication.
Use a layered check:
- Verify keys and certificates: Confirm fingerprints or certificate identity through a separate, trusted channel.
- Use domain authentication: SPF, DKIM, and DMARC help receiving systems handle messages that fail domain-level authentication.
- Confirm high-risk requests: Call a known number or use an established channel before sending money, credentials, or sensitive files.
- Inspect the actual protection: Confirm that the client shows message-level encryption, not just a browser padlock or successful TLS delivery.
Plan for failure before it happens
Key loss is one of the hardest practical problems. If you lose the private key, you may lose access to messages encrypted for it. If an attacker obtains it, future messages can be exposed unless you revoke and replace the key. Keep recovery material in a secure location and know how your mail client handles backups.
Recipient compatibility creates another boundary. If the recipient can't decrypt the message, don't send sensitive content and hope that a fallback will be safe. Use a secure portal, an encrypted attachment with the password shared through a separate channel, or another communication method that both people understand.
The most secure theoretical system isn't automatically the safest choice. A method that your recipients can't configure, verify, or use reliably may lead them to disable protection at the exact moment it matters.
NeoTeo covers practical security tools and tutorials, including options such as SecureGmail, Whiteout Mail, and ProtonMail, which approach protected email through browser encryption, OpenPGP support, or built-in end-to-end encryption. Visit NeoTeo to compare current technology guides and choose an email workflow you can verify and maintain.
