How to send documents securely through email — 7 methods, ranked by what they actually protect

Email was not built to be private, and most advice about it protects the wrong thing. What each method really defends against — Gmail confidential mode, Outlook encryption, S/MIME, encrypted files, secure links — and which one to use for a passport, a payslip or a contract.

22 September 2026 · How to

Before choosing a method, be clear about what you are defending against, because the four threats are different and almost nothing defends against all of them.

1. Somebody reading it in transit. Mostly solved already, and the thing every guide talks about.
2. Somebody reading it later — in a mailbox left signed in, in a backup, in the copy still sitting on a mail server years from now.
3. The recipient passing it on, deliberately or by forwarding a thread without thinking.
4. You sending it to the wrong person. The most common by a wide margin, and the only one where encryption makes matters worse, because the wrong person now has both the file and your trust.

Is email encrypted already?

Partly, and it is worth knowing exactly how much.

Mail between servers travels over TLS almost universally now, so the classic image — someone reading your attachment off the wire — is largely obsolete. What TLS does not do is protect the message at rest. Your copy sits in your Sent folder, theirs sits in their inbox, and both sit on mail servers that keep them long after either of you has forgotten. An attachment sent once exists in at least four places forever, none of which you control.

That is the gap every method below tries to close.

The short version

\* the file stays encrypted when forwarded, but so does the password, once the recipient passes that along too.

1. Encrypt the file, send the password another way

The simplest method that genuinely works, and the one that needs nothing from your recipient's email provider.

Put a password on the PDF itself — Preview on a Mac, LibreOffice on Windows, qpdf at a terminal — and attach it as normal. The file is ciphertext wherever it ends up: in transit, in both mailboxes, in every backup.

The rule that makes it work: never send the password in the same channel as the file. A password in the email body protects nothing. Text it, say it on the phone, or use one they already have. This is where most people quietly skip a step and end up with the illusion of security rather than the thing.

We wrote the full method up separately: how to password protect a PDF.

What it does not do: stop your recipient forwarding both, and give you any way to take it back or find out whether it was read.

2. Gmail confidential mode

Gmail has a built-in mode that adds an expiry date, an optional SMS passcode, and removes the forward, copy, print and download buttons. Click the padlock with a clock on it when composing.

It is genuinely useful and routinely oversold. Three things to know:

• It is not end-to-end encryption. Google can still read the message.
• Recipients can screenshot. Removing the download button is not the same as stopping a copy — a phone camera defeats it entirely.
• The SMS passcode is regional. Not every country is supported, and the passcode goes to a number you type, which must be right.

What it is genuinely good at is the third threat: casual forwarding, and the thread that gets passed along with an attachment nobody reread. It is also the only method here that lets you revoke access after sending, which is worth more in practice than another few bits of key length.

3. Outlook and Microsoft 365 encryption

If your organisation is on Microsoft 365, Outlook has Options ▸ Encrypt, offering Encrypt and Do Not Forward. This is Microsoft Purview Message Encryption, built on Azure Rights Management, and it protects the message inside and outside the organisation — including to Gmail recipients, who read it through a web viewer.

Do Not Forward is the strongest of the mainstream options, because the restriction travels with the message rather than being a property of one mailbox.

The catch is licensing. It comes with Office 365 E3 and above; on smaller plans such as Exchange Online Plan 1 or Office 365 E1 you add Azure Information Protection Plan 1 to get it. If the Encrypt button is missing from your Outlook, that is why, and no amount of clicking will produce it.

4. S/MIME or PGP — real end-to-end, real friction

These are the only methods here that are end-to-end encrypted in the strict sense: nobody between you and the recipient can read the message, including your own email provider.

Both need the same thing first — the recipient's public key or certificate — and that exchange is where the method usually dies. S/MIME certificates are issued per address and cost money or come from a corporate CA; PGP means generating a keypair and getting them to do the same.

Use them when you will be sending to the same person for years, such as a lawyer, an accountant, a co-founder. Do not attempt them for a one-off document to someone who has never heard of them, because the realistic outcome is a plaintext attachment sent in frustration twenty minutes later.

5. An encrypted mail provider

Proton Mail and Tuta encrypt mailbox contents at rest and offer password-protected messages to recipients on any provider: they get a link, type the password you agreed, and read the message in a browser.

This is a good answer if you send sensitive documents regularly and are willing to move your mail. It is a poor answer to "I need to send my passport to a letting agent this afternoon", since it requires a new account for you and a password conversation with them anyway.

6. Send a link instead of the attachment

Attachments are the problem. They are copies — uncontrolled, unrevokable, un-updatable, and capped at 25 MB by Gmail anyway. A link is a pointer to one file that stays yours.

