Sending documents by email without the email reading them

Email is the most widely-used insecure transport on the internet. A typical email in 2026 passes through at least three and often five or more server hops between sender and recipient, is stored indefinitely at both ends and often in the middle, is fully readable to the email providers on both sides, is indexed by at least one of them for spam or search, and is subject to subpoenas, breaches, employee access, and accidental forwarding throughout that chain.

When you send a sensitive document as an email attachment, you are not sending it to the recipient — you are sending it to the infrastructure that serves the recipient, which has a long memory.

There are ways to make email private. None of them are frictionless. This is a tour of what’s available and when each makes sense.

Why email is broken for sensitive content

Email was designed in the 1970s to pass messages between research computers. Confidentiality was not on the list of goals. The consequences:

• SMTP, the protocol that moves email between servers, was originally plaintext. TLS was added as an optional upgrade (STARTTLS) in the 2000s. It’s now widely deployed, but it’s hop-by-hop — each server in the chain decrypts and re-encrypts, seeing the plaintext at each step.
• Most email providers read your email. Not a scandal — the design assumes they can. They run spam filters, virus scans, search indexing, and in some cases ad targeting, all of which require reading content.
• Subpoenas and legal process operate on stored email. Providers hand over content when served with appropriate orders.
• Breaches happen. When a mail provider is breached, stored email is exposed. Historical breaches at Yahoo (2013), Microsoft (2023), and others have exposed hundreds of millions of mailboxes.
• Forwarding leaks everything. An email forwarded three times carries all the attachments and signatures of the original, often across organizational boundaries.

None of this is a reason to stop using email. It’s a reason not to use email in its naive form for documents you would not post on a bulletin board.

Tier 1: password-protected attachment, regular email

The lowest-friction option. Works with any recipient, on any email service, with no software installation on either side.

1. Create the document.
2. Export as PDF with a password (AES-256). On Mac, File → Export as PDF with the security checkbox. On Windows, print to PDF then open in Acrobat or a similar tool to add the password. Or use qpdf --encrypt.
3. Attach to the email and send.
4. Separately — SMS, phone call, Signal — send the password.

This protects the attachment. The email body itself is still plain, so don’t include sensitive content in the body. See password-protected PDFs done right for the specific technique.

When this is enough: most personal sharing with professionals who aren’t technical. Tax returns to accountant, signed contracts to lawyer, lab results to specialist.

When it isn’t: when you need to exchange many documents, when you want metadata (subject line, body, recipient list) protected too, or when the recipient is also security-aware and would prefer a proper E2EE channel.

Tier 2: a privacy-first email provider

The next step up in confidentiality and convenience. Services like ProtonMail, Tutanota, Posteo, and Mailbox.org are regular email providers (IMAP/SMTP-compatible for the most part) that add end-to-end encryption when both sides use them.

ProtonMail

• Based in Switzerland.
• Automatically end-to-end encrypted between ProtonMail accounts.
• Offers password-protected emails to non-Proton recipients: you set a password; the recipient gets a link; they type the password in a browser to read the message. Deliver the password out-of-band.
• Supports PGP (you can add an external contact’s PGP key, or share your own).
• Free tier; paid from €4/month.

Tutanota

• Based in Germany.
• Similar E2EE between Tutanota accounts.
• Similar password-protected email to external recipients.
• Custom encryption (not PGP-based), which some see as a feature and some as a limitation.
• Free tier; paid from €3/month.

How this actually works day-to-day

You send an email. If the recipient also has ProtonMail (or Tutanota, in Tutanota’s case), it’s automatically encrypted — nothing to configure. If they don’t:

• Option A: compose with “Password-protected” toggled on; set a password; send the password to them separately.
• Option B: find their PGP public key (if they have one), add it to your contact; emails to them are signed and encrypted.
• Option C: send unencrypted. Same as regular email.

When this is enough: recurring sensitive correspondence, or sending documents to anyone else who uses the same service. Works well for solo practitioners and for professional-client relationships where both sides value privacy.

