How to Send an Encrypted Email in Gmail, Outlook, and Beyond

What does it actually mean to encrypt a single email?

You have one message you would rather the wrong people never read. A contract with a signature on it, a tax document, a set of login credentials a colleague needs, a medical result, a bank detail, a confidential update to a client. A normal email feels too exposed for it, so you go looking for the button that locks it down — and quickly discover that "send an encrypted email" means five different things depending on which inbox you are sitting in, and that some of the options labeled "secure" protect far less than the word implies.

This guide is the practical version. It walks through exactly how to send an encrypted email in Gmail, Outlook and Microsoft 365, Proton Mail, and with PGP through a browser extension, plus the low-tech fallback that works no matter what the recipient uses. For each method you get the steps and, just as important, an honest line on what it actually protects — because the gap between "this feels private" and "this is genuinely unreadable by anyone but the recipient" is where most people get a false sense of security.

Before the steps, one piece of vocabulary that makes everything else click. Almost all modern email is already encrypted in two ways you do not have to think about. It is encrypted in transit, meaning the connection between mail servers is scrambled by TLS so someone tapping the network in between sees gibberish, and it is encrypted at rest, meaning your provider stores it on disk in encrypted form. Those are the baseline, and they are real. But in both cases your email provider — Google, Microsoft, whoever runs your mailbox — holds the keys and can read the contents. That is fine for most mail and it is how features like search and spam filtering work. It is not enough when the threat you care about is "the provider, or anyone who can compel the provider, should not be able to read this."

Closing that last gap is what people usually mean by an "encrypted email," and there is only one mechanism that does it: end-to-end encryption, where the message is scrambled on your device with a key only the recipient can undo, so it travels and rests as ciphertext that the servers in the middle — including your own provider — cannot read. End-to-end encryption (E2EE) is the gold standard, and it is also the one that takes a little setup, because both you and your recipient need keys. Everything else on the menu — Gmail's confidential mode, password-protected portals, a locked PDF — sits somewhere short of that, offering useful control without true end-to-end secrecy. Knowing which is which is the whole game.

It helps to picture the journey a single email takes. You write it, it leaves your device, it crosses the open internet to your provider's servers, it is stored there, it is handed to the recipient's provider, it is stored again, and finally it is delivered to the recipient's screen. Transit encryption guards the hops between servers. At-rest encryption guards the two resting points on the servers. But at every server it passes through, the message exists in a form the operator of that server can read, because they hold the keys. End-to-end encryption changes the math entirely: the message is locked the instant it leaves your hands and is not unlocked until it reaches the recipient's, so every server in between — yours, theirs, and anything in the middle — only ever touches a sealed envelope it cannot open. That is the difference between "nobody can eavesdrop on the wire" and "nobody but the recipient can ever read this."

There is also a quieter benefit to true end-to-end encryption that pure transit encryption can't offer: integrity and authenticity. The same key machinery that scrambles a message can also sign it, so the recipient can verify two things — that the message genuinely came from you, and that not a single character was altered along the way. That matters more than people realize in an era of convincing impersonation and forged senders; an encrypted, signed message is far harder to fake than a plain one. Most of the strong methods in this guide (S/MIME and PGP especially) give you signing alongside encryption, and it is part of why they're worth the setup for high-stakes correspondence.

So the right question is never just "how do I encrypt this email" — it is "what level of protection does this specific message need, and which method on my provider delivers it." The next section gives you a fast way to decide, and then we get into the step-by-step for each platform. None of this requires you to become a cryptographer; it just requires you to know which of two very different things the word "encrypted" is doing in any given feature.

First, what level of encryption does this message actually need?

Reaching for the strongest possible method on every email is a recipe for never sending anything, because true end-to-end encryption asks something of the recipient too. The realistic approach is to match the method to the stakes. Most mail needs nothing extra — the transit and at-rest encryption your provider already applies is genuinely adequate for the ordinary back-and-forth of work and life. The handful of messages that carry real consequences if they leak are the ones worth a deliberate choice.

A simple way to triage: ask who you are protecting the message from, and what happens if it ends up in the wrong hands. If you are mainly worried about a message being forwarded around an office, sitting in an inbox forever, or being opened by whoever happens to be at someone's unlocked screen, you want access control — expiration, no-forward, a passcode. Gmail's confidential mode and Outlook's Encrypt button live here. If you are protecting against the provider itself, a subpoena, a future data breach of the mail host, or a genuinely sensitive secret, you need end-to-end encryption — Proton, S/MIME, or PGP. And if the recipient cannot do any of that, the universal fallback is to encrypt the file, not the email, and hand over the password some other way.

