S/MIME and PGP: Email Encryption from Scratch — Which One, When, and How?

Let's open with a sentence from the field — from an IT manager, verbatim: "Aren't our emails already encrypted? There's a padlock in the browser." That sentence sums up the most common misconception in email encryption. The padlock (TLS) means the email is encrypted in transit — like the courier driving an armored van. But when the email lands on a server, gets backed up, falls into the wrong mailbox, or the account is taken over, the content is wide open. The envelope itself was never sealed.

In this second article of our Mail Technologies Series we cover the two technologies that seal the envelope: S/MIME and PGP. The goal is the same as before: a guide that an IT manager with zero prior exposure can read and apply, showing the common mistakes and the right way — not definition memorization. If you haven't read the first article (SPF/DKIM/DMARC), start there; that one answers "is the sender really you," this one answers "can anyone but the recipient read the content."

1. First, the Concept: What Does TLS Protect — and What Doesn't It?

Email has three separate protection layers, and they're frequently confused:

• Transport encryption (TLS): The email is encrypted while traveling between servers. Standard between major providers today. But it's not end-to-end — the email sits in the clear on every server.
• Authentication (SPF/DKIM/DMARC): Verifies the sender's authenticity; encrypts nothing.
• Message encryption (S/MIME, PGP): Encrypts the email's content; only the intended recipient can open it. Even if a server is breached, a backup leaks, or the email goes to the wrong person, the content stays unreadable. This layer is today's topic.

The short rule: TLS protects the road; S/MIME/PGP seal the envelope. If you carry sensitive content (financial data, health data, contracts, technical drawings), you need both.

2. S/MIME — The Corporate Standard

