S/MIME & PGP Email Encryption

Email encryption has a reputation for being painful, certificates to issue, keys to distribute, and an experience that pushes recipients into clunky web portals. Most of that pain comes from doing encryption at the client. Doing it at the gateway instead makes it transparent: Hermes Secure Email Gateway can automatically encrypt outbound mail and decrypt inbound mail, so encrypted messages behave like normal, searchable mail in your users’ mailboxes. This guide explains S/MIME and PGP, and how a self-hosted gateway makes them practical.

S/MIME vs PGP: the short version

  • S/MIME uses X.509 certificates issued by a Certificate Authority (or your own internal CA). It’s built into most mail clients (Outlook, Apple Mail), which makes it the natural fit for organizations and B2B mail.
  • PGP / OpenPGP uses a decentralized web of trust rather than a central CA. It’s common among technical users and for person-to-person confidentiality.

Both encrypt message contents so only the intended recipient can read them, and both can sign mail to prove it wasn’t tampered with. The hard part has never been the math, it’s the key management and user experience.

The usual problem

Two common approaches, two kinds of friction:

  • Client-side encryption asks every user to obtain a certificate or key, install it on every device, and not lose it. Adoption stalls because it’s per-person busywork.
  • Provider “portal” encryption, such as Microsoft’s Purview Message Encryption (formerly OME) or Google’s Confidential mode, wraps the message so external recipients open it in a browser-based viewer (via an HTML attachment or a link), authenticating with a one-time passcode or sign-in. The content effectively lives on the provider’s side, not as ordinary mail. It isn’t in the recipient’s mailbox, isn’t easily searchable, and adds a step on every message.

The gateway approach

Hermes moves encryption off the client and onto the gateway, driven by policy:

Outbound: a message matching an encryption policy → Hermes encrypts (S/MIME, PGP, or password-protected PDF) → delivered to the recipient.
Inbound: an encrypted message arrives → Hermes decrypts at the gateway → delivered as normal, readable mail to the mailbox on your infrastructure.

Because the gateway holds the keys and applies the rules, individual users don’t manage certificates per device. And because the gateway can read what it decrypts, inbound encrypted mail can be scanned for malware before delivery, closing a real blind spot, since client-side encryption (including Microsoft 365’s S/MIME) hides message contents from malware, spam, and policy scanning. Decrypted mail then lands in the mailbox where it’s searchable, archivable, and yours, not stranded in an external portal. You set the policy (encrypt by recipient, domain, content match, or header), and Hermes enforces it consistently for everyone.

For recipients who can’t do S/MIME or PGP. Not every recipient has a certificate or key. Hermes can fall back to delivering the message as a password-protected (encrypted) PDF, so the content is still protected in transit and at rest on the other end, without requiring the recipient to set anything up.

Gateway-managed or end-to-end: your choice

Transparent gateway encryption is the right default for most organizations, but it isn’t the only mode, and the difference comes down to who holds the keys:

  • Keys Hermes manages → the gateway encrypts and decrypts, so mail is scannable, policy-enforced, and lands as normal searchable mail. The plaintext is only ever exposed on your own self-hosted server, not a third-party cloud.
  • Keys Hermes doesn’t hold → for true client-to-client S/MIME or PGP, the gateway simply relays the encrypted message untouched. It stays end-to-end, and not even your own gateway can read it.

The only inherent trade-off: pass-through end-to-end mail can’t be scanned, because nothing in the middle can read it, while gateway-managed mail can. You’re not locked into one model for the whole organization; it’s decided per message by where the keys live.

What Hermes includes

  • S/MIME and PGP encryption and signing, applied at the gateway by policy.
  • Encrypted-PDF fallback for recipients without S/MIME/PGP.
  • SMTP TLS for transport encryption, and at-rest mail encryption for stored messages.
  • An internal CA so you can issue S/MIME certificates for your own users without buying them per seat.

All of this is part of the free, open-source Community Edition, encryption isn’t held back for a paid tier.

Getting started

  1. Stand up Hermes. → Installation
  2. Configure encryption settings and policies (when and how to encrypt). → Encryption · Encryption Settings
  3. Set up S/MIME certificates, use your internal CA or import existing certs. → Internal CA
  4. Configure PGP key handling for partners and users. → PGP Key Servers

This page covers the concepts and the why; the exact configuration steps live in the Administrator Guide.

A note on interoperability

Gateway encryption removes the work for your side, but the recipient still has to be able to open what you send: S/MIME and PGP require the recipient’s client to support the standard, which is why the encrypted-PDF fallback exists for everyone else. Plan your policies around who you actually correspond with.

Try it

Encryption is included in the free Hermes Community Edition. Pro adds time-of-click Link Guard and more, with a free trial, no credit card required.

Start a free trial See all features