Send a password by email today, and you've created a record that will outlive your career. The email exists in your sent folder, the recipient's inbox, both providers' SMTP server logs, every backup of both providers' systems, the recipient's phone-cached preview, the recipient's IMAP client on three devices, the recipient's enterprise compliance archive, and possibly the spam-filter vendor's training data.

Every one of those copies is a future breach surface. None of them are under your control. And unlike Slack, where deletion at least changes the visible surface, email deletion is functionally a no-op — the message has already replicated to systems you can't even enumerate.

This article is the case I make when developers ask why email is the worst way to send passwords. We'll walk through what actually happens to a password sent over email, why "encrypted in transit" doesn't help, and what to use instead.

The fifteen places your password email lives

When you send a password via email, here's the actual replication graph:

Your side:

Your sent folder, indefinitely
Your email provider's primary storage
Your email provider's secondary/backup storage
Your email provider's compliance archive (Gmail, Outlook, Workspace all retain for legal hold)
Any local copy in your desktop email client (Outlook, Mail.app, Thunderbird)
Any local copy on your phone's email client
Any IMAP-cached copy on your tablet

The transit: 8. Your outbound SMTP server logs 9. Every relay server between you and the recipient (often 2-5 hops) 10. The recipient's inbound SMTP server logs

Recipient side: 11. The recipient's primary inbox storage 12. The recipient's spam filter / security gateway (often a third-party SaaS like Proofpoint or Mimecast) 13. The recipient's IMAP-cached copy on every device they use 14. The recipient's enterprise compliance archive (if applicable) 15. The recipient's phone notification cache and lock-screen preview

That's fifteen distinct locations, only one of which (#1) is under your direct control. None of these copies disappear when you "delete" the email. Some persist for the lifetime of the underlying systems.

"But it's encrypted in transit"

TLS between SMTP servers is now near-universal — STARTTLS, opportunistic TLS, sometimes enforced TLS via MTA-STS. But TLS only protects the message during transit. Once received, the message is decrypted and stored in plaintext by the recipient's mail server. The same is true for your sent folder.

A password "encrypted in transit" means it can't be read by someone tapping the wire between your SMTP server and the recipient's. It doesn't mean Google can't read it. Google reads it (or could, if they wanted to, or if a court ordered them to). Microsoft reads it. Your enterprise archiver reads it. Your phone's mail app reads it.

Encryption in transit is the bare minimum, not a security model.

What about S/MIME or PGP?

S/MIME and PGP do provide end-to-end email encryption. They also have approximately zero adoption outside specific enterprise contexts. The reasons are well-documented:

Key distribution is hard. You need the recipient's public key. They probably don't have one.
The UX is hostile. Even with Mailvelope or other extensions, normal users won't get past the first error message.
Quotes don't include the encryption. Forward an encrypted email and you decrypt it. The forward is plaintext.
Mobile support is patchy. Encrypted emails on your phone are usually unreadable or readable only via a separate app.

For internal teams that have invested in S/MIME, it works. For sending a password to a contractor or a client who's never used PGP in their life, it doesn't.

The deletion myth

"I'll just delete it after they confirm receipt" doesn't work in email any better than in Slack. Specific failure modes:

Deletion only affects the original copy. The recipient still has theirs. Both providers still have theirs. Backups still have theirs.
The IMAP cache lingers. If the recipient's mail client cached the message before they "deleted" it, the cache may persist for weeks.
Search indexes outlive the message. Both Gmail and Exchange index messages aggressively. Even after the message is gone, the indexed terms (and snippets) often persist.
Forwarding rules. If the recipient has any auto-forwarding (to a personal address, to a security archiver, to an integration), the message has already replicated by the time they delete.

The cost of "delete after read" in email is the false sense of security. You believe the message is gone. It isn't.

What "good enough" requires

The channel for sending a password needs to satisfy:

End-to-end encrypted — the relay service can't read the payload.
One-time access — the message is readable once, then provably destroyed.
Hard expiry — even unread, the message expires.
No persistent copies — the channel doesn't replicate the message into archives, search indexes, or backups.
No friction for recipient — no install, no account, no instructions.

Email satisfies zero of these. Slack satisfies arguably one (no install on either side, but everything else fails). A self-destructing share link satisfies all five.

A real-world case study

A friend's marketing agency sent a client's WordPress admin password by email in 2019. The email sat in the agency's sent folder, the client's inbox, and various backups. In 2023, the client's email account was breached via a stolen password (unrelated to the WordPress credential). The attacker searched the inbox for "password," found the agency's email from four years earlier, and used it to take over the client's WordPress site.

The WordPress password had never been rotated because the client assumed "we changed our email password, we're safe." The original credential, sitting in a four-year-old email, was the entry point.

This pattern is depressingly common. The email channel creates a multi-year exposure window for credentials that should have been ephemeral.

What to use instead

Three options, ordered by friction:

1. A self-destructing share link. End-to-end encrypted, one-time read, no account required, works in any browser. The lowest friction and best fit for one-off transfers.

2. A team password manager. 1Password's "share link" feature, Bitwarden Send, Vaultwarden's share. Higher friction (the recipient may need an account on the sender's side), but works well for ongoing team relationships.

3. A secret manager-issued temporary credential. For service-level access — Vault, AWS Secrets Manager, Doppler — you can often skip the human transfer entirely and grant the recipient a time-bound credential they fetch themselves.

For the moment a human needs to hand a password to another human, option 1 is the right tool.

Where SnapSend fits in

SnapSend is option 1. End-to-end encrypted with the key in the URL fragment (so the SnapSend backend can't decrypt the password under any circumstance). One-time read with hard expiry. No account required for either sender or recipient. The Credential Card mode is the right shape for "service + username + password + URL" handoffs.

When you need to send a password, the workflow takes about 30 seconds:

Open snapsend.site
Paste the password
Set expiry to 1 hour
Copy the link, paste it in your email instead of the password

The email now contains a one-time-readable link. The password is never in the email's body, which means it's not in the recipient's inbox, the SMTP server logs, the spam filter, or any backup. The recipient clicks the link, the password is decrypted in their browser, the link is incinerated.

Stop emailing passwords

Every password you've sent by email in the last five years is still out there somewhere. You can't take them back. You can stop adding to the pile.

Try SnapSend free at snapsend.site — no account needed.