S/MIME email encryption: how it works and when to use it

S/MIME, short for Secure/Multipurpose Internet Mail Extensions, is a standard for signing and encrypting email so that only the intended recipient can read it and the sender can be verified. It works with public-key cryptography and X.509 certificates: you encrypt a message to the recipient's public key so only their private key can open it, and you sign it with your own private key so the recipient can confirm it really came from you. Defined in RFC 8551, S/MIME is built directly into mail clients like Outlook and Apple Mail, which makes it the default enterprise choice for confidential and authenticated email. It gives you confidentiality and authenticity together, but it does not protect everything, and it is famously awkward to drive from code.

How S/MIME encryption works

S/MIME rests on the same trust model that secures HTTPS. Each user has an X.509 certificate that binds their email address to a public key, and that certificate is issued and signed by a certificate authority (CA). Your mail client already trusts a set of root CAs, so when it sees a certificate chaining up to one of them, it accepts that the public key really belongs to the address on it. This is a strict hierarchy: a root CA vouches for intermediate CAs, which vouch for individual certificates, and trust flows down from the top.

Underneath the certificate is a public and private keypair. The two operations S/MIME performs map directly onto that pair:

• Encrypt to the recipient's public key. To send confidential mail, your client fetches the recipient's certificate, pulls out their public key, and encrypts the message to it. Only the matching private key, held by the recipient, can decrypt it. In practice this is hybrid encryption: a random symmetric key encrypts the body, and that symmetric key is wrapped to the recipient's public key.
• Sign with your own private key. Your client hashes the message and signs it with your private key. The recipient verifies the signature with your public key, taken from your certificate, confirming both that the message came from you and that it was not altered in transit.

Do both at once and you get confidentiality plus authenticity in a single message. Because Outlook and Apple Mail ship S/MIME support natively, inside a corporate directory where IT provisions certificates it can feel almost invisible to the user.

Getting and using an S/MIME certificate

The friction starts before you send a single message. You have to obtain a certificate from a CA, and for anything beyond a self-signed test certificate that usually means a paid product from a commercial authority or an internal enterprise CA. Once issued, you install the certificate and its private key into your mail client's certificate store so it can sign and decrypt.

Then you hit the chicken-and-egg problem. To encrypt a message to someone, you need their certificate first, and you cannot pull it out of thin air. The standard bootstrap is to trade a signed email: one party sends a signed but unencrypted message, the signature carries their certificate, the client stores it, and only then can the other side encrypt a reply. Until both sides have exchanged certificates, encryption is not possible.

Certificates also expire, typically after a year or two, so there is ongoing renewal and lifecycle management: reissuing before expiry, distributing the new certificate, and revoking compromised ones. For a broader tour of the options here, see the email encryption guide.

What S/MIME does not protect

S/MIME encrypts the message body and attachments, but it leaves a real amount of information exposed, and it is worth being blunt about the gaps.

• The Subject line and headers travel in the clear. Standard S/MIME per RFC 8551 encrypts the MIME body, but the RFC 5322 headers, including From, To, Date, and Subject, are not part of that encrypted body. A subject like "Q3 acquisition terms" is visible to anyone watching the wire or reading the server. The metadata leaks even when the content does not.
• Trust is centralized in the CA. You inherit whatever a certificate authority decides. A mis-issued or compromised CA can undermine the guarantee, and you have no say in that chain.
• Cross-organization exchange is clumsy. Inside one directory it is smooth, but exchanging certificates between organizations usually means trading signed emails and hoping both clients handle the certificates cleanly.
• It is hard to drive from code. S/MIME lives inside desktop mail clients and their certificate stores. Wiring it into a server, a CI job, or an autonomous agent means wrestling with certificate files, key stores, and libraries that were never designed for hands-off automation.

S/MIME vs PGP

S/MIME and PGP solve the same problem with opposite trust models. S/MIME uses CA-issued X.509 certificates: a central authority vouches that a key belongs to an address, and your client trusts the authority. PGP uses a peer-to-peer web of trust: there is no central authority, and users sign each other's keys to vouch for them directly. S/MIME tends to win inside enterprises that already run a certificate authority, while PGP took hold among privacy-focused individuals who did not want to depend on a CA. Neither protects the subject line, and neither is pleasant to automate. For the full breakdown of PGP's web of trust and why it never went mainstream, see the PGP deep-dive.

