How to send a secure email in outlook

If you've ever hit Send on something sensitive and felt a knot in your stomach, this one's for you. Learning how to send a secure email in Outlook isn't just about finding the right button. The method you need depends on your Outlook version, your Microsoft 365 plan, and how the recipient's email system handles protected messages.

Get those three things wrong, and you're not protecting anything.

Microsoft's current email encryption stack uses AES-256 for messages at rest and always sends mail over TLS in transit. That's a strong baseline. But TLS alone is not end-to-end encryption.

A lot of Outlook users believe they're private when they're really just protected during delivery. Let's clear that up.

Quick Answer: Which Encryption Method Do You Actually Have?

To send a secure email in Outlook, use the Encrypt button. Choose Options, then Permissions, then Encrypt-Only. That works if your Microsoft 365 admin enables it.

For true end-to-end encryption, use S/MIME. Both methods need a supported Outlook version.

Why "Secure Email" in Outlook Isn't One Simple Button

The word "secure" gets thrown around constantly in email discussions. In Outlook, it can mean a few genuinely different things. The automatic protection is Transport Layer Security, or TLS.

TLS encrypts messages while they travel from your device to the recipient's mail server. Once the message lands in that server's inbox, protection stops.

S/MIME, which stands for Secure/Multipurpose Internet Mail Extensions, is the only true end-to-end encryption built into Outlook. It encrypts the message on your device and decrypts it only on the recipient's device. Nobody in the middle, including mail providers, can read the body.

Both sides need digital certificates for it to work.

Microsoft Purview Message Encryption is the enterprise-friendly option most business users actually encounter. It wraps your message in a secure view and lets you apply restrictions like Do Not Forward. It's not true end-to-end encryption, but it stops casual snooping and forces accidental recipients to verify their identity first.

Information Rights Management, or IRM, is the engine behind usage restrictions like Do Not Forward. It also controls printing and copying. This is the right tool when your real concern isn't encryption itself, but what someone does with the content after opening it.

Check Your Outlook Version and Microsoft 365 Plan First

Before you do anything else, figure out which Outlook you actually use. The Windows client, Mac client, web app, and mobile app all handle encryption a little differently. A feature that works beautifully on one platform can be completely absent on another.

As of 2026, most Microsoft 365 business and enterprise plans include Microsoft Purview Message Encryption. Consumer accounts generally don't. If you bought Outlook as a one-time Office purchase, you're probably limited to S/MIME or nothing native.

Here's the quick breakdown:

To find your plan in Outlook for Windows, go to File > Office Account. You'll see your product name and subscription level right there. On the web, click your avatar in the top right, then check "View account."

If you don't see any encryption options, don't assume you're doing something wrong. Most of the time, the admin simply hasn't turned it on. You'll need to contact your IT team or, if you're the admin, open the Microsoft 365 admin center and enable Azure Rights Management.

Path A: Microsoft Purview Message Encryption (Encrypt-Only and Do Not Forward)

This is the most common way to send a secure email in Outlook today. Microsoft Purview Message Encryption, still often called OME, wraps your entire message in a protected experience. Instead of delivering plaintext, it delivers a secure view that requires recipient verification.

The recipient clicks through, verifies their identity, and then reads the content.

The feature offers two main options: Encrypt-Only and Do Not Forward. Neither one hides the fact that you sent an email. Both stop anyone who intercepts the message from reading it easily.

Microsoft's own documentation for this is the clearest technical reference, and you can check it directly on Microsoft Learn.

When to Use Encrypt-Only

Think of Encrypt-Only as the baseline protection. It scrambles the message body and requires recipient verification before display. However, the recipient can still forward the message, print it, or copy the contents after they open it.

That makes Encrypt-Only the right choice when your main worry is sending data to the wrong address. If a message goes somewhere it shouldn't, the unintended recipient faces a login wall. They can't read the body just by looking at their inbox.

Good candidates for Encrypt-Only include:

• Payroll documents
• Tax ID numbers and W-2s
• Healthcare records sent under HIPAA
• One-time passwords or access credentials

When to Use Do Not Forward

Do Not Forward does everything Encrypt-Only does, then adds a layer of policy enforcement. After the recipient opens the message, the forward button disappears. Printing and copying are blocked too.

This is the tool for legally sensitive or strategically important content. You don't want a client forwarding a settlement offer to a colleague. You definitely don't want them printing a confidential business plan.