When it isn’t: if your recipient needs to send you things and refuses to switch providers, you’re back to the tier-1 or tier-3 options. Also, the metadata (subject line, who emailed whom, when) is still visible to the provider.

Tier 3: S/MIME

S/MIME is the enterprise-grade email encryption standard. It uses X.509 certificates issued by commercial or internal certificate authorities — the same kind of cert technology as TLS.

When this is relevant

• Microsoft 365 environments with Exchange Online. S/MIME is well-integrated. Many regulated enterprises use it as standard.
• Enterprise to enterprise communication between organizations that both have S/MIME deployed.
• Apple Mail has native S/MIME support; iOS and macOS clients can encrypt and sign.

Setup, at a high level

1. You obtain an S/MIME certificate. In a corporate environment, IT provisions one through a managed CA. For individuals, Actalis and a few others offer free personal S/MIME certs (validity is limited).
2. Install the cert in your mail client. The private key lives on your device (or in your keychain).
3. Share the public part with correspondents — typically by sending them a signed email; their mail client extracts the public cert.
4. Received signed emails can be verified. Encrypted ones require the recipient’s public cert in your address book.

Pros and cons

• Pros: Standards-based, widely supported in corporate mail clients, strong cryptography, integrates with existing enterprise identity.
• Cons: Key-management complexity (certificates expire, renewals must be coordinated); limited utility between non-enterprise correspondents; tied to specific mail clients; browser-based webmail usually can’t handle it.

When this is right: you’re in a corporate environment that already uses S/MIME, or your correspondents do. Don’t try to set this up if you’re a solo user with Gmail. Use tier 2 instead.

Tier 4: PGP / GPG

PGP is the grandparent of email encryption — a public/private key system with no central authority, published keys on keyservers or your own website. For documents, it’s also the tool covered in Tar, encrypt, upload: using GPG.

How email-PGP works

1. You generate a key pair (public + private). Private key stays on your device; public key is shared.
2. Your correspondent does the same.
3. You exchange public keys and verify the fingerprints — this is the critical step that prevents a man-in-the-middle attack.
4. Your mail client (Thunderbird with built-in support; Mail.app with GPGTools; Outlook with GPG4Win) encrypts outgoing messages to their public key and decrypts incoming ones with your private key.

Clients that handle PGP well

• Thunderbird — as of version 78, PGP support is built in (no Enigmail plugin needed).
• Apple Mail via GPG Suite (paid, well-maintained).
• Outlook via GPG4Win + Gpg4o.
• ProtonMail has PGP support built-in, blurring the line between tier 2 and tier 4.

Why most people don’t use PGP

• Key management is genuinely hard. Lost keys = lost decrypted archive. Compromised keys = compromised ecosystem.
• Most correspondents don’t have PGP keys. You can’t encrypt to someone who hasn’t set it up.
• The user experience in most clients is workable but not lovely.

When PGP is worth it

• Long-standing correspondence with other technical users.
• Professional contexts where metadata matters less than content confidentiality and where both parties are comfortable with the workflow.
• Encrypting files for archival or transfer (where GPG shines more than in email).

The pragmatic tier selection

For a normal person:

• Default: tier 1 (password-protected PDF, regular email, out-of-band password).
• Long-term relationship with someone privacy-aware: both of you move to tier 2 (ProtonMail or Tutanota). One-time setup, automatic from then on.
• Corporate environment: tier 3 (whatever your IT has deployed; S/MIME is the usual answer).
• Technical correspondent, specific use case: tier 4 (PGP), ideally scoped to specific high-stakes threads.

The wrong answer for almost everyone is “I want to do tier 4 on everything I send.” The setup cost exceeds the value. The right answer is matching the tool to the thread: most email is routine, and should be sent normally; the minority that matters gets whichever tier buys you enough protection for the lowest friction.

And for the especially sensitive ones, the question “is email the right transport for this at all?” is worth asking honestly. The answer is often: use the recipient’s secure portal, use Signal, use a shared E2EE folder. Email is a universal solvent; it’s also the one transport that keeps a searchable copy of everything you ever send.