There is a second variable that quietly decides everything: what the recipient can receive. The strongest methods are only as available as the other person's setup. S/MIME needs the recipient to have S/MIME too. PGP needs them to have a PGP key you can find. Proton's full end-to-end mode needs them to be on Proton. The moment your recipient is just a regular Gmail or Outlook user with no special setup, your realistic options narrow to a password-protected portal (like Proton's) or a locked attachment. This is not a flaw in your effort — it is the nature of encryption, which requires both ends to cooperate. Plan around the recipient, not just around your own inbox. A useful habit is to confirm, before you compose anything sensitive, how the person on the other end actually reads their mail: a one-line "can you receive an encrypted file, or should I send you a secure link?" saves a lot of bounced attempts and accidental plaintext.

It is also worth being honest about the cost side of each level, because that is what makes triage realistic rather than aspirational. Access control is nearly free in effort: a couple of clicks in Gmail or Outlook and you are done, and the recipient barely notices. True end-to-end encryption sits at the other end of the spectrum — S/MIME and PGP both involve obtaining and managing cryptographic keys, and even the friendliest option, Proton, asks the recipient to deal with a password or to create an account. The attachment workaround lands in the middle: trivial for you, a small extra step for the recipient. Knowing those costs up front stops you from over-engineering a low-stakes note or, worse, under-protecting something that genuinely needed the strong stuff because the strong stuff felt like a hassle in the moment.

Keep one more thing in mind that no encryption method can fix: once a human being can read a message, they can screenshot it, photograph the screen, forward the gist, or simply remember it. Encryption protects the message in transit and storage; it does not bind the person who legitimately opens it. So choose the recipient as carefully as you choose the method. A perfectly encrypted message sent to the wrong, or careless, person is no safer than a postcard. With that framing, here is the decision in table form, followed by the steps for each route.

How do you send an encrypted email in Gmail?

Gmail gives you two genuinely different options, and the names hide how far apart they are. The first, confidential mode, is available on every Gmail account for free and is the one most people find — but it is not end-to-end encryption, and treating it as such is the most common mistake in this whole topic. The second, S/MIME, is real end-to-end-grade encryption but is locked to certain paid Google Workspace tiers and requires setup on both ends. We will cover both, starting with the one you can use right now.

Confidential mode works by not sending the message body in the normal way at all. Instead, Gmail stores the content on Google's servers and sends your recipient a link to view it, which is the trick that makes its headline features possible: you can set an expiration date after which the link dies, require an SMS passcode to open it, and revoke access at any time. The recipient cannot forward, copy, print, or download the message through Gmail's buttons. That is real, useful access control. What it is not is private from Google — because the content sits on Google's servers in a form Google can read, exactly like any other Gmail message. So confidential mode protects against the wrong recipient and the over-eager forwarder; it does nothing against the provider itself. Here is how to turn it on.

It is worth being precise about when confidential mode is the right call, because used in the right spot it is a genuinely sensible tool, and most of the criticism of it is really criticism of people expecting too much from it. Reach for it when you are sending something mildly sensitive to a person you already trust, and your worry is the message's afterlife rather than interception: you do not want it forwarded into a wider thread, sitting in their inbox indefinitely, or being read by whoever borrows their laptop. The expiration gives the message a sensible shelf life, the no-forward control adds friction to casual sharing, and the revoke button is a real comfort the first time you realize you sent it to the wrong "Sarah" in your contacts. None of that requires the recipient to do anything special, which is exactly why it is the most reached-for option in Gmail.

1. 1

   Compose your message and open confidential mode

   In Gmail on desktop, click "Compose," fill in the recipient, subject, and body, then click the padlock-with-a-clock icon ("Toggle confidential mode") in the toolbar at the bottom of the compose window. On the mobile app, tap the three-dot "More" menu in compose and choose "Confidential mode."

2. 2

   Set an expiration date

   Use the "Set expiration" dropdown to pick how long the message stays openable — one day, one week, one month, three months, or five years. After that window the recipient's link stops working and the content is no longer viewable.

3. 3

   Choose a passcode option

   Select "No SMS passcode" (Gmail recipients open it directly; non-Gmail recipients get a code emailed to them) or "SMS passcode" (every recipient must enter a code texted to their phone, so you'll need to add the recipient's phone number — not your own).

4. 4

   Save and send

   Click "Save" to apply the settings — a banner confirms the expiration at the bottom of the message — then click "Send." To revoke access later, open the message in your Sent folder and click "Remove access" at any time before it expires.

How do you set up real encryption (S/MIME) in Gmail Workspace?

If you need Gmail to send mail that Google itself cannot read, confidential mode will not get you there — you need S/MIME, and that means a paid Google Workspace plan. S/MIME (Secure/Multipurpose Internet Mail Extensions) is a long-standing standard that uses digital certificates to encrypt and digitally sign messages. When both you and your recipient have S/MIME set up, the message is encrypted end-to-end between you, and the signature proves it genuinely came from you and was not altered in transit. This is the kind of encryption that holds up against the provider and against tampering — but it comes with two real conditions.

First, hosted S/MIME in Gmail is only available on certain paid Workspace tiers (the enterprise and education editions), not on a personal @gmail.com account or the cheaper Workspace plans. Second, and this trips everyone up, S/MIME only works when the recipient also has S/MIME enabled and you have exchanged certificates — which happens automatically once you have received at least one signed message from them. Email someone who has no S/MIME certificate and Gmail simply cannot encrypt to them with this method; you fall back to a lesser option. So S/MIME shines inside organizations and between partners who have both set it up, and is close to useless for one-off messages to random external addresses.

The mental model that makes S/MIME less intimidating is the public-and-private key pair, which is the same idea underneath PGP and Proton. Your certificate contains a public key, which you hand out freely, and a private key, which never leaves your control. Anyone with your public key can lock a message that only your private key can open, and your private key can produce a signature that anyone with your public key can verify. Certificates from a trusted certificate authority simply add a layer of vouching on top — a recognized third party attesting that this public key really belongs to this email address — which is what lets organizations trust each other's keys without meeting in person. When people say S/MIME is "managed," this certificate lifecycle is what they mean: issuing, distributing, renewing, and revoking those credentials across a domain.

Turning it on is an administrator task, not something an individual user flips, because certificates have to be managed for the domain. That is a feature, not a bug, for a business: it means the organization can guarantee that everyone's mail can be encrypted and signed consistently, rather than leaving it to each employee to figure out. The flip side is that as an individual on a personal Gmail account, this route is simply closed to you, and you should mentally cross it off and head to Proton or PGP for end-to-end encryption. Here is the high-level path for those who do have an eligible Workspace account; the exact menus shift over time, so the specifics live in Google's admin documentation, which is linked in the sources.

1. 1

   Confirm your Workspace edition supports it

   Hosted S/MIME is available on Google Workspace Enterprise and Education editions. If you're on a personal Gmail account or a lower Workspace tier, S/MIME isn't an option — skip to Proton or PGP below for end-to-end encryption.

2. 2

   An administrator enables S/MIME in the Admin console

   A Workspace admin signs in at admin.google.com and goes to Apps, then Google Workspace, then Gmail, then User settings, and turns on "Enable S/MIME encryption for sending and receiving emails" for the relevant organizational unit, then saves.

3. 3

   Upload or provision certificates

   Each user needs an S/MIME certificate from a trusted certificate authority, uploaded for their account (often via the admin or an automated tool). This is what holds the keys that encrypt and sign their mail.

4. 4

   Compose and send to an S/MIME recipient

   Once enabled, a lock icon appears next to the recipient when you compose. Click it to see and set the encryption level; a green lock means S/MIME encryption is available for that recipient. Write and send as normal — Gmail encrypts it end-to-end provided the recipient also has S/MIME.

How do you send an encrypted email in Outlook and Microsoft 365?

Outlook's encryption story is, if anything, friendlier than Gmail's, because Microsoft built a one-click Encrypt button into the compose window for Microsoft 365 accounts. Like Gmail, Outlook offers two layers — a portal-based encryption that works for any recipient, and certificate-based S/MIME for true end-to-end between people who both have it set up. The Encrypt button is what most people want, so start there. One caveat before you go looking for it: the button is a Microsoft 365 feature tied to your organization's licensing, so it appears in business and many education accounts but may be absent or limited on a free Outlook.com address. If you do not see it, that is almost always the reason, and your fallbacks are the same as anyone else's — Proton, PGP, or a locked attachment.

The Encrypt button is powered by Microsoft Purview Message Encryption (you may also see it called Microsoft 365 Message Encryption or, historically, Office 365 Message Encryption). When you encrypt a message this way and send it to someone outside your organization, they receive a notification and open the message either in their own compatible mail client or through a secure web portal where they verify their identity — often with a one-time passcode — before reading it. The message is protected in transit and the recipient must authenticate to open it, which is meaningfully more private than a plain email. Within the same Microsoft 365 organization it is smoother still. Crucially, the button also offers usage restrictions: "Encrypt-Only" lets the recipient read and reply but keeps the protection attached, while "Do Not Forward" additionally blocks forwarding, printing, and copying. Here is the flow.

Where the Encrypt button earns its keep is reach. Unlike S/MIME or PGP, it does not care whether the recipient has any encryption setup of their own — a recipient on a plain Gmail account, on a phone, on whatever client they happen to use, can still open the message by verifying their identity through Microsoft's portal. That makes it the practical default for the common business situation of sending a sensitive message to an external party you cannot vet in advance. The honest caveat is the same one that applies to every portal-style method: Microsoft mediates the experience, so this is not the same as the provider being unable to read your message. It raises the bar and verifies the reader; it does not put the message beyond Microsoft's reach the way S/MIME does. For most business confidentiality needs that is a perfectly reasonable trade, but if your requirement is specifically that even Microsoft must not be able to read the content, you want S/MIME, covered next.

1. 1

   Start a new message and open the Options tab

   In Outlook (new Outlook, classic desktop, or Outlook on the web with a Microsoft 365 account), click "New mail" to compose, then go to the "Options" tab in the ribbon at the top of the message window.

2. 2

   Click Encrypt

   On the Options tab, click the "Encrypt" button. Depending on your version it may apply a default encryption immediately or open a small menu of choices.

3. 3

   Pick a permission level

   Choose "Encrypt-Only" to let recipients read and reply while keeping the message encrypted, or "Do Not Forward" to also block forwarding, printing, and copying. Your organization may offer additional custom policies in this menu.

4. 4

   Compose and send

   Finish writing and click "Send." A small lock or banner near the subject line confirms encryption is on. External recipients get an invitation to view the message and verify their identity (often via a one-time passcode) before reading it.

How do you turn on S/MIME for true end-to-end encryption in Outlook?

The Encrypt button is great for convenience, but for the strongest, certificate-based end-to-end encryption — the kind that holds up against the provider and proves the sender's identity cryptographically — Outlook supports S/MIME, just as Gmail Workspace does. The same two conditions apply: you need a valid S/MIME certificate installed, and the recipient needs S/MIME too, with certificates exchanged between you. Once that is in place, S/MIME both encrypts the message so only the recipient can read it and signs it so the recipient can verify it genuinely came from you and was not tampered with.

Setup is a one-time configuration per device. You install your certificate, point Outlook at it in the Trust Center, and then you can encrypt and sign individual messages — or set Outlook to do it by default for every message. Here is the path on the desktop client.

A small but important workflow note: because S/MIME encryption requires the recipient's public certificate, the very first exchange between two new correspondents is necessarily a two-step dance. You cannot encrypt to someone you have never received a signed message from, because you do not yet have their key. The standard fix is to send each other a digitally signed (but not encrypted) message first — signing only requires your own certificate, so anyone can do it unilaterally — and once that signed message lands, the certificate it carries is stored automatically, and every message after that can be fully encrypted. Build that handshake into how you onboard a new partner, and S/MIME stops feeling fiddly and starts feeling like infrastructure that simply works in the background.

1. 1

   Obtain and install an S/MIME certificate

   Get a personal S/MIME certificate from a trusted certificate authority (your IT department often provides one in a managed environment) and install it in your operating system's certificate store so Outlook can find it.

2. 2

   Point Outlook at your certificate

   In classic Outlook, go to File, then Options, then Trust Center, then Trust Center Settings, then Email Security. Under "Encrypted email," click "Settings," and choose your S/MIME certificate for signing and encryption.

3. 3

   Encrypt a message (or all messages)

   On a single message, use the "Encrypt" control on the Options tab and pick the S/MIME option, or enable "Encrypt contents and attachments for outgoing messages" in Email Security to do it by default. You can also turn on digital signing here.

4. 4

   Exchange certificates before sending

   To encrypt to a recipient, you need their public certificate, which arrives automatically the first time they send you a digitally signed message. Send signed mail to each other once, and from then on you can exchange fully encrypted S/MIME messages.

How do you send an end-to-end encrypted email with Proton Mail?

If end-to-end encryption is the goal and you would rather not wrestle with certificates or admin consoles, Proton Mail is the most direct path, because privacy is the product rather than a bolted-on feature. Proton is built on PGP under the hood, with the keys generated and held in a way Proton itself cannot read, which means mail you send is end-to-end encrypted by default in the cases where it can be. The important nuance — and the thing that makes Proton genuinely usable for real people — is that what "encrypted" means depends on who you are emailing.

Email another Proton Mail user and there is nothing to do: the message is automatically end-to-end encrypted between you, full stop. Neither Proton nor anyone in the middle can read it. The interesting case is emailing someone who is not on Proton — a regular Gmail or Outlook address. Proton solves this with a feature called password-protected emails (sometimes shown as Proton Mail's "encrypt for outside users"). You set a password on the individual message; Proton sends the recipient a notification with a link to a secure Proton-hosted page; they enter the password you both agreed on and read the message there, end-to-end encrypted. It is essentially a portal, like Outlook's Encrypt button, but built on Proton's encryption and available on every plan including Proton Free. Here is how to use both modes.

Two details make the password-protected mode more practical than it first sounds. First, it is genuinely two-way: the recipient can hit "Reply securely" on that Proton page and their response comes back to you end-to-end encrypted as well, so a sensitive exchange does not collapse into plaintext the moment the other person answers. There is a cap — a non-Proton recipient can send a limited number of these secure replies before they would need their own free Proton account for more — but for a typical back-and-forth it is plenty. Second, the expiration control means these messages do not linger: by default a password-protected message self-deletes after 28 days, and you can shorten that if you want the secure link to have a tighter window. Together those turn what could have been a one-shot "here is a secret" into a usable private channel with anyone, regardless of their provider.

It is also worth noting that Proton can interoperate with the wider PGP world, since it is built on the same standard. If your recipient already uses PGP, you can exchange public keys with them and send true end-to-end encrypted mail without the password portal at all — Proton handles the PGP machinery for you. That makes Proton a comfortable middle ground: automatic E2EE with other Proton users, password-protected E2EE for ordinary recipients, and standards-based PGP for the technically equipped, all from one inbox without you touching a command line. For most people who want strong encryption without becoming a key-management hobbyist, that combination is the path of least resistance.

1. 1

   Compose a new message in Proton Mail

   Sign in to Proton Mail (web or app) and click "New message." Add your recipient and write your email as usual.

2. 2

   If the recipient is on Proton, just send

   When you email another Proton Mail address, the message is automatically end-to-end encrypted — you'll see a lock indicator on the recipient. No password or setup is needed; click "Send."

3. 3

   For a non-Proton recipient, set a password

   Click the lock/padlock icon in the compose window ("Encrypt for non-Proton Mail users") and enter a password for the message, plus an optional hint. Avoid putting the actual password in the hint. This is the password the recipient will need to open it.

4. 4

   Optionally set an expiration, then send

   Use the expiration control to set when the message self-deletes (password-protected messages expire after 28 days by default). Click "Send." The recipient gets a link to a secure Proton page and enters the password to read — and can reply securely a limited number of times.

How do you add PGP encryption to Gmail with Mailvelope?

What if you want true end-to-end encryption but you are committed to your existing Gmail or other webmail account and do not want to migrate to Proton or pay for Workspace? That is what PGP browser extensions are for, and Mailvelope is the most widely used. PGP (Pretty Good Privacy) is the open standard underneath Proton and much of the privacy world: you generate a key pair — a public key you share freely and a private key you guard — and anyone who has your public key can encrypt a message that only your private key can open. Mailvelope grafts this onto Gmail (and other webmail) right in your browser, so the encryption happens on your machine before anything reaches Google's servers.

The trade-off is honesty about effort. PGP is the most manual of the methods here, and like S/MIME it requires the recipient to participate: you can only send an encrypted message to someone whose public key you have. The reward is encryption that is genuinely independent of your provider — Google handles only ciphertext it cannot read — and that works across any PGP-compatible recipient regardless of their email host. Here is the setup and first send.

Mailvelope is not the only option in this category — FlowCrypt is a popular alternative that integrates even more tightly with Gmail's own compose window — but the concepts are identical across all of them, so learning one teaches you all. The single idea to internalize is the direction of the keys, because it confuses almost everyone at first. You encrypt to someone using their public key, and they decrypt using their private key; conversely, they encrypt to you using your public key, and you decrypt using yours. Public keys are meant to be handed out widely — you can publish yours, email it, or upload it to a key server — while private keys never leave your device and are protected by your passphrase. If you keep that picture straight, the rest of PGP is just plumbing: generate a pair, collect the public keys of the people you write to, and let the extension do the math.

One practical reality worth setting expectations on: PGP has a well-earned reputation for being unforgiving, and the friction is almost always about key management rather than the encrypting itself. Losing your private key or forgetting its passphrase means losing access to everything that was encrypted to you, permanently, with no recovery. Getting a stranger's authentic public key — and being sure it is really theirs and not an impostor's — takes a moment of care. This is precisely why managed options like Proton and S/MIME exist: they automate the parts of PGP that bite. Choose Mailvelope or FlowCrypt when you specifically want provider-independent encryption on top of your existing webmail and are willing to take responsibility for your keys; otherwise Proton will get you to the same end-to-end destination with far less to maintain.

1. 1

   Install the Mailvelope extension

   In Chrome, Firefox, or Edge, go to the extension store, search for "Mailvelope," and add it to your browser. A small Mailvelope icon appears in your toolbar.

2. 2

   Generate your PGP key pair

   Open Mailvelope's setup and choose "Generate key." Enter your name and the email address of the webmail account you'll use, then create a strong passphrase. Write that passphrase down somewhere safe — Mailvelope does not store it, and you cannot recover it if it's lost.

3. 3

   Exchange public keys with your recipient

   Encryption needs the recipient's public key. Import it into Mailvelope (ask them to send it, or look it up on a public key server) and share your own public key with them so they can encrypt replies to you. Without their public key, you can't encrypt to them.

4. 4

   Compose and encrypt in Gmail

   In Gmail, click the Mailvelope compose icon next to the normal compose button, write your message in Mailvelope's secure editor, add the recipient, and click "Encrypt," then send. Google only ever sees the encrypted ciphertext; the recipient decrypts it with their private key.

What about the password-protected attachment workaround?

Every method so far depends on the recipient having the right setup, the right provider, or the patience to open a portal. There is one approach that sidesteps all of that and works with literally any email account: do not encrypt the email at all — encrypt the file, and send the password separately. It is the duct tape of email security, unglamorous and surprisingly effective, and it is often the right answer when you are sending a sensitive document to someone you cannot count on to have anything fancy.

The idea is simple. If the sensitive part of your message is a document — a contract, a statement, a scan — you password-protect that file before attaching it. Most tools you already have can do this: Microsoft Word, Excel, and PowerPoint can save with a password (File, then Info, then Protect Document, then Encrypt with Password); Adobe Acrobat and many free PDF tools can lock a PDF; and you can wrap any files in an encrypted ZIP archive with a password using 7-Zip or your operating system's built-in tools. The file rides along as a normal attachment on a normal email, and without the password it is just unreadable bytes. Then — and this is the part that makes or breaks it — you deliver the password through a completely different channel.

The reason this humble trick deserves a place alongside Proton and PGP is that it is the only approach with zero requirements on the recipient's email setup. They do not need an account anywhere special, a certificate, a key, or even much technical skill — almost everyone knows how to type a password into a PDF prompt. For sending a tax form to an accountant, a signed contract to a counterparty, or onboarding paperwork to a new hire, that universality is often more valuable than the theoretical elegance of full email encryption. The file is encrypted on your machine before it is attached, so even though the email body itself travels with only ordinary provider encryption, the sensitive payload inside it is sealed end to end in practice, as long as the password is handled correctly.

Be clear-eyed about the limits, though, because they are real. Not all file encryption is equal: a modern AES-256 ZIP or a properly encrypted PDF is strong, but the older or weaker password schemes in some tools can be broken, and any short or guessable password can be cracked by brute force regardless of the algorithm. "Permissions" passwords on PDFs that merely restrict printing or editing — as opposed to an "open" password that encrypts the contents — can often be stripped in seconds by free tools, so make sure you are setting a password that actually encrypts the document to open it, not just one that nags about permissions. And the most fundamental limit applies here as everywhere: once the legitimate recipient opens the file, they can save an unprotected copy and do whatever they like with it. The workaround protects the document in transit and at rest in the recipient's inbox; it does not control the recipient.

1. 1

   Password-protect the file

   In Word, Excel, or PowerPoint, go to File, then Info, then "Protect Document" (or "Protect Workbook"), then "Encrypt with Password," and set a strong password. For a PDF, use Acrobat's "Protect" tool or a trusted PDF utility. For mixed files, create an encrypted ZIP with 7-Zip (choose AES-256) or your OS's archive tool.

2. 2

   Use a strong, unique password

   Make it long and not guessable — a passphrase of several random words is ideal. A weak password defeats the whole exercise, because PDF and ZIP passwords can be brute-forced if they're short or common.

3. 3

   Attach the file and send the email

   Attach the encrypted file to a normal email and send it. Do not put the password anywhere in this email — not in the body, not in the file name, not in the subject.

4. 4

   Share the password on a separate channel

   Tell the recipient the password by phone call, text message, or a secure messaging app — anything other than the same email thread. Agreeing on it in advance is even better. This separation is what gives the workaround its real protection.

Which encryption method protects what? A side-by-side comparison

The methods in this guide are not interchangeable, and the labels do not make the differences obvious — "confidential," "encrypt," and "secure" get used loosely across all of them. The table below cuts through it: for each method, what it genuinely protects against, whether your provider can still read the message, and what the recipient needs in order to receive it. Read the "Provider can read it?" column especially carefully, because that single distinction separates true end-to-end encryption from everything that merely looks like it.

If you take only one thing from the comparison, let it be this: the column that says whether the provider can read the message is the column that defines what "encrypted" actually means for your situation. Everything in the "Yes" or "mediated" rows is, at heart, access control and identity verification layered on mail your provider can still see — valuable, and right for plenty of cases, but not secrecy from the provider. Everything in the "No" rows is true end-to-end encryption, and notice that every single one of them asks something of the recipient in return: an account, a certificate, a key, or a password. That trade is not an accident or a missing feature; it is the inescapable physics of encryption, which needs a key at both ends. Any product that promises strong encryption with zero effort for the recipient is either quietly doing access control, or quietly holding the keys itself.

How does AI Emaily keep your mail secure across every provider?

Step back from the individual buttons and a pattern emerges: encryption is something you bolt onto a message, one at a time, and only when you remember to — while the inbox itself, the place all your mail lives day to day, runs on whatever privacy posture your provider chose for you. You can become an expert at confidential mode, S/MIME, Proton passwords, and PGP, and your everyday email is still only as private as the foundation underneath it. AI Emaily is built to make that foundation a deliberate choice rather than an afterthought.

AI Emaily is an AI-native email client that connects to the accounts you already use — Gmail, Outlook, iCloud, Fastmail, and any IMAP mailbox — and brings them into one private workspace. It is provider-agnostic by design, which is the relevant part here: it works alongside the very providers and methods in this guide rather than replacing them, and that explicitly includes end-to-end encrypted providers. If you keep Proton for your most sensitive correspondence, AI Emaily is built to work with secure providers like it too, so you don't have to choose between a private mail host and a capable client. To be clear about the boundary: AI Emaily does not itself send messages with end-to-end encryption — when you need true E2EE on a specific message, you still reach for Proton, S/MIME, or PGP as described above. What AI Emaily provides is a secure foundation for the inbox as a whole.

That distinction matters because it is honest, and honesty is the whole point of a guide like this. Plenty of products would happily blur the line and let you believe their assistant somehow makes every message end-to-end encrypted. It does not work that way, for anyone, for the reasons the comparison table laid out: true E2EE needs keys at both ends, and no client can conjure that for a recipient who has not set it up. So rather than overclaim, AI Emaily focuses on the part it can genuinely own — handling your mail privately and securely across every account — and stays out of the way when a specific message needs the heavier machinery of Proton, S/MIME, or PGP. You get a private home for your everyday email and a clear-eyed sense of when to step up to dedicated encryption, instead of a false promise that one button does it all.

That foundation rests on a few concrete commitments. Your data is encrypted in transit and at rest, and AI Emaily connects to your accounts over secure connections, so your mail isn't handled in the clear. Just as important for an AI product: the assistant is private by design. The models that draft, summarize, and triage your email are never trained on your mail, and your content isn't turned into training data for anyone. For a tool that reads your inbox to be useful, that no-training guarantee is the line that matters, and it's the line a lot of free AI email features quietly cross.

There is also a practical security benefit to having an agent mediate your inbox rather than a raw webmail page. The most common privacy failure in email is not exotic — it is sending the wrong thing to the wrong person, or firing off a reply in a hurry that should have been encrypted or never sent at all. Because AI Emaily acts as an approval-gated assistant, it can draft in your voice while keeping a human in the loop before anything goes out, which is exactly the kind of friction that prevents the everyday mistakes encryption can't help with. You stay in control of the send; the assistant does the work up to that point.

It also helps to think about where the bulk of your privacy risk really lives. The handful of messages you consciously decide to encrypt are, almost by definition, the ones you are already being careful with. The quieter risk is the thousands of ordinary emails flowing through your accounts every year — the ones you never think to protect, that accumulate in your provider's storage, that an AI feature somewhere might be reading to improve a model. A method-by-method approach to encryption does nothing for that vast middle, because you will never remember to lock every message, and you shouldn't have to. The case for a privacy-first client is that it raises the floor for the whole inbox at once: secure connections, encrypted storage, and a no-training guarantee that apply to every message automatically, so the protection is structural rather than something you opt into one email at a time.

AI Emaily is free to start at $0, with a Pro plan at $17.99 per month billed annually when you want higher volume and the full toolkit. If you have read this far because you care how your email is handled, the takeaway is that privacy shouldn't only live on the handful of messages you remember to encrypt — it should be the baseline for the whole inbox, across every account you connect, with an assistant that never trains on your mail. You can create an account at app.aiemaily.com/signup and connect your mailbox in a few minutes.

Putting it all together

Sending an encrypted email is really a two-step decision, and the second step is the one most guides skip. Step one is honest triage: does this message need access control (don't forward it, expire it) or true end-to-end secrecy (the provider must not be able to read it)? Step two is matching that to what your recipient can actually receive. Get both right and the method picks itself.

In Gmail, confidential mode is the free, built-in choice for adding a shelf life and no-forward control to mildly sensitive mail — just remember it is access control, not encryption, and Google can still read it. For true encryption in Gmail you need S/MIME on a paid Workspace tier, with both sides set up. In Outlook and Microsoft 365, the Encrypt button (with "Encrypt-Only" or "Do Not Forward") covers most needs and reaches any recipient through a secure portal, while S/MIME delivers maximum, provider-proof secrecy between prepared parties. Proton Mail is the easiest route to genuine end-to-end encryption: automatic between Proton users, and a password-protected message for everyone else. PGP through Mailvelope brings provider-independent end-to-end encryption to Gmail and other webmail if you're willing to manage keys. And when you can't rely on the recipient's setup at all, lock the document and send the password on a separate channel — it works with any inbox on earth.

If you remember nothing else, remember the two-question test, because it resolves almost every real decision faster than any feature comparison can. Question one: do I need to stop this from being forwarded and lingering, or do I need to stop the provider itself from ever reading it? That tells you whether to reach for access control or for true end-to-end encryption. Question two: what can my recipient actually open? That tells you which of the methods in your chosen tier is realistic right now. Access control for a trusted colleague is a two-click affair; true secrecy to an unprepared stranger almost always lands on a Proton password-protected message or a locked attachment with the password sent separately. Internalize those two questions and you will never again stare at a sensitive draft wondering which button to press.

The thread running through every method is that encryption protects the message, not the moment a human reads it, and that the strongest options always ask something of the recipient. So choose the recipient as carefully as the method, share passwords on a second channel, and don't mistake a feature named "confidential" or "secure" for end-to-end encryption. Finally, if you care enough about privacy to encrypt individual messages, it's worth applying that standard to the whole inbox: a client like AI Emaily gives you encrypted storage, secure connections, and an assistant that never trains on your mail, across Gmail, Outlook, Proton, and every account you connect — so privacy is the default, not a button you have to remember to press.