Do Not Forward puts a technical stop on that.

Best uses for Do Not Forward:

• Legal contracts and settlement documents
• Financial statements before public release
• Proprietary product details
• Board meeting materials

One honest warning: Do Not Forward doesn't stop someone from taking a photo of the screen. No rights management tool can. It stops forwarding and copying, not analog photography.

How to Send Encrypt-Only From Outlook on Windows

The workflow is short. Compose a new email as you normally would, then look for the Options tab in the message window.

1. Click Options.
2. Click Permissions in the ribbon.
3. Choose Encrypt-Only from the list.
4. Send the message normally.

On Outlook on the web, the Encrypt button sits in the top toolbar of the new message screen. Click it and choose the same Encrypt-Only option.

If you don't see these buttons, the feature isn't enabled for your tenant. Encrypt-Only is a Microsoft 365 feature, not a standalone Outlook feature. The admin has to enable it first.

When Purview Encryption Isn't Enough

Purview Message Encryption protects the content from casual interception and accidental misdelivery. It doesn't protect the content on the recipient's mail server. That's a critical difference.

If you need encryption that survives the entire journey and stays encrypted until the recipient opens it, you need S/MIME.

Path B: S/MIME for True End-to-End Email Encryption

S/MIME is the heavyweight option. It provides actual end-to-end encryption, which means the message stays scrambled from your device to the recipient's device. Not even Microsoft can read the contents in between.

This is a mature standard, defined in RFC 8551 by the IETF, and it's been around for decades.

Here's the tradeoff: it requires certificates. Both you and your recipient need a digital certificate installed. That's why S/MIME is common in government, healthcare, and legal sectors, but rare among consumers.

How S/MIME Encryption Works

S/MIME uses a pair of cryptographic keys. Your private key stays on your device, never leaves it, and is used to sign or decrypt messages. Your public key lives inside your digital certificate, which you can share with anyone.

That certificate proves your identity and gives others the key they need to encrypt messages to you.

There are two separate S/MIME actions, and people confuse them all the time:

• Signing proves the email came from you and wasn't altered. It doesn't hide the content.
• Encrypting scrambles the content so only the recipient with the matching private key can read it.

You can sign only, encrypt only, or do both. For sensitive content, you usually want both.

Getting a Digital Certificate

You can't hand-wave your way through this. You need a certificate issued by a trusted certificate authority, or CA. If you work for a sizeable organization, your IT team probably issues certificates through an internal PKI system.

If you're on your own, you'll need to buy one from a public CA.

Typical certificate validity runs one to three years. After that, it has to be renewed. If your certificate expires and you don't renew it, recipients can't verify your signature and they can't encrypt responses to you.

Setting Up S/MIME in Outlook

Once you have the certificate file, installation is straightforward on Windows:

1. Install the certificate into your Windows certificate store, usually by double-clicking the .pfx or .p12 file.
2. Open Outlook and go to File > Options > Trust Center > Email Security.
3. Under Encrypted email, click Settings.
4. Choose the certificate for signing and the certificate for encryption.
5. Click OK and send a test signed email to a colleague who uses S/MIME.

After that, you'll see separate Sign and Encrypt buttons on the Options tab in any new email. These are distinct from the Encrypt-Only button. One click on the right control makes a real difference.

How to Send an S/MIME Encrypted Message

The actual sending process is simple once setup is done:

1. Compose your message.
2. Click Sign to add your digital signature.
3. Click Encrypt to scramble the message body.
4. Send.

There's one catch. Outlook can only encrypt a message when it has the recipient's public certificate. In most corporate environments, certificates are published to the Exchange Global Address List.

Outlook pulls them automatically. Outside that setup, you'll need to exchange signed emails first, because a signed email carries your public certificate.

Real-Life Example

Say you're a lawyer sending a settlement agreement to opposing counsel. Both sides use S/MIME and have each other's public keys. You compose the email, click Sign, click Encrypt, and send.

Opposing counsel sees a message from you with a valid signature and content that only their private key can open.

Even if an attacker intercepts the message in transit, they get nothing. Broken ciphertext. No names, no numbers, no settlement figures.

That's the whole point.

S/MIME Limitations to Know

S/MIME isn't perfect. Mobile support still lags desktop. As of 2026, Outlook mobile's S/MIME support depends heavily on device management settings.

If your organization uses Intune or another MDM, the certificate might not be available on your phone.

