Why You Shouldn't Send Passwords by Email
It delivers. It persists. That's the problem.
Email never forgets
You send a password to a colleague. They read it. The email sits in their inbox. It's in your Sent folder. It's on the mail server. It's in the nightly backup. It's in the compliance archive.
If either of you uses Gmail, deleted messages are recoverable for 30 days. Corporate mail servers keep everything indefinitely. The password you sent today is findable next year by anyone who can search the mailbox.
Forwarding and delegation
Email gets forwarded. People set up delegation so assistants can read their mail. Shared mailboxes exist. Auto-forwarding rules copy messages to personal accounts.
When you send a password by email, you don't control how many copies end up where. Each copy is a copy of the password.
Email isn't encrypted at rest by default
SMTP encrypts in transit (usually). But most mail servers store messages in plain text or with provider-managed encryption. The provider has the keys. An admin, an attacker, or a legal request can access the contents.
S/MIME and PGP exist, but adoption is low and both sides need to be set up. For a one-time password handoff, that setup cost doesn't make sense.
Compliance and legal discovery
Regulated industries (healthcare, finance, legal) retain email for years. A password in an email is a password in the legal discovery archive.
If the mailbox is part of an eDiscovery hold, nothing gets deleted, including that password from 2023 that nobody changed.
What to do instead
Use a tool with self-destructing links. Paste the password, set a view limit, send the link. The recipient opens the link, copies the password, and the encrypted data is deleted. What's left in the email is a dead link that points to nothing.
The password existed only for the moment someone needed it. Share passwords securely or share API keys with encrypted one-time links.
How Secret.Broker handles this
Your browser encrypts the password with XChaCha20-Poly1305 before anything goes to the server. The decryption key stays in the URL fragment. The server stores ciphertext it can't read. After the view limit or expiry, the ciphertext is hard-deleted.
The email channel carries only the link, not the secret. The protocol page documents the full encryption stack.
Slack has the same problem
Everything said about email applies to Slack, Teams, Discord, and any messaging tool that stores history indefinitely. Messages persist in exports, search indexes, and compliance archives. The credential is accessible to anyone who can search the workspace.