Email was designed in the 1980s to move plain text between trusted machines, and every security property it now has was bolted on later. Most of the time that is fine. When you are sending a contract, a payroll file, a medical record or a client's identity documents, "most of the time" is not a standard. This is a practical account of what protection email actually gives you, what it does not, and which of the available options is right for which kind of document.
What happens to an email attachment
A message travels from your client to your provider's server, from there to the recipient's server, and finally to their client. In 2026 the hops between reputable providers are almost always encrypted in transit with TLS, which stops passive interception on the wire.
What that leaves:
- The message sits unencrypted at rest on your provider's servers and the recipient's. Both organisations, their administrators, and anyone with lawful or unlawful access to those accounts can read it.
- It is copied. Sent items, backups, journaling systems, archiving appliances, spam filters, DLP scanners.
- It is forwardable by the recipient to anyone, instantly and invisibly to you.
- You cannot recall it. "Recall" works only within some corporate environments and only sometimes.
- Mis-addressing is the dominant risk. Autocomplete sending a payroll spreadsheet to the wrong Sarah is, empirically, a far more common cause of data incidents than interception.
- TLS is opportunistic. If the receiving server does not offer it, many senders will deliver in plain text rather than fail. MTA-STS and DANE fix this, and are not universal.
The realistic threat model, then, is not a wiretap. It is the wrong recipient, a compromised mailbox, and an unbounded number of copies you no longer control.
Option 1: encrypt the document itself
The simplest meaningful improvement: password-protect the PDF, then send the password by a different channel.
This is genuinely effective against mis-addressing and against mailbox compromise, provided you get the second part right:
- Use AES-256, which every current tool offers. See AES-128 vs AES-256 PDF encryption.
- Use a strong, unique password — the encryption is only as good as the passphrase, and a four-digit date is not protection.
- Send the password over a genuinely separate channel: a phone call, an SMS, a signal message. Not a second email, and emphatically not the same email.
- Understand what you are encrypting. An open password (required to view) is real cryptography. A permissions password (restricting printing or copying) is a request the viewer may honour, and is trivially stripped. The distinction is set out in PDF permissions explained and PDF encryption explained.
Practical mechanics: how to password protect a PDF.
Limitations: it protects the file, not the metadata around it. The subject line, the filename, the fact that you sent it, and the recipient list are all in clear. Redundancy_Notice_J_Miller.pdf in a subject line is a disclosure regardless of the encryption inside.
Option 2: send a link, not a file
Upload the document to storage you control and send an access link. This is the approach most organisations end up at, and for good reasons:
- Access can be revoked after sending. This alone is a substantial improvement over email.
- Access can be scoped to named accounts rather than to whoever holds the message.
- Access is logged, so you know whether it was opened and by whom.
- Links can expire, which bounds exposure by default rather than by intention.
- The file is not copied into four mail archives.
Set it up properly, though. A link with "anyone with the link can view" and no expiry is worse than an attachment, because it will be forwarded, indexed, and still live in two years. Require authentication, set an expiry, and use view-only permissions where download is not needed. Storage options and their differences: choosing cloud storage for documents, using PDFs with Google Drive, using PDFs with SharePoint.
Fuller treatment: how to share a PDF securely.
Option 3: encrypted email
Genuine end-to-end email encryption exists, and its problem has always been adoption rather than mathematics.
S/MIME — certificate-based, well supported in Outlook and Apple Mail, standard in enterprise and government environments. Requires both parties to hold certificates and to have exchanged public keys. Where it is deployed, it works transparently and well.
PGP / GnuPG — the open equivalent, with a long history and a persistent usability problem. Excellent among people who already use it, unavailable in practice with an ordinary counterparty.
Provider-side encrypted delivery — Microsoft Purview Message Encryption, Google Workspace's client-side encryption, and the various "secure message portal" products. The recipient gets a notification and authenticates to a portal to read the message. Not end-to-end in the strict sense, since the provider mediates, but a real improvement and, crucially, workable with recipients who have installed nothing.
For a one-off exchange with an external party, option 1 or 2 will get you there faster. For a standing flow of sensitive documents with a known counterparty, S/MIME or a portal is the correct investment.
Before you send: reduce what is in the file
Encryption protects a document from outsiders. It does nothing about what the document itself discloses to its intended recipient.
- Strip metadata. Author names, the file's edit history, the original filename, the software used, GPS data in embedded photographs. See how to strip metadata from a PDF and hidden data in PDFs explained.
- Redact properly. A black rectangle drawn over text hides nothing — the text is still in the file and comes out with a copy-paste. Use real redaction: how to redact text in a PDF and PDF redaction failures and how to avoid them.
- Check comments and annotations. Internal review comments regularly ship to clients. Flatten before sending: how to flatten a PDF.
- Check hidden layers and cropped content. Cropping a PDF hides content without removing it.
- Send only the pages needed, not the whole pack — see how to extract pages from a PDF.
Regulated data
If the document falls under a specific regime, the rules are more prescriptive than general good practice:
- Health information — HIPAA-compliant PDF handling covers what "appropriate safeguards" means for transmission, and why an unencrypted attachment to a patient is a documented decision rather than an oversight.
- Personal data of EU or UK residents — GDPR and PDF documents, where the relevant concept is appropriate technical measures proportionate to risk, and a breach caused by mis-addressing is reportable.
- Financial and legal records — usually governed by sector rules and by your own retention policy: document retention policies.
The common thread in all three: the control you can demonstrate matters as much as the control you applied.
The habits that prevent most incidents
Technical measures address a minority of real-world failures. These address the majority:
- Address the message last. Compose, attach, check, then fill in the recipient. It makes premature and mis-addressed sending nearly impossible.
- Turn off or slow down autocomplete for external addresses, or configure a warning for external recipients. Most mail platforms support this and most organisations leave it off.
- Set a send delay — even 30 seconds catches a startling proportion of mistakes.
- Verify the attachment is the one you meant, by opening it from the draft rather than trusting the filename.
- Check the recipient list on replies, especially reply-all on a thread that has grown people you did not add.
- Name files so the name itself is not a disclosure — see naming and versioning shared files.
Summary
Email gives you transport encryption and nothing else: the message rests unencrypted at both ends, gets copied everywhere, and cannot be recalled. For a one-off, encrypt the PDF with AES-256 and send the password by phone. For anything ongoing, send an authenticated, expiring link instead of a file so access can be revoked. Strip metadata and redact properly before either. And address the message last — mis-addressing causes more incidents than every cryptographic weakness combined.