A modern alternative for automated and agent email

If the job is to encrypt mail that programs send and receive, the certificate machinery is the wrong shape. Web and API developers already solved "sign and encrypt a small payload, then verify it in any language" with JOSE, the JSON Object Signing and Encryption family. Its two workhorses are JWE (JSON Web Encryption) for confidentiality and JWS (JSON Web Signature) for authenticity, and their keys are plain JSON objects called JWKs. Every mainstream language has a mature JOSE library, such as the npm jose library or the Python jwcrypto library, so there is no shelling out to a binary and no certificate store on disk.

The trust problem gets a leaner answer too: published-key discovery by address. Instead of a CA hierarchy or a keyserver full of unverified uploads, each address publishes its public key at a predictable location, and the sender resolves it by address at send time. A recipient's published encryption key is just a JWK:

{
  "kty": "EC",
  "crv": "P-256",
  "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
  "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
  "use": "enc",
  "kid": "agent-42@inbox.agenticemail.dev"
}

Because the whole message lives inside the encrypted JWE, the subject can travel inside the sealed payload instead of an exposed header, closing the exact gap that S/MIME and PGP leave open. There is no certificate to buy, install, renew, or revoke.

Here is how the three approaches compare:

Where AgenticEmail fits

AgenticEmail is API-first email infrastructure for AI agents, and its end-to-end encryption is exactly this JOSE approach, built for agent-to-agent mail. It uses JWE with ECDH-ES over P-256 and AES-256-GCM, with multi-recipient support, plus Ed25519 JWS in a sign-then-encrypt flow. It is zero-knowledge: the private key is generated and kept client-side, in the SDK package agenticemail or the CLI agenticemail-cli on your machine, and never touches AgenticEmail servers, which hold only ciphertext. Discovery works by publishing a public key that recipients resolve by address.

Two honest caveats matter. Encryption is opt-in, and plaintext is the default. It works only between two AgenticEmail inboxes that have published keys; you cannot end-to-end encrypt to an external Gmail or Outlook address, because those systems do not speak this protocol. And because the private key lives only with you, if you lose it, old encrypted mail is unrecoverable. For the deeper mechanics see end-to-end encrypted email and encrypted email for AI agents, the step-by-step how to send encrypted email guide, or the full reference in the docs.

Frequently asked questions

Is S/MIME free?

Not usually. You can generate a self-signed certificate for testing at no cost, but any certificate that other clients will trust must be issued by a certificate authority, and commercial CAs generally charge for it. Large organizations often run their own internal CA, which shifts the cost from per-certificate fees to running that infrastructure.

Does S/MIME encrypt the subject line?

No. Standard S/MIME as defined in RFC 8551 encrypts the MIME message body and attachments, but the email headers, including the Subject, From, To, and Date, travel in the clear. That means the topic and the participants are visible even when the body is unreadable. If you need the subject protected, it has to be carried inside the encrypted payload, which S/MIME does not do by default.

S/MIME vs PGP: which should I use?

Pick S/MIME if you are inside an enterprise that already issues X.509 certificates through a CA and uses Outlook or Apple Mail, since it is built in and centrally managed. Pick PGP if you are exchanging mail with the privacy-focused community that already runs OpenPGP and you would rather not depend on a certificate authority. Both leak the subject and both resist automation, so if the sender is a program, neither is a comfortable fit.

Can I use S/MIME with Gmail?

The paid Google Workspace tiers support hosted S/MIME, so administrators can enable it for their organization, but it is not available on ordinary free Gmail accounts. Even where it works, both sides still need valid certificates and must exchange them first. For casual mail to a standard Gmail address, S/MIME is generally not an option.

Can an AI agent or automated system use S/MIME?

Technically yes, but it is painful. S/MIME assumes a mail client with a certificate store and a human to install and renew certificates, so automating it means managing certificate files and key stores yourself and handling the certificate-exchange bootstrap in code. A JOSE-based design fits automation far better: JSON keys, native libraries in every language, published-key discovery by address, and no certificate lifecycle. That is the model AgenticEmail uses, and you can drive it through the SDK, the CLI, or the hosted MCP server at https://api.agenticemail.dev/mcp.