Another pain point: if you send an S/MIME encrypted message to someone without a certificate, Outlook simply won't send it. You'll get a warning instead. That's better than a failed message, but it means you need to plan ahead.

And remember, S/MIME doesn't stop someone from forwarding an email after they decrypt it. Once the recipient has the plaintext in front of them, they can do whatever they want with it. S/MIME protects the channel, not the reader.

Path C: Sensitivity Labels and Data Loss Prevention (DLP) Auto-Encryption

There's a quieter way to encrypt email in Outlook that doesn't get enough attention. It happens entirely in the background. Sensitivity labels and Data Loss Prevention rules can encrypt messages automatically, before you even click Send.

No extra button. No thinking required.

Sensitivity labels come from Microsoft Purview Information Protection. They're applied to documents and email messages to classify content based on how sensitive it is. A label called "Confidential" or "General" doesn't just tag the message.

It can force encryption as part of that classification.

This is the system you see in Outlook when you click a message and notice a label banner at the top. You might see "Confidential" in a colored pill or "General" in a gray one. The label isn't decoration.

It carries policies with it.

How Sensitivity Labels Enforce Encryption

Here's the logic Microsoft uses. An admin creates a label in the Microsoft Purview compliance portal. Then they attach an encryption setting to that label.

When any user applies that label to an email, Outlook automatically encrypts the message with the associated policy.

The result is an email that's already protected before you think about it. If the label says "Confidential \ All Employees," every recipient inside your organization can open it. If it says "Confidential \ Recipients Only," only the people listed in the To and CC fields can read it.

That's a completely different security model than clicking Encrypt-Only manually.

You can also let users pick sub-labels from a dropdown. This gives them control without giving them the technical burden of choosing encryption parameters. They just pick the right level of sensitivity, and the encryption follows.

DLP Rules That Encrypt Without User Action

Data Loss Prevention, or DLP, goes one step further. DLP policies scan outgoing email for patterns. Credit card numbers.

Social Security numbers. Bank account details. Passwords.

If a rule matches, the system can apply encryption automatically.

This is the most reliable safety net in the entire Microsoft ecosystem. A busy employee who forgets to click Encrypt doesn't matter. The policy catches the message before it leaves Exchange Online.

It reads the content, matches the pattern, and wraps the message in protection.

Where Labels Sit in Outlook

In Outlook for Windows, you'll see the sensitivity label button near the subject line or in the message ribbon. In Outlook on the web, it appears in the top toolbar of the compose window. It's a small icon with text that shows the current label.

Clicking it opens a list of allowed labels.

You can also set a default label for all your messages. If you work in a highly regulated industry, you might want your default label to be "Confidential" with encryption forced. Then every single email you send is protected by default.

Who Should Rely on Labels and DLP

If you're an individual sending the occasional sensitive email, labels and DLP are overkill. Manual encryption is simpler. But if you run a team where sensitive data flows daily, automation wins.

HR departments that email payroll data need DLP. Legal teams that send draft contracts need a Confidential label. Healthcare offices handling patient records should be using automatic classification.

Here's the biggest practical advantage: automation protects against human error. Aggregate reports confirm that most data leakage comes from an employee who forgot the process. A DLP rule doesn't forget.

The tradeoff is complexity. Setting up labels and DLP policies requires admin access and careful planning. It's not a weekend project.

But for organizations sending dozens of protected emails daily, it's the only realistic path.

Step-by-Step: How to Send an Encrypted Email in Outlook

The exact steps depend on which Outlook client sits on your machine. We'll break it down by platform, because the buttons move around. On every platform, the process starts the same way: compose a message, go to the security options, and pick your protection level.

Outlook for Windows

The Windows desktop client offers the most complete encryption experience. Both Purview Message Encryption and S/MIME are fully available here.

1. Open a new message by clicking New Email.
2. Click the Options tab in the message ribbon.
3. Click Permissions. A dropdown appears.
4. Pick Encrypt-Only or Do Not Forward.
5. If you use S/MIME, click Sign and Encrypt in the same ribbon.
6. Write your message. Send it.

That's the entire workflow. It takes about six seconds once you know where to look.

One note: the Permissions button only appears when your account is on Microsoft 365. Outlook from an older standalone Office installation won't show it. If you're missing the button entirely, that's why.

Outlook for Mac

Mac users get a slightly different experience. The encryption options are still there, but the navigation is more indirect.

