How to send an encrypted email in Outlook

To send an encrypted email in Outlook you have two main options, and which one you use depends on your account. The first is S/MIME, certificate-based encryption where you install an S/MIME certificate, turn on the encrypt option in a new message, and send to a recipient who already has your certificate. The second is Microsoft 365 Message Encryption (OME), a hosted feature on Microsoft 365 business and enterprise plans that uses an Encrypt button and needs no certificate exchange. S/MIME is true end-to-end style encryption between two certificate holders, while OME is Microsoft-hosted encryption that reaches any recipient through a secure portal. This guide walks through both, what each one protects, and where neither fits automated sending.

Option 1: S/MIME encryption

S/MIME uses public-key cryptography and X.509 certificates to encrypt a message to the recipient's public key so that only their private key can open it. Before you can send anything, you need an S/MIME certificate installed on the machine and account you send from. That certificate comes from a certificate authority (CA), either a commercial one or an internal enterprise CA that your admin runs.

Once the certificate is in place, the flow is roughly the same across clients:

• New Outlook and classic Outlook desktop. Enable S/MIME in the account or trust-center settings so the client knows which certificate to use, then compose a new message and turn on the encrypt option before sending. The client encrypts the message body to the recipient's public key on send.
• Outlook on the web. With S/MIME configured for your Microsoft 365 organization and the browser extension in place, you compose a message and switch on the encrypt option, and the message is encrypted in the same way.

The catch is the chicken-and-egg problem: to encrypt a message to someone, the recipient needs your certificate first, and you need theirs. The standard way to bootstrap this is to exchange a signed email. One side sends a message that is signed but not encrypted, the signature carries their certificate, the other client stores it, and only then can an encrypted reply go the other way. For the full mechanics of certificates, signing, and the CA trust model, see the S/MIME email encryption guide.

Option 2: Microsoft 365 Message Encryption (OME)

If certificate exchange sounds like too much, Microsoft 365 Message Encryption is the alternative built for people who just want to click a button. OME is available on Microsoft 365 business and enterprise plans, and it surfaces in Outlook as the Encrypt control with options such as Encrypt-Only and Do Not Forward. You compose a message, pick one of those options, and send. There is no certificate to obtain, install, or trade first.

The big practical advantage is that OME works to external recipients. When you encrypt a message to someone outside your organization, they read it through a Microsoft-hosted secure portal, authenticating with their own account or a one-time passcode. That removes the requirement that both sides have set up keys in advance, which is what makes S/MIME awkward across organizations.

The trade-off is who holds the keys. OME is Microsoft-hosted encryption, not zero-knowledge end-to-end encryption. Microsoft manages the keys and the portal, so the platform can technically access the message content. That is a reasonable trade for most business mail, but it is a different guarantee from S/MIME, where the plaintext only exists on the two endpoints. The email encryption overview lays out where each model sits, from encryption in transit to hosted encryption to true end-to-end.

What Outlook encryption does not do

Both options are useful, but it is worth being blunt about the gaps before you rely on either one.

• S/MIME leaves the Subject header in the clear. Standard S/MIME encrypts the MIME message body and attachments, 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 readable to anyone watching the wire or reading the mail server, even when the body is sealed.
• Both sides need setup. S/MIME requires certificates on both ends and an exchange to bootstrap. OME needs a qualifying Microsoft 365 plan on the sending side, and external readers have to detour through a portal to open the message.
• It is manual and client-bound. Both options assume a human sitting at a mail client, clicking Encrypt on a message they composed by hand. They are tied to Outlook and its certificate store or to the Microsoft 365 service, so neither is designed to run headless, which makes them a poor fit for automated or programmatic sending.

Encrypting email from code or an AI agent

Outlook encryption assumes a human at a mail client. The moment the sender is a script, a backend service, or an autonomous agent, the certificate stores and Encrypt buttons are the wrong shape. For programmatic or agent-to-agent mail you want an API that handles key generation, publishing, encryption, and decryption automatically, with no interactive step.

Where AgenticEmail fits

AgenticEmail is API-first email infrastructure for AI agents, and its end-to-end encryption is built for exactly this case. It uses standards-based JOSE: JWE for confidentiality with ECDH-ES over the P-256 curve and AES-256-GCM, plus Ed25519 JWS signatures in a sign-then-encrypt flow so the recipient can verify who sent a message. It is zero-knowledge: the private key is generated and kept client-side, never on AgenticEmail servers, which only ever hold ciphertext. Encryption is opt-in and agent-to-agent, and keys are discovered by publishing a public key that peers resolve by address.

Some honest caveats you should weigh before relying on it. Encryption is opt-in and plaintext is the default, so it is something you switch on, not something that is always on. It works only between two AgenticEmail inboxes that have each published a key, which means you cannot end-to-end encrypt to an external Outlook or Gmail address, because those mailboxes have no key registered with AgenticEmail. And because the private key lives only with you, a lost private key means the mail encrypted to it is unrecoverable. For the deeper design, see end-to-end encrypted email and encrypted email for AI agents, or the full method reference in the docs.

Frequently asked questions

Does Outlook encrypt email by default?

No. Outlook secures the connection to the mail server with TLS in transit, but the message itself is not encrypted end-to-end unless you turn it on. You have to explicitly enable S/MIME and choose the encrypt option, or use the Encrypt button on a Microsoft 365 plan. Left alone, a normal Outlook message is plaintext once it reaches the servers that handle it.

What is the difference between S/MIME and Microsoft 365 Message Encryption?

S/MIME is certificate-based encryption where both sender and recipient hold X.509 certificates, and the plaintext only exists on the two endpoints. Microsoft 365 Message Encryption is a hosted service that needs no certificate exchange and can reach external recipients through a secure portal, but Microsoft manages the keys and can technically access the content. S/MIME is closer to true end-to-end; OME is easier to use but hosted rather than zero-knowledge.

Does Outlook encryption hide the subject line?

Standard S/MIME does not. It encrypts the message body and attachments, but the headers, including the Subject, From, To, and Date, travel in the clear, so the topic and the participants stay visible. If you need the subject itself protected, it has to be carried inside the encrypted payload, which S/MIME does not do by default.

Can the recipient read an encrypted Outlook email in Gmail?

It depends on the method. For S/MIME, the Gmail recipient needs S/MIME configured on a supported Google Workspace account and must have exchanged certificates first, so a plain free Gmail address generally cannot open it. For Microsoft 365 Message Encryption, a Gmail recipient reads the message through the Microsoft-hosted secure portal after authenticating, rather than seeing decrypted content directly in Gmail.

Can I send encrypted email from Outlook automatically or from code?

Not comfortably. Both S/MIME and OME are designed around a person at a mail client clicking Encrypt, so driving them headless means wrestling with certificate stores or the Microsoft 365 service without an interactive step. For automated or agent-to-agent sending, an API-first design fits far better: keys generated and published programmatically, encryption applied on send, decryption on receive. That is the model AgenticEmail uses, and you can drive it through the SDK, the CLI, or the hosted MCP server described in the docs.