Is It Safe to Email Passwords?
Email is not safe for sending passwords because messages travel across intermediate mail servers, remain stored unencrypted in sent and received inboxes, and can be retrieved years later with a simple search. Transport-layer encryption (STARTTLS) only protects data while it is in transit, leaving stored mailbox contents completely accessible. Sensitive credentials should always be shared using zero-knowledge, self-destructing links, with the identifier sent out-of-band.
- Email messages are permanently stored and indexed in sent folders, inboxes, and cloud server archives.
- STARTTLS encrypts mail only between supporting servers in transit, not within stored mailboxes.
- An attacker who breaches an email account can instantly query for 'password' to find past credentials.
- Gmail Confidential Mode restricts message forwarding, but it is not end-to-end encrypted.
- Secret Note encrypts text in your browser with AES-GCM-256 and destroys the note on first read.
The Architectural Flaws of Email for Secret Sharing
Electronic mail was conceived decades ago on trusting, open networks using a store-and-forward routing model. When you dispatch an email containing sensitive credentials, the message does not travel straight from your computer to the recipient's screen. Instead, it hops across numerous independent entities: outbound mail transfer agents (MTAs), domain name lookup servers, corporate spam filters, legal compliance proxies, and destination mail spoolers.
While modern mail exchanges attempt to negotiate TLS encryption via RFC 3207 (STARTTLS), this mechanism is opportunistic. If an intermediate server does not support TLS or an active network adversary initiates a downgrade attack, the email message falls back to transmitting in clear text. More importantly, transport security ceases the millisecond the email reaches the recipient's mail server. From that point forward, the plaintext credential is saved directly into IMAP or Exchange database stores.
Inbox Indexing, Backups, and Forwarding Chains
A password sent over email never exists as an isolated artifact. The moment 'Send' is clicked, identical copies are duplicated into at least four persistent environments: your Sent Items folder, your company's cloud email backups, the recipient's Inbox, and the local disk cache of desktop clients like Microsoft Outlook or Apple Mail.
This persistent footprint creates significant operational liabilities:
1. Instant Harvest via Mailbox Searches: When a user's account is compromised through phishing or credential stuffing, the attacker's first move is searching the mailbox for keywords like password, credentials, API key, VPN, or admin. Temporary passwords shared months or years earlier remain indexed and waiting to be harvested.
2. Forwarding and Reply-All Chains: Email threads are routinely forwarded to project contractors, colleagues, or new employees. A forgotten password buried in the footer of a long message chain quickly spreads beyond its intended audience.
3. Shared Departmental Inboxes: When credentials are sent to shared mailboxes such as sales@, support@, or billing@, every team member with access sees the secret. Auditing who viewed or duplicated the password becomes impossible.
Why Gmail Confidential Mode Is Not End-to-End Encryption
Many corporate teams rely on Google's 'Gmail Confidential Mode' to distribute sensitive data. As of October 2026, this feature allows senders to set an expiration timer and restricts recipients from forwarding, copying, printing, or downloading the message body. While useful for general business hygiene, Confidential Mode is fundamentally not end-to-end encryption.
Confidential messages remain hosted directly on Google's servers. The restrictions are software controls enforced by web interfaces and mobile apps, not mathematical zero-knowledge protections. Google's automated systems maintain complete visibility into the clear text of the message. If the recipient uses an external mail client, they must click an external link back to Google's infrastructure and request an SMS verification code. This model relies entirely on institutional trust in Google rather than client-side cryptographic guarantees.
The Out-of-Band Delivery Pattern for Passwords
To communicate credentials safely when email is your primary channel, decouple the secret from the email body using Secret Note. When you input a password on not.saklama.com, the text is encrypted client-side inside your browser using the native WebCrypto API (AES-GCM-256). The decryption key is embedded strictly in the URL fragment—the portion following the hash sign (#).
Pursuant to RFC 3986 section 3.5, internet browsers never transmit fragment data across the wire in HTTP requests. saklama.com servers store only unintelligible ciphertext, and mail servers see only a standard URL string without the key. When the recipient opens the link and clicks View note, their browser retrieves the ciphertext, decrypts it locally, and the server purges the record permanently. The email thread retains only a defunct, unreadable URL.
Always pair this flow with the out-of-band principle: paste the one-time link in your email, but deliver the associated username, server address, or optional extra passphrase over a completely separate medium (such as an SMS message, Signal chat, or phone call). Even if the email archive is breached, an attacker holding an expired link cannot determine which system it belonged to or unlock the payload.
Post-Delivery Credential Hygiene and Limits
Cryptographic tools must be paired with strict post-delivery hygiene. Any password transmitted over digital channels must be treated as inherently transitional. The recipient should log into the target platform immediately upon receipt and reset the password to a permanent, strong passphrase stored in an audited password manager like Bitwarden.
It is equally important to acknowledge technical limits. Any web application delivers its executable code from the server on visit; not.saklama.com respects this trust by serving unminified JavaScript and running zero third-party analytics or advertising scripts. However, endpoint malware, screen recorders, or local spyware on either device bypasses browser-level security. Minimizing the lifetime of secrets remains your strongest practical defense.
- 1. Encrypt the password in your browser: Navigate to not.saklama.com and input your password. The text is encrypted locally using AES-GCM-256 before transmission; clear text never touches the server.
- 2. Configure single-read self-destruction: Select 'delete after reading' so the server-side ciphertext is permanently deleted immediately upon the recipient viewing it.
- 3. Set an optional secondary passphrase: Add an extra password derived with PBKDF2-SHA256 (200,000 iterations). If typed incorrectly, the note is rejected in the browser without burning the secret.
- 4. Send the encrypted link via email: Paste the generated one-time link into your email message. Do not include the associated username, account handle, or server hostname in the email body.
- 5. Send the username and passphrase out-of-band: Deliver the account identifier and any extra passphrase via a secondary channel, such as an SMS, messaging app, or direct telephone call.
- 6. Rotate the password immediately after login: Have the recipient access the target account and change the temporary password to a permanent credential saved in a password manager.
| Feature | Standard Plain Email | Gmail Confidential Mode | Secret Note (saklama.com) |
|---|---|---|---|
| End-to-End Encryption | None (TLS transit only) | None (Server-side controls) | Yes (Client-side AES-GCM-256) |
| Permanent Destruction on Read | No (Remains in sent/inbox) | Partial (Timer expires, stays on server) | Yes (Permanently purged upon view) |
| Mailbox Search Vulnerability | High (Searchable by keyword) | Moderate (Metadata remains visible) | Zero (Link becomes completely dead) |
| Decryption Key Location | Clear text inside email | Managed on Google servers | In URL fragment (#), never sent to server |
| Account Requirement | Yes (Email address) | Sender requires Google account | None (Free and accountless) |
Frequently Asked Questions
Why is emailing passwords considered a security vulnerability?
Emails pass across multiple intermediate mail servers and stay permanently stored in plaintext format in sent folders, inboxes, and cloud backups. An account compromise exposes all historical credentials.
Doesn't TLS protect email passwords from being read?
TLS only protects data across the network connection between mail servers. Once delivered, messages are decrypted and stored in plaintext in mailbox databases without encryption at rest.
Is Gmail Confidential Mode safe enough for sharing server passwords?
No. Gmail Confidential Mode does not use end-to-end encryption. The plaintext is accessible to Google's infrastructure and only restricts copying or forwarding within supported client interfaces.
What happens if someone clicks an old Secret Note link in an email archive?
Because the note self-destructs upon the first view, clicking the link in an old email returns a tombstone page stating that the note has already been read and permanently deleted.
What should a recipient do immediately after receiving a password via Secret Note?
The recipient should treat the credential as temporary, log into the target account, and immediately change the password to a permanent credential stored in a dedicated password manager.