1. Compose a new message as normal.
2. Click Options in the toolbar.
3. Look for Permissions or Encrypt.
4. Select your level of protection.
5. Send.

On the Mac, S/MIME settings live under Outlook > Settings > Accounts > Advanced > Security. Make sure both signing and encryption certificates are selected there. Without that, the Sign and Encrypt buttons will be grayed out.

Mac users also have keyboard shortcuts worth knowing: Control + Shift + E toggles encryption, and Control + Shift + S toggles signing. Saved you some clicks.

Outlook on the Web

Web users have the simplest interface, but fewer choices. The encryption options are confined to Purview Message Encryption. S/MIME isn't available in the browser version for most accounts.

1. Go to outlook.office.com and sign in.
2. Click New Message in the top left.
3. Click More options, indicated by three dots in the toolbar.
4. Select Encrypt from the dropdown menu.
5. Choose Encrypt-Only or Do Not Forward.
6. Compose and send.

The web app highlights the Encrypt option only when your Microsoft 365 tenant has it enabled. For free Outlook.com accounts, you might see encryption options limited to deleting or blocking recipients.

Outlook Mobile App

Here's where frustration kicks in for most people. The Outlook mobile app currently offers limited encryption support. As of 2026, the app relies heavily on Intune app protection policies when it comes to encryption.

Without that infrastructure, you won't find an Encrypt button on your phone.

What mobile users can do instead:

• Use Outlook on the web from your phone's browser.
• Send the email from your desktop first.
• Rely on sensitivity labels if your admin set up auto-labeling for mobile.
• Use a DLP policy that encrypts automatically.

Mobile is still a read-first experience. For sending sensitive email, your desktop or web client remains the reliable route. If you're on iOS and your organization supports it, check Settings under your account for S/MIME options.

A small number of enterprise setups enable it there.

A Quick Platform Comparison

What the Recipient Sees When You Send an Encrypted Email

The recipient's experience depends on their email provider. That's where most people get surprised. You can send a perfectly encrypted email and your recipient still ends up confused.

Let's map out the four most common scenarios.

Recipient Using Microsoft 365

If the recipient has a Microsoft 365 work or school account, the message opens almost normally. They click the email, read it inline, and may not even realize it was encrypted. The experience feels seamless.

The only visible sign is a small lock icon or a banner saying "This message is protected."

That's the best-case scenario. No extra login. No waiting.

No friction.

Recipient Using Gmail, Yahoo, or Another Consumer Service

External recipients get the full identity-verification experience. They open the email and see an HTML page instead of your message. The body says something like, "The sender has protected this message with Microsoft Outlook."

From there, they have two options:

• Sign in with a Microsoft account to read the message inline.
• Use a one-time passcode sent to their email address.

The one-time passcode is the most common path. They click the button, Microsoft sends a code to their inbox, they enter it, and then the message displays. The entire process takes 30 to 45 seconds.

Recipient Using Outlook.com

Free Outlook.com users fall somewhere in between. They might see the same verification experience as Gmail users, or the message might open inline if they're already signed in. It's inconsistent.

If the recipient gets stuck, tell them to look for the code in their spam folder. That's where Microsoft's one-time passcode lands more often than you'd think.

Recipient Receiving an S/MIME Encrypted Message

S/MIME looks completely different on the recipient's side. Instead of an HTML page, the recipient sees an email with a lock icon in the reading pane. Or they see a confusing message that says, "This message could not be decrypted."

That second message means the sending certificate didn't match the recipient's private key. The sending client didn't have the right public certificate, or the recipient's certificate expired. It's a configuration problem on one side of the conversation.

When S/MIME works properly, the recipient just reads the message like normal. The digital signature shows a green ribbon or checkmark that says "This message was signed by [sender]." That's verification baked into the reading pane.

Common Recipient Questions

• Can I reply to an encrypted email? Yes. The reply inherits the same encryption settings.
• Can I forward it? Only if you used Encrypt-Only. Do Not Forward blocks it.
• What happens if I click the passcode after 15 minutes? It expires. They request another one.
• Will my phone show the encrypted message? Once opened via the web link, yes. The message itself renders in the browser.

Common Mistakes That Break Secure Emails in Outlook

Plenty of people think they're sending encrypted email when they aren't. At least a few of these mistakes have probably hit you already. Let's fix them for good.

Thinking TLS Means End-to-End Encryption

This is the mother of all misconceptions. Outlook always uses TLS in transit automatically, but that only protects the connection between mail servers. The plaintext message sits on the recipient's server at rest.

