Email security
Email is the channel most people reach for when they need to send a password. It is also one of the worst choices for doing so. This article explains exactly why email is dangerous for credential sharing, when you have no option but to use it, and the one approach that makes email a safe delivery channel without actually putting the password in the email.
Email is a persistent, multi-copy system. When you send an email, it is stored on your outbox server, your email provider's infrastructure, the recipient's inbox server, and their mail client — often simultaneously. Many organisations also archive email indefinitely for compliance and legal reasons. A password you sent two years ago is likely sitting in at least four separate storage systems right now.
This persistence is compounded by searchability. Every major email provider — Gmail, Outlook, Apple Mail — indexes message content for search. A password buried in an email thread from two years ago is retrievable in seconds by anyone with access to that inbox.
Then there is the account access problem. Email accounts are the most targeted account type in phishing and credential stuffing attacks, precisely because they unlock everything else — password reset emails, financial accounts, and of course, every credential ever sent to or from that inbox. A compromised email account does not just expose current credentials. It exposes everything in the archive.
For a detailed breakdown of the specific risks, see why you should stop emailing passwords.
Credentials sent by email fall into consistent categories:
In all of these cases, the credential ends up in a long-lived email record that persists far beyond the context in which it was created.
Sharing a password safely over email is not really possible if the password itself is in the email. Any email containing a plaintext credential is unsafe by definition — the credential will persist in the email record indefinitely, be indexed for search, and be exposed if the email account is ever compromised.
Safe credential sharing requires three properties that email cannot provide:
For a full explanation of what secure credential sharing requires, see how to share passwords securely.
The solution is not to avoid email — it is to avoid putting the password in the email. Email becomes a safe delivery channel for a one-time encrypted link, even though it is an unsafe channel for a plaintext credential.
Here is how it works:
The email itself is now safe to archive, forward, or retain indefinitely — there is nothing sensitive in it. The credential is encrypted before it ever touches a server and destroyed the moment it is read.
The one-time link contains two things: an identifier that points to an encrypted blob on the server, and a decryption key in the URL fragment (the part after the #). The decryption key is never transmitted to any server — browsers do not include URL fragments in HTTP requests. This means the server holding the encrypted data cannot decrypt it. Even if your email is intercepted in transit, an attacker cannot extract the password from the link without opening it — which burns the link and alerts the intended recipient that the credential has been compromised.
To understand the zero-knowledge architecture in more detail, see what is a one-time secret link.
When you use a one-time link, the channel you use to deliver it matters less than it does for a plaintext credential. The link is safe to send over email, but also over Slack, Teams, WhatsApp, or SMS. The credential never enters the channel's storage.
If you are choosing between channels for reasons other than security — convenience, the recipient's preferred tool, what they have access to — the choice of channel is largely irrelevant once you are using a one-time link. Pick the most convenient one.
For context on sharing credentials across different platforms and tools, see:
Since the email body will not contain the credential, include a clear description of what the link contains — for example, “I've shared the staging database credentials in the secure link below. It will only work once, so make sure you're ready to copy the details before clicking.” This prevents the recipient from opening the link prematurely or being confused by what it is.
If you want to give the recipient context about which account or system the credentials belong to, include that in the email body. Keep the actual secret in the link. Separating the context (which system) from the credential (the actual password) means your email archive contains only non-sensitive context, not the credential itself.
If the credential you are sharing is a temporary one created specifically for the handoff, rotate it or revoke it once the recipient has confirmed access. This limits the exposure window and ensures the credential does not persist in use indefinitely.
CYPH3RDROP links expire after 7 days if not opened. If the email is not acted on in time, the link will be dead and the recipient will see an expiry message. Simply generate a new link and resend. The expired link contains nothing sensitive.
If someone else reads the email and opens the link first, the intended recipient will find the link is already dead — and they will know immediately that something went wrong. This is actually one of the security advantages of a one-time link: a burned link is a signal that the credential has been accessed by someone other than expected.
Transport Layer Security (TLS) encrypts email in transit between mail servers — it is not end-to-end encryption and it does not address storage. S/MIME and PGP provide genuine end-to-end encryption for email, but require both parties to have configured and exchanged keys — a significant setup barrier in most professional contexts. A one-time link requires no setup on either side and works with any email client.
For credentials shared repeatedly between permanent team members, a password manager with sharing features (1Password Teams, Bitwarden) is the right tool. For one-off handoffs — especially with external parties who do not share your tooling — a one-time link is simpler, requires no shared software, and leaves no persistent record. See also: how to share credentials with clients.
Yes. If you need to send multiple credentials to the same recipient, either include all of them in a single link (the form accepts any text — you can paste a list of credentials separated by labels) or generate a separate link for each credential. Each link works exactly once and is independently destroyed when opened.
Never put a password in the body of an email. Email is a permanent, searchable, multi-copy system — a credential sent by email persists indefinitely. Instead, generate a one-time encrypted link and email the link. The email archive contains only a URL. The credential is encrypted before it leaves your device, stored only as ciphertext, and destroyed the moment it is read. Email becomes a safe delivery channel without the credential ever entering it.
Try it now
No account required. Paste a password, get a one-time link, email the link. Done.
Create a secret link →