S/MIME (Secure/Multipurpose Internet Mail Extensions) is certificate-based: your identity is vouched for by an email certificate signed by a trusted certificate authority (CA). It does two things: digital signing (proves the email came from you and wasn't altered) and encryption (ensures only the recipient can open the content).

How to set it up (with Microsoft 365 as the example)

1. Obtain certificates: An S/MIME certificate per employee from a CA. In corporate scenarios this is done centrally (distributed via MDM/Intune or GPO) rather than purchased one by one.
2. Install the certificate: The certificate (.pfx) is installed on the user's device; in Outlook it's selected under Settings → Trust Center → Email Security as the signing/encryption certificate.
3. Exchange public keys: To send encrypted email you need the recipient's public key (certificate). Simplest path: the other side sends you one signed email; Outlook stores the certificate with the contact.
4. Sign and encrypt: The "Sign" and/or "Encrypt" buttons are now active. First test: mutual signed emails → then an encrypted one.

Common mistakes → the right way

• Mistake: leaving the private key as a single copy on the device. When the device dies or the employee leaves, all past emails encrypted with that key become permanently unreadable. The right way: a key backup/escrow policy — in corporate deployments certificates are centrally backed up.
• Mistake: not noticing an expired certificate. One day your signatures start showing as "invalid" and the other side thinks you're fake. The right way: tie the certificate lifecycle to central management, not a calendar; automate renewal.
• Mistake: confusing "signing" with "encrypting." A signature proves identity but the content is open; encryption closes the content. A sensitive attachment sent "signed but unencrypted" is less protected than assumed. The right way: both together for sensitive content.
• Mistake: sending an encrypted file's password through the same channel. If the encrypted file and its password sit in the same email thread, the encryption is theater. The right way: a second channel (SMS, phone) — or S/MIME/PGP, which need no password at all.

3. PGP — The Flexible, Independent Alternative

PGP (Pretty Good Privacy; the open standard is OpenPGP) needs no CA: every user generates their own key pair — a public key (distributed to everyone) and a private key (never shared). Trust rests not on a certificate authority but on being sure the key really came from the right person.

How to set it up (summary flow)

1. Pick a tool: Gpg4win (Kleopatra) on Windows, GPG Suite on macOS; Thunderbird has OpenPGP built in.
2. Generate a key pair: A 3072/4096-bit RSA (or modern ECC) key with name + email; the private key is protected by a strong passphrase.
3. Share the public key: Put it on your website, add the fingerprint to your email signature, or send it directly. You also obtain and verify the other side's key (confirming the fingerprint by phone is the cleanest method).
4. Encrypt/sign: The tool integrates with your mail client; it encrypts with the recipient's public key and signs with your private key.

Common mistakes → the right way

• Mistake: losing the private-key passphrase / not backing up the key. PGP has no "forgot my password" button. The right way: back up the key + a revocation certificate at generation time; store offline.
• Mistake: trusting a key without verifying the fingerprint. An attacker can publish a fake key under the target's name. The right way: confirm the fingerprint through a second channel on first exchange.
• Mistake: forgetting the subject line isn't encrypted. PGP (and S/MIME) encrypt the body and attachments; the subject line and recipient information stay open. The right way: no sensitive information in the subject (a subject like "Company X acquisition contract" defeats the encrypted body).

4. Which One, When? (Plus a Türkiye-Specific Note: KEP)

• Corporate, continuous, multi-user need → S/MIME. Native fit with Outlook/Microsoft 365 and mobile clients, central deployment and management. The natural choice for departments with regular sensitive correspondence (finance, legal, HR).
• External, expert-to-expert, ad-hoc need → PGP. No CA cost, no dependence on the other party's corporate infrastructure. Security researchers, journalists, high-sensitivity exchanges with individual external parties.
• Türkiye-specific note — don't confuse with KEP: KEP (Registered Electronic Mail) provides legal evidentiary value for delivery (who, to whom, when — it substitutes official notification); end-to-end confidentiality of the content is a separate matter. KEP is for official notice, S/MIME/PGP for content confidentiality; neither replaces the other — they're combined as needed.

5. One Level Up: Corporate Encryption Without the Certificate Burden

Let's be honest: corporate S/MIME deployment (certificate lifecycle, key escrow, counterpart compatibility) demands real operations; PGP shines in external individual scenarios but is hard to scale to hundreds of employees. For exactly this gap there's a third way: policy-based encryption.

With Check Point Harmony Email & Collaboration it works like this: the DLP engine classifies outgoing email by content (IBAN, national ID, health data, a "confidential"-stamped attachment...); email matching a policy is encrypted automatically. The recipient authenticates in a secure browser portal and reads the message — no certificate, key, or installation needed on their side. The employee never has to remember to press a button; the "HR forgot to encrypt the payroll file" scenario disappears. It doesn't replace S/MIME/PGP — it's the complementary layer that takes human error out of the loop.

Frequently Asked Questions

Isn't Microsoft 365's own message encryption (OME/Purview) enough?

Purview Message Encryption is a practical tool and sufficient in many scenarios; but it depends on license tier, offers limited policy flexibility, and often leaves the encryption decision to the user labeling correctly. It's at its strongest combined with content-aware automatic DLP classification.

Does encryption also stop phishing?

No — this distinction must be made clearly. Encryption provides confidentiality (nobody can read the content); phishing/BEC defense is a separate layer. A signed-and-encrypted-looking email coming from a compromised real account can even create a false sense of trust. The two layers complement each other; they don't substitute.

The other side has no infrastructure at all — can I still send encrypted?

S/MIME/PGP require the other side's key/certificate. If they have no setup, portal-based policy encryption (section 5 above) exists for exactly this scenario: the recipient reads with nothing but a browser, after verifying their identity.

What happens to encrypted emails when an employee leaves?

If key escrow is in place, the organization retains access within its legal retention obligations. If not, the emails are permanently sealed — which is exactly why writing the escrow policy before starting an S/MIME rollout is critical.

What Should You Do Now?

Ask yourself two questions: (1) How do your finance/legal/HR teams send sensitive content today? (2) Is the "remember to encrypt" decision tied to a person or to a policy? If the answer to the second is "a person":

1. Free Field Audit: We photograph your outbound sensitive-data flow (from a DLP perspective) and report the encryption gaps.
2. Policy-based encryption demo: An end-to-end walkthrough on Harmony Email with your real scenarios (an email carrying an IBAN, a personnel file, a contract attachment).

Schedule an intro meeting

About this article: The second article of our Mail Technologies Series; the next will cover transport-layer security with MTA-STS and TLS-RPT (the continuation of this article's "TLS protects the road" line). Kinetik Bilişim is the Türkiye partner of Check Point Software Technologies at the Advanced Partner 2026 level, holding Email, Endpoint & Browser, Mobile, and SASE Solution Specialization accreditations. The author, Kemal Özleyen, is a cybersecurity engineer certified as a Check Point Workspace Security Expert.