Anyone with access to that server can read it.

If you're protecting sensitive content, TLS isn't enough. You need Purview Message Encryption or S/MIME on top of it.

Clicking "Sign" When You Want "Encrypt"

Signing proves the message came from you. It doesn't hide a single word. If you're trying to hide the content, signing alone does nothing.

You need the virtual seal plus encryption.

Plenty of professionals learn this after sending a confidential contract that only carried a signature. The signature proves authenticity, not secrecy.

Forgetting to Use the Web App for External Recipients

If you're sending S/MIME encrypted mail to a business partner outside your organization, they need the web experience to work. Some older providers can't handle S/MIME attachments on mobile. The recipient sees a file instead of a message.

It breaks the entire point of sending encrypted email.

Sending Encrypt-Only to a Distribution List

This one is subtle. When you send Encrypt-Only to a distribution list, Microsoft can only open the message for recipients who have Microsoft accounts. External users on that list get the one-time passcode experience.

The problem is, some distribution lists keep membership hidden. You can't know who's on the list, so you can't predict who's external.

The fix is to send encrypted messages to explicit recipient lists. Know exactly who's receiving the email before you encrypt it.

Letting Certificates Expire

S/MIME certificates come with expiration dates. Once the certificate dies, your private key becomes useless. Not only can you not encrypt new messages, you can't decrypt old ones either.

Set a calendar reminder 60 days before expiration. You should also test your S/MIME setup at least once a quarter. A short test email to a colleague catches configuration drift before it becomes a crisis.

Assuming Attachments Are Automatically Protected

Attachment handling differs between encryption methods. Purview Message Encryption encrypts the entire email including attachments when sent through Outlook for Windows. But on mobile, that behavior can vary.

S/MIME works differently with different attachment types.

Check what happens to the attachment before you hit send. Some attachment types are encrypted as part of the S/MIME envelope. Others, depending on your email client, may not be.

A quick test message with a PDF or spreadsheet attached verifies your setup.

Not Calling Your Admin When the Button Is Missing

Many users quietly accept the absence of encryption options. They think, "This is just how Outlook is." No. If the Encrypt button isn't there, your admin or your plan is holding it back.

That's not a limitation to live with.

If you handle sensitive data, raise the issue with IT. The fix is usually a configuration change or a license upgrade. In our research, most Microsoft 365 Business Standard and E3 plans include the necessary capability, but it needs to be turned on.

How to Choose Between Purview Encryption, S/MIME, and TLS

You have three real layers of protection, and each one does a different job. Choosing the right one for your situation is simple once you ask the right question. The question isn't "which is more secure." The question is "who are we protecting against."

When TLS Is Enough

TLS handles the transport layer. It stops someone from intercepting your email as it travels across the internet. If you're sending routine business correspondence with mildly sensitive content, TLS does the job.

Your message stays encrypted between servers, and that's that.

Choose TLS-only when:

• The message contains no personal or financial data.
• Your concern is someone tapping the wire.
• Your recipient's server uses TLS, which most major providers do.
• You just need privacy, not restrictions on usage.

When Purview Message Encryption Works

Purview Message Encryption is your middle ground. It protects content at rest on the recipient's server and gives you access controls. The recipient has to verify their identity before reading.

That's the key difference from plain TLS.

Choose Purview when:

• You're sending to a mixed recipient list.
• You need Do Not Forward protection.
• The recipient might be using Gmail, Yahoo, or another consumer provider.
• You're handling HIPAA-covered data or other regulated content.
• You want a simple "click and send" experience.

This is the best option for most business users. It balances protection with usability.

When S/MIME Wins

S/MIME offers the strongest security of the three because it encrypts end-to-end. Nobody can intercept, inspect, or even read the message between sender and recipient. The encryption only breaks when the recipient's private key decrypts it.

Choose S/MIME when:

• You're in a regulated industry like government, legal, or finance.
• You exchange sensitive documents with known business partners.
• You need cryptographic proof of authenticity, not just a link click.
• Your organization issues S/MIME certificates to employees.
• You're sending to recipients who also use S/MIME.

The cost is that S/MIME demands certificates on both sides. You can't just toggle it on.

Decision Logic in One Line Each

If your recipient is inside your organization, use Encrypt-Only or sensitivity labels. If you need to control forwarding and copying, use Do Not Forward. If you're dealing with true secrets and both sides have certificates, use S/MIME.

