When someone asks you to send a copy of your passport, a signed contract or a bank statement, the instinct is to attach it to an email. It feels private — you typed a specific address, hit send, done. In reality, that attachment may pass through half a dozen servers, get copied multiple times and remain accessible to your email provider indefinitely.
Email was designed in the 1970s and 1980s for plain text messages between university researchers. File attachments were bolted on later. Security was never part of the original design.
When you send an email with an attachment, the following happens:
At every step, the attachment exists in plaintext on a server. Your email provider has a copy. The recipient's provider has a copy. If there are intermediate relay servers, they may have copies too.
Modern email uses TLS (STARTTLS) to encrypt the connection between servers. But this is hop-by-hop encryption, not end-to-end. Each server along the route decrypts the message, processes it and re-encrypts it for the next hop. At every server, your attachment is readable.
Worse, STARTTLS is opportunistic. If a server does not support it, the message falls back to plaintext transmission. You have no way to know whether this happened.
Gmail, Outlook, Yahoo and other providers scan email attachments for multiple purposes:
Once an email is delivered, the attachment sits in both the sender's "Sent" folder and the recipient's inbox. It remains there until someone manually deletes it. In practice, most people never delete old emails. Your passport scan from five years ago is still sitting on Google's servers.
Even if you delete the email, it moves to Trash and stays for 30 days. And backups may retain it for much longer. You have no control over the retention policy of the recipient's email provider.
You send a contract to your lawyer. Your lawyer forwards it to a paralegal. The paralegal forwards it to an external consultant. Each forward creates another copy on another server. You have no visibility into who has accessed your file and no ability to revoke access.
Email accounts are among the most frequently targeted in cyberattacks. Phishing, credential stuffing and password reuse give attackers access to millions of accounts every year. When an account is breached, the attacker has access to every attachment ever sent or received.
A single compromised email account can expose years of sensitive documents: tax returns, ID scans, medical records, contracts and financial statements.
PGP and S/MIME provide true end-to-end encryption for email, including attachments. In theory, they solve the problem. In practice, they have failed to achieve widespread adoption after 30 years of availability.
| Challenge | Impact |
|---|---|
| Key management | Both sender and recipient must set up and exchange public keys before communicating |
| Usability | Most people cannot configure PGP or S/MIME without technical assistance |
| Recipient burden | If the recipient does not have PGP set up, you cannot send them an encrypted email |
| Mobile support | Limited and inconsistent across email apps |
| Key rotation | Old keys expire or get compromised, breaking access to historical messages |
PGP is technically sound but practically unusable for most people. It requires both parties to participate, which makes it impractical for ad-hoc file sharing.
Instead of attaching files to email, a more secure workflow is:
#).You still use email to send the link, but the email no longer contains the sensitive file. Even if the email is intercepted or the provider reads it, they only see a URL. The decryption key in the URL fragment is never sent to any server.
Do this: encrypt the PDF, set a 24-hour TTL, send the link in the email body. The recipient clicks the link and downloads the decrypted file. After 24 hours, the encrypted data is deleted from the server.
Do this: encrypt the scan, enable single-use download, send the link. The recipient downloads it once. The encrypted data is immediately deleted. No copies remain on any server.
Do this: select all three files. They are automatically compressed into an encrypted ZIP. Send one link. The recipient downloads and decrypts all three files at once.
Email was never designed for secure file sharing. Attachments travel through servers in plaintext, get stored indefinitely, can be forwarded without control and are scanned by providers. These are not bugs — they are fundamental properties of the SMTP protocol.
For sensitive documents, replacing email attachments with encrypted links is a straightforward improvement that eliminates multiple categories of risk. The file never travels in plaintext, expires automatically and cannot be read by any server along the way.
Send files with end-to-end encryption. The server never sees your data. No account required to receive.
Get Started Free