Google Drive, Dropbox and OneDrive all do this, and if the recipient is inside your organisation they do it well. Where they get awkward is outside it: sharing settings that quietly default to "anyone with the link", a sign-in prompt for an account your recipient does not have, and no way to know whether the document was actually read.

This is the shape of the problem PDFLink exists for. You upload the PDF, you get an address, and you send the address:

• Put a password on the link, and change or remove it after sending.
• Set an end date, so the document stops being live once it is stale.
• Retire it entirely the moment you need to — the link stops working for everyone who has it, including the person you sent it to.
• Ask for an email before the document opens, so a forwarded link tells you who is reading.
• Watermark each view with the reader's own email, which does more to stop a document being passed on than any technical control.
• See who opened it, when, and how far they read.
• Swap the file for a corrected version without sending anything again.

And the honest limits. A link protects the delivery, not the file: once somebody downloads the PDF, it is an ordinary PDF and you no longer control it — so turn downloading off when that matters. It is not end-to-end encrypted; we hold the file, as Google does with Drive. If the document must stay encrypted wherever it travels, encrypt it with method 1 and send that file through a protected link. The two stack, and together they cover every threat in the list at the top of this page except the last one.

7. A one-off secure transfer service

Dropbox Transfer, Tresorit Send, SendSafely and WeTransfer Pro all do password-protected, expiring, one-time transfers with no account for the recipient. They are a reasonable answer for a large file going to somebody once and never again. They are a poor answer for a document you will revise, because each revision is a new transfer and a new link.

The threat nobody prepares for: the wrong recipient

More documents are exposed by autocomplete than by cryptography. You type the first three letters of a name, the client picks a different person with the same ones, and a payslip goes to a stranger.

Three settings worth changing today, all of them free:

• Turn on undo send and set it to 30 seconds — Gmail and Outlook both have it, and both default to less.
• Turn on external-recipient warnings if your organisation offers them, so an outside address in a thread is flagged before it is too late.
• Attach the file last. Compose, check the recipients, then attach. It sounds trivial and it is the single most effective habit on this page.

And structurally: a link you can revoke is the only method here that survives this mistake. Everything else is unrecoverable the moment Send is pressed.

What to use for what

• Passport, driving licence, bank statement to a company — password protect the file (method 1) and send the password by text. If they offer their own secure upload portal, use theirs instead; it is their risk to hold.
• A contract or proposal to a client — a link with an end date and open tracking (method 6). The revocability matters more than encryption here, and knowing it was read is the whole point.
• Payroll or HR documents inside a company — Outlook's Do Not Forward (method 3), if you have the licence for it.
• Medical or legal records under a compliance regime — neither plain email nor a consumer file host is enough on its own; you need a provider that will sign a data-processing agreement and produce an audit trail.
• Something genuinely sensitive to somebody technical — S/MIME or PGP (method 4), set up once and used for years.

Is email encrypted by default?

In transit, usually yes: mail servers negotiate TLS between themselves and have done so near-universally for years. At rest, no. Copies of your message sit in your Sent folder, the recipient's inbox and on both mail providers' servers, readable by anyone with access to those accounts and by the providers themselves.

Is Gmail confidential mode secure?

It is useful but it is not encryption. Google can read the message, recipients can screenshot or photograph what they cannot download, and the SMS passcode works only in supported regions. What it genuinely provides is an expiry date, the ability to revoke access after sending, and a barrier to casual forwarding. Treat it as access control, not secrecy.

What is the safest way to email a passport or a bank statement?

Encrypt the PDF with a strong password, attach it, and send the password by a different route — a text message or a phone call, never the same email. If the organisation offers a secure upload portal, use that instead: it takes the document out of email altogether and makes holding it their responsibility.

Can I password protect an email attachment?

Not the attachment itself — you password protect the file before attaching it. PDFs support this natively; so do Word, Excel and PowerPoint documents, and 7-Zip archives. Only Microsoft 365's Encrypt option and similar provider features protect the message as a whole.

Does zipping a file with a password make it secure?

A modern zip tool using AES-256 does encrypt the contents properly, so in transit and at rest it is sound. Two practical problems: older zip encryption is weak and some tools still default to it, and the moment anyone extracts the archive the file inside is unprotected and forwardable. Encrypting the document itself keeps the protection attached to the thing that matters.

How do I send a document securely to someone who is not technical?

Send a link with a password, and tell them the password by phone or text. It needs nothing installed, no account, no certificate exchange, and works on a phone — and unlike an attachment, you can revoke it if you get the address wrong.