A Decision Table for Quick Reference

What About Third-Party Add-Ins?

You'll come across third-party tools that claim to add secure email to Outlook. Virtru and Zix are the two most commonly mentioned. They integrate with Outlook and offer simplified encryption.

They don't replace your native Microsoft security settings though.

Using a third-party tool adds a new license, a new login, and a new failure point. It can help if you need specific features Microsoft doesn't provide, but most organizations never will. Start with the native options before adding vendors.

Compliance, Privacy Laws, and Audit Trails: What to Know Before You Hit Send

Encryption isn't just a technical detail. It's often a legal requirement. If you handle certain types of data, the law may demand you protect it.

Not doing so can cost you heavily.

The most frequently cited regulation is HIPAA. Healthcare providers, insurers, and their business associates must safeguard electronic protected health information. Sending patient records without encryption is a violation risk.

The U.S. Department of Health and Human Services provides enforcement guidance here.

GDPR takes a broader approach. It applies to any organization handling personal data of EU residents. Article 32 specifically requires encryption as a means of securing personal data.

It's not an absolute mandate, but it's the expected baseline.

Other regulations follow the same pattern. PIPEDA in Canada, LGPD in Brazil, and state-level laws like the California Consumer Privacy Act all push toward encryption. If your email contains personal data, encrypted delivery is your safer default.

Audit Trails and eDiscovery

Encrypted email can complicate legal discovery. When a lawsuit or regulator demands records, you must produce them. If you can't decrypt old messages, you're in trouble.

Microsoft 365 helps here. The Purview compliance portal tracks email activity. It logs when messages are sent, received, encrypted, and opened.

That trail becomes your evidence.

For S/MIME, keep your certificates and private keys backed up. If a certificate expires and you've lost the private key, you may also lose access to every message encrypted to that key. Recovery is often impossible.

When to Seek Legal Advice

This article gives you practical guidance, not legal counsel. If you're unsure whether your email practices satisfy a specific regulation, ask your compliance officer or a qualified attorney. The cost of a consultation is tiny compared to a data breach fine.

One more thing: encryption is a tool, not a compliance shield. You can encrypt every message and still violate HIPAA by sending it to the wrong person. Encryption protects the channel.

It doesn't protect your judgment.

Costs, Certificate Requirements, and Plan Limitations

Let's get practical about money and constraints. Encrypting email in Outlook isn't free for everyone. Some paths cost nothing beyond your subscription.

Others require a digital certificate purchase.

What Your Microsoft 365 Plan Includes

Baseline encryption is included in most business plans. Microsoft Purview Message Encryption comes with Microsoft 365 E3, E5, Business Standard, and Business Premium. If you're on Microsoft 365 Business Basic, you may have limited access.

Consumer Outlook.com accounts don't get Purview encryption. If you're using a free account, you're stuck with basic protection and third-party add-ins. That's not ideal for sensitive data.

S/MIME Certificate Costs

If you need true end-to-end encryption, you'll need certificates. Organizations often run their own certificate authority. That's an internal cost you already pay in infrastructure.

For individuals or small businesses, public certificate authorities are the route. A typical S/MIME certificate costs between $30 and $100 per year. Some providers offer free certificates for personal use.

Those free options often expire after a year and require manual installation.

Don't forget the hidden cost: time. Setting up S/MIME on a single machine takes about an hour after you have the certificate. Rolling it out to a whole team takes coordination and training.

Email Size Limits

Encryption doesn't shrink your message. It wraps it in extra layers. Purview encryption can handle attachments up to your normal Exchange Online limit, which is typically 25 to 35 MB.

For larger files, you're better off using a secure file-sharing service.

S/MIME is different. Encrypted attachments can be significantly larger than their plaintext counterparts. The cryptographic overhead adds a few kilobytes per file, which is negligible.

The real limit remains your organization's outbound message size cap.

Recipient Friction as a Hidden Cost

Every time you send an encrypted message to an external user, they face a one-time passcode step. That's a few seconds of their time. Do that often enough, and they'll start asking why you don't just send regular email.

There's a real cost to that friction. Business relationships get strained when clients can't easily read your messages. If you send many encrypted messages to external parties, consider switching those recipients to a secure portal or a service they're already using.

Renewal and Maintenance

Encryption isn't set and forget. Certificates expire. Policies get outdated.

Users forget their passwords. Budget for ongoing maintenance just like you would for any other security tool.

