Is it safe to email passwords?

No. Emailing a password creates permanent copies in your sent items, their inbox, both providers' systems and any backups — none of which you can reach later. Encryption in transit protects the journey, not those copies.

This is the rare security question with a genuinely simple answer. What's worth understanding is why, because the reason rules out several of the fixes people reach for first.

What actually goes wrong

The copies outlive the need. A password is useful for about five minutes and stays in the thread for years. Every mailbox involved is a long-term store, indexed and searchable, and a mailbox compromise months later hands over everything ever sent through it. The password you sent a client in March is in the breach in November.

You control roughly none of them. You can delete your copy. You cannot delete the recipient's, their provider's backups, their company's archiving system, or the copy pulled into an e-discovery tool. "I'll delete it after" is a best-effort action on one of several copies.

Forwarding is invisible and normal. The recipient forwards your message to a colleague who actually does the work. Entirely reasonable, completely undetectable to you, and the credential now exists in mailboxes you don't know about.

TLS is not the protection people think it is. Mail servers negotiate TLS, so the message is usually encrypted between hops. That is genuinely useful and entirely beside the point: nobody is intercepting your SMTP traffic. They're reading a mailbox.

There's no record either way. If a client's security reviewer asks how their admin credential was handed over, "we emailed it" is the wrong answer, and "we emailed it, I think, some time in March" is worse.

The fixes that don't work

Splitting it across two channels. Username by email, password by text. It does raise the bar — but both halves still persist permanently, and it takes twice as long, so it survives about two handovers before someone reverts.

Password-protected attachments. The zip is only as strong as its password, which you then have to send — commonly in the same thread, which defeats it entirely. It also adds a file to everyone's downloads folder.

Obfuscating it. "The password is our usual one with 2024 on the end." You have made the credential harder for the recipient and trivial for anyone reading the thread.

Deleting it afterwards. See above. Worth doing, not worth relying on.

PGP. Genuinely solves it, and almost nobody's client can use it. If your recipient already has PGP set up, this isn't a question you were asking.

What to do instead

Send a one-time link. The credential is encrypted, the recipient opens it once, and the copy is destroyed — so the thing that made email unsafe, the permanent copy, doesn't exist. The link itself can travel by email quite safely: once it's been opened it's worthless, and if it's never opened you can revoke it.

Free tools do this well — Onetimesecret and self-hosted PrivateBin among them. If you already pay for 1Password or Bitwarden, their sharing features cover it for colleagues. Any of these is a large improvement over email, and if that's all you need, stop there.

Paid tools like SecretWolf earn their place when the handover is part of the job rather than an occasional errand: links on your own brand and domain, requesting credentials inbound, verifying the recipient before anything reveals, and an audit trail that answers the security reviewer's question. How it's secured covers the mechanics, including where it differs from browser-side zero-knowledge tools — and practices and onboarding teams show what that looks like in practice.

If you've already emailed one

Change it. Not because something has definitely gone wrong, but because working out how worried to be costs more than rotating the credential does. Then send the new one properly, and if anyone needs the old thread cleaned up, do that afterwards rather than instead.

Questions people ask