Email is one of the most common ways people exchange information, which is exactly why passwords often end up there. A user asks for access, an administrator creates a temporary password, and the fastest response seems to be pasting the password into an email. The problem is that email is designed to preserve messages, not to make secrets disappear.
Email creates multiple long-lived copies
A message can exist in the sender's mailbox, the recipient's mailbox, mobile devices, desktop clients, server-side archives, backups, security gateways, and notification previews. Forwarding can create additional copies. Even if the sender later deletes the original message, there is usually no reliable way to confirm that every copy has been removed.
Transport encryption does not solve retention
Modern mail systems normally protect connections using encryption in transit. That protection is important, but it addresses a different problem. It helps prevent interception while the message moves between systems. It does not automatically remove the password after the recipient reads it.
For a reusable password, the main risk may be the months or years during which the message remains searchable. Anyone who later gains access to the mailbox may discover old credentials that are still valid.
Notifications can expose sensitive content
Email content may appear in lock-screen notifications, desktop pop-ups, smart watches, or message previews. A password that is safe inside a protected mailbox can still become visible on a nearby screen. The same issue applies to recovery codes, API keys, PINs, and private configuration values.
Separate the secret from the email
A safer pattern is to use the email only to deliver a temporary link. The sensitive value is stored separately and is revealed when the recipient opens that link. If the service removes the value after the first successful retrieval, the email can remain in the mailbox without retaining the reusable secret itself.
For higher-risk access, an additional passphrase can be communicated through another trusted channel. This reduces the chance that access to one mailbox is enough to reveal the secret.
Use temporary credentials whenever possible
Even with a safer delivery method, a temporary password is preferable to a permanent shared credential. Require a password change at first sign-in, issue a short-lived token, or create limited access that expires automatically. The shorter the useful lifetime of the credential, the smaller the impact of accidental disclosure.
What to do if a password was already emailed
Do not assume that deleting the message is enough. If the password is still valid, rotate it. For an API key or token, revoke it and issue a replacement. If the credential provided privileged access, review relevant sign-in or activity logs according to your organization's incident-response process.
Keep the audit trail, not the secret
Email can still be useful for documenting that access was requested and approved. The message can contain the purpose, the recipient, the expiration time, and instructions for using the credential without including the credential itself. This preserves the business record while reducing the amount of sensitive material stored in mailboxes.