Real-Life Example: Sending a Confidential Contract to a Client

Let's walk through a realistic scenario. You're a financial advisor sending a signed engagement contract to a new client. The contract contains bank details, social security numbers, and fee schedules.

This is exactly the kind of email that should never travel as plaintext.

The Setup

Your firm uses Microsoft 365 Business Standard. You have Purview Message Encryption available, but your client uses Gmail. You've never exchanged S/MIME certificates with them, so Purview is the practical choice.

You compose the email in Outlook for Windows. Before you type a word, you decide on the protection level.

• You don't need to block forwarding, since the client may need to share the contract with their spouse or accountant.
• You do need to verify that whoever opens the email is the actual client.
• Encrypt-Only is the right call.

The Sending Process

You click New Email, type the subject line, then go to Options > Permissions > Encrypt-Only. Then you write the body, attach the PDF, and hit Send. Total time spent securing the message: about five seconds.

What Happens on the Client's Side

Your client receives an email that looks different from a normal message. It doesn't show the contract text or attachment directly. Instead, it shows a block explaining that the sender protected the message.

They click the "Read the message" button. Gmail asks them to verify their identity. Microsoft sends a one-time code to their inbox.

They enter the code, and then the contract appears in their browser. The PDF attachment is available there.

All of that takes about 45 seconds. The client is mildly surprised but understands why you did it. Your signed contract is readable.

Nobody else can access it.

The Lesson

Encrypt-Only delivered exactly the right balance of security and usability. The message was protected at rest. The recipient had to verify their identity.

The forwarding remained possible because the client needed it.

S/MIME would have been stronger, but it would have required both you and the client to set up certificates. That's a poor trade for a single document exchange. Do Not Forward would have been worse, since it blocks the client from sharing with their accountant.

The decision tree works. Match the threat level to the recipient's needs and their technical setup.

Frequently Asked Questions

Can I send an encrypted email in Outlook for free?

Yes and no. If you have a Microsoft 365 business plan, Encrypt-Only is included. It costs nothing extra beyond your subscription.

For free Outlook.com accounts, native encryption is unavailable. You'd need a third-party add-in for that.

Why is my Encrypt button missing in Outlook?

Your account plan or admin settings control that button. If you're on a personal Outlook.com account, you won't see it. If you're on a business plan and the button is absent, your IT admin hasn't enabled Microsoft Purview Message Encryption.

Ask them to turn it on.

What's the difference between Encrypt-Only and Do Not Forward?

Encrypt-Only requires recipients to verify their identity and protects the message body at rest. Do Not Forward adds restrictions. It blocks forwarding, printing, and copying.

Both hide the message content from accidental recipients.

How do I open an encrypted email received in Outlook?

If you use Microsoft 365, the message opens inline with no extra steps. If you use Gmail or another provider, you'll click a link and request a one-time passcode. Microsoft emails you that code, you enter it, and the message displays.

Does Outlook encrypt email attachments?

Yes, in most cases. Purview Message Encryption wraps attachments along with the message body when sent from Outlook for Windows. S/MIME encrypts attachments as part of the cryptographic envelope.

Mobile apps may handle attachments differently, so test one before relying on it.

Final Decision Guide: Pick Your Secure Email Path in Outlook

You now know more about Outlook encryption than most IT pros. Time to turn that into a decision. The right path depends on your role, your recipients, and your threat model.

Start With These Questions

1. Are both you and your recipient inside the same Microsoft 365 organization? Use Encrypt-Only or Do Not Forward. The message opens seamlessly.

2. Is your recipient external but uses a major email provider? Use Encrypt-Only for general sensitive content. Use Do Not Forward if you need to block copying.

3. Do you and your recipient both have S/MIME certificates? Use S/MIME encrypt and sign. This is the only true end-to-end option.

4. Do you worry about people forgetting to encrypt? Configure sensitivity labels or DLP policies. Let automation handle it.

5. Are you sending routine business email with nothing sensitive? Do nothing. TLS in transit is already active.

The Verdict

For most business users, Encrypt-Only is the right starting point. It's one click, it's included in your subscription, and it stops accidental misdelivery from becoming a headline. Upgrade to Do Not Forward only when you need policy enforcement.

Add S/MIME when the data is valuable enough to justify certificate management.

Whichever path you choose, test it first. Send a test message to a second account. Confirm the recipient experience works.

That's the only way to be certain your secure email is actually secure where it counts.