One checkable line first: the padlock in a mail client only means this hop used TLS. It does not mean the body stays ciphertext after it leaves that server. After you send, search Sent and the recipient Inbox for a canary password. A hit means that message is still stored as readable text. Do not run the check with a live production key.
Hitting Send is not “a quick note.” It hands plaintext to a mail store
Work email is easy to treat like a local chat box: the words are still on your screen, so the other person is only “looking.” After Send, that paragraph has left this tab. It is now a message the provider has to deliver, index, and keep. Database passwords, cloud access keys, GitHub personal access tokens, shared Wi-Fi secrets, and account recovery codes sit in the same bucket the OWASP Logging Cheat Sheet usually keeps out of shared plaintext records. Sent, Inbox, Drafts, and the IMAP copy on a phone often become an informal vault: easy to search, looser than a password manager, and kept longer.
HTTPS or a banner that says “this message is encrypted” only covers eavesdropping on the wire. It does not decide how long the other mailbox stores the body, whether an admin can search it, or whether a backup disk still holds a copy. An earlier note covered model sessions: paste a key into ChatGPT and the source can enter history and a possible training copy. Emailing a secret is the same class of exposure. The recipient just changed from “a model vendor” to “at least two mailbox stores, plus every relay in between.” What you have to handle before Send is not “is this mail client clever.” It is “does this paragraph contain a secret that should not become searchable mail.”
This note uses Gmail, Exchange Online, Google Vault, and Microsoft Purview because the retention numbers and admin search scopes are written in public help. Self-hosted Postfix, Microsoft 365 journal archives, and other hosted mail are still store-and-forward. When you change products, walk that vendor’s delete and archive pages again. Do not copy the 30-day Trash window or the 14-day Recoverable Items default onto another service.
The padlock and STARTTLS cover one hop, not end to end
A lock icon in the browser bar or the mail client is often read as “encrypted all the way to the other person.” SMTP transport encryption does not work that way. RFC 3207 section 6 is blunt: SMTP is not an end-to-end mechanism. A decision by one SMTP client and server to add TLS does not protect the message from the sender’s mail user agent to the recipient. A message can pass through two or more SMTP servers. TLS on one pair does not make the whole delivery path private.
That produces a scene that looks contradictory. Your client-to-gateway hop can be TLS. The gateway-to-MX hop can be STARTTLS. At the end of each hop, the relay still has to open the message to read the envelope, run spam filters, and hand it to the next hop. On those disks the body is readable by default. True “nobody along the path can read this” needs content encryption such as S/MIME or OpenPGP, not a transport padlock. A password typed into a work compose window almost never gets that layer.
IMAP and phone clients copy the message again. Mail is not a pipe you glance at in a web tab. It is object storage: Inbox, Sent, Drafts, and Trash are objects. Another signed-in laptop, a company phone, and a desktop client’s offline cache can all read the same plaintext. Transport encryption stops a bystander on the wire. It does not stop copies that already landed in a store.
Sent and Inbox: two readable copies the moment you email a password
After Send, count copies before you talk about Delete. The first is yours: Gmail Sent, Outlook Sent Items, or Sent on most IMAP accounts. That is not an undo buffer in the browser. It is a stored object. You can search that string two months later. An admin who can search the mailbox can too. The second is theirs: Inbox, plus whatever All Mail or Archive tag they used to file it. Both copies are the body, not “subject only.”
Cc and Bcc add more. Cc to a project list leaves a copy in each Inbox. Bcc only hides addresses from other recipients. It does not shrink storage. Auto-forward rules, journaling, and “also send this to Slack or Teams” gateways can land another copy outside the mail product. Those copies do not share one Delete button. Emptying your Sent folder does not touch their Inbox, and it does not touch a copy a gateway already wrote.
The search box is the evidence. Gmail, Outlook, and most webmail index the body. Drop a canary password into search. A hit means anyone with that mailbox can read it. That is the same class of leftover as a cloud instant-upload hash or clipboard history: the product keeps plaintext because search is useful, not because it wants to help you forget a secret.
| Where | What usually remains | Who can still read it |
|---|---|---|
| Sender Sent / Sent Items | Full body and attachments | The sender; anyone with that mailbox |
| Recipient Inbox / All Mail | The same full body | The recipient; their synced devices |
| Relay SMTP servers | A readable message during delivery | Operators and filters on that hop |
| Trash / Recoverable Items | A body you can still restore | The user; restore UI before the clock ends |
| Enterprise archive / Vault / eDiscovery | A searchable copy kept by policy | Archive or compliance admins |
Both sides hit Delete. The clock usually has not finished
“I deleted it and they deleted it” is often heard as the secret coming back. Vendor delete paths are longer. Gmail’s delete help says a deleted message goes to Trash. For up to about 30 days you can still find it there, move it back to Inbox, or choose to delete it forever. After 30 days it is permanently deleted from the account and cannot be recovered from Trash. Archive is not delete: Archive only takes the message out of Inbox. Search in All Mail can still hit it.
Google Workspace adds an admin window after that user clock. Workspace restore help says that after the 30-day Trash period, admins have about 25 more days to restore messages. That extra window starts 30 days after the delete, not on the send date. When it ends, the help says messages are permanently deleted from the Workspace account and cannot be restored by an admin or by Google. Vault retention and holds sit outside that restore button. They are a different copy.
Exchange Online has a hidden folder after “gone.” Microsoft’s deleted-item retention page says that after you delete from Deleted Items, empty Deleted Items, or press Shift+Delete, the object moves to Recoverable Items → Deletions. The default keep is 14 days. An admin can raise it to 30. Users can still Recover deleted items in Outlook. If the mailbox is on Litigation Hold, that retention clock is ignored and deletes are not purged on the 14-day schedule.
Undo Send does not reclaim a secret that already left. Gmail Undo Send only offers a 5, 10, 20, or 30 second cancel window. That delays the real delivery. It does not pull the body back off the other server. After the window, the message is ordinary Sent mail. Outlook recall can work only in some Exchange organizations, and only if the other person has not read it. It is not a general take-back button.
Enterprise archives and admin search are extra copies you cannot delete
A personal Trash clock and a company compliance store are not the same switch. Google Workspace Vault search for Gmail is built to find messages by keyword in the body and attachments (Google writes about the first ~1 MB of text and attachments). Admins can preview, print, and download attachments. Drafts and autosaved drafts are in scope. A default Vault retention rule can keep mail searchable after users empty Trash. That is the product job: find what an employee already deleted.
Microsoft Purview eDiscovery treats mailboxes the same way. Finding content in mailboxes says a keyword search covers the subject, the body, and many participant properties. Indexed message properties include sent and received dates, sender and recipient, attachment filenames, and text in the message body. The design goal is “we can still find this after the user clicked Delete,” not “honor the sender’s second thoughts.”
So “only the two of us know” usually fails on a company mailbox. Anyone who can open Vault, run eDiscovery, or export a mailbox can read that password as part of the job. That is not a claim that a vendor is peeking for fun. It is the permission the help pages describe. A personal Gmail account has no Workspace admin. That does not make Sent plaintext unreadable to whoever sits at an already signed-in computer.
Confidential mode blocks casual forwarding, not archives or screenshots
Gmail confidential mode is often treated as “email burn-after-read.” The official scope is narrower. Gmail’s confidential mode help says you can set an expiry, revoke access later, turn off forward / copy / print / download, and require an SMS code. The same page warns that recipients can still take screenshots or photos, and that a recipient with malware may still copy or download. Workspace copy is also explicit about the implementation: Gmail strips the body and attachments from the recipient’s copy and replaces them with a link to the content. What leaves over SMTP is mainly the subject and that link.
Expiry or a revoke can close the body for the recipient. It does not erase the copy inside the sender’s organization. Vault’s confidential-mode notes say that if the organization enabled confidential mode, Vault can retain, search, and export confidential-mode messages sent by users in the organization after 30 November 2018. Those messages stay available to Vault even when the user set an expiration date or revoked recipient access. Search with label:confidentialmode. Preview hides content by default; the operator can choose to show it. That is not a burn. It is a gate for the recipient and an open door for the compliance inbox.
Workspace admin docs add one more internal copy. To let Vault read confidential-mode mail, Gmail can attach a copy of that content to the recipient’s message when sender and recipient are in the same organization. The help says that copy is only for Vault. Senders and recipients cannot open it from Gmail, and third-party archive tools cannot see it. Deleting every copy still means deleting it from the sender account and every recipient account. Confidential mode is a misfire control. It is not a one-time key channel. The same provider still hosts the body. The subject still rides ordinary SMTP. Screenshots are out of scope on Google’s own page. If the goal is “the server only holds ciphertext, reads burn by count, and the key never enters HTTP,” that is a different split—not the same message marked confidential.
Do not test with a live password, a production API key, or an unredacted connection string. Use a disposable canary such as canary-mail-2026-do-not-reuse. You are checking Sent and search hits, not spreading a real secret again. If a real key already went out in mail, revoke it at the issuer first, then change how you send the next one.
Check it here: a canary in two test mailboxes, then search Sent
A slogan that says “this email is encrypted” cannot prove itself. What you can see in one sitting is four things: whether Sent still has the source, whether a recipient test box has the source, whether Trash or Recoverable Items still hold it after Delete, and whether the padlock was mistaken for “the server cannot read this.” This step only proves which readable copies this test message left. It does not prove a vendor’s archive policy. That side can only be checked against official help. Network cannot stand in for it.
Use two mailboxes you control. Do not use a production address book. Write a canary you can recognize and that will not collide with a real password—for example canary-mail-2026-do-not-reuse. Keep the subject ordinary. Put only the canary in the body. Do not add an ID number or a real hostname. After Send, search the sending account for that string. Sent should hit. Sign in to the recipient test account and search again. Inbox should hit. Two hits means at least two plaintext copies. Delete the sender’s copy into Trash. Open Trash inside the 30-day window. On Gmail it should still be there. That is the proof that Delete is not a take-back.
If you need to check whether a key entered HTTP, do not put the key in mail. Use a burn-after-read link instead. After you create it, the address bar should look like s.html?id= plus a # key. Open DevTools Network. The request line should show the id only. The segment after the hash should not appear. That check proves link shape. It does not prove anything about an email body. Once a body is sent, Network cannot pull storage that already landed.
- From two test mailboxes, send a body that contains only a canary such as
canary-mail-2026-do-not-reuse. Do not use a real key. - Search that string in the sender’s Sent folder and the recipient’s Inbox. Both should hit.
- Delete the sender copy, then open Trash or Recover deleted items and confirm it is still there inside the window.
- When a real key must reach a person, switch to Burn-Link. Use mail only for a notice with no key, or for an already encrypted attachment.
The proof is narrow. In this one run, plaintext landed as a mail body in at least two stores, and Delete did not wipe the sender copy at once. It does not prove an extension never saved a third copy. It does not prove the other company turned on Vault. After you change mail products, run the canary again against that vendor’s delete and archive pages.
Split the notice from the secret with Burn-Link that opens with no account
If you want “the body never becomes mailbox storage” as a repeatable move, start from MakePwd Burn-Link. It opens with no account and no sign-in. Plaintext appears only in the creator’s tab. The browser encrypts with Web Crypto and AES-256-GCM. The outbound fields are ciphertext, expiry, and read count. The server stores only ciphertext and returns an id. The page then appends the key as a fragment: s.html?id={id}#{key}. Per RFC 9110, the target URI does not include the fragment, so the request line should not show the segment after the hash.
Practice only with canaries. Create a disposable phrase, send the full link to a test recipient, and write in the email body only “open the link; do not forward the string that includes the hash.” After they confirm and retrieve it, opening the same id should show a burned state, not another readable body. A blue link can still sit in chat or mail. That is a locator. After ciphertext is deleted by the set count, those characters unlock nothing. Details are in What remains on the server after a one-time secret is read once and Why a URL hash fragment is a fit place for a key—and when that protection fails.
Do not fall back to “passworded ZIP as the attachment” for a whole file that contains keys. File Encryption Box turns the file into .lock / .enc in this tab with AES-256-GCM (one file, at most 5 GB). Ciphertext can travel through mail or a drive. Send the passphrase on another channel. If a login password already went out in mail, revoke it at the issuer first, then use the Password Generator on this device for a new 6–128 character string (default 16; under 8 is flagged as weaker). None of those steps requires a login.
FAQ
If the mail used HTTPS, can only the recipient read the password?
No. RFC 3207 says SMTP is not an end-to-end mechanism: TLS between one pair of servers does not protect the message from the sender’s client to the recipient. Each hop can decrypt, inspect, and hand the message on. Sent, Inbox, and the store on those servers default to a readable body.
If both sides delete the message, is the password gone?
It can still be there. Gmail puts deletes in Trash for about 30 days. Exchange Online keeps permanently deleted items in Recoverable Items for 14 days by default, up to 30. A Workspace admin can have about 25 more days after Trash empties. Litigation Hold ignores that clock. If the org archived mail, an admin can still search and export the body.
After Gmail confidential mode expires, is the body gone from the system?
The recipient cannot open the body after expiry or a revoke. For Vault in the sender’s organization, Google writes that Vault can still retain, search, and export confidential-mode mail sent inside the org, even after the user set an expiry or revoked access. Screenshots and photos are out of scope on the same help page.
If I must get a password to a coworker, how can email still help?
Use mail for a notice with no key, or for a ciphertext attachment. Send the real password once with Burn-Link and keep the key in the URL # fragment. Create and read both open with no account. The server stores only ciphertext. Do not paste the same plaintext into the email body.
Three things to remember before the next email
First: Send writes to disk. Sent, Inbox, synced devices, and relays can each keep a readable body. Editing the current page does not reclaim a copy that already landed. Second: Delete only starts a clock. Gmail Trash is about 30 days. Exchange Recoverable Items default to 14. Workspace admins can have about 25 more days after Trash. Enterprise archives and Vault are another set, and the user cannot delete them. Third: confidential mode and Undo Send stop mistakes. They are not end-to-end. A real key that must arrive goes through Burn-Link. A leaked password is revoked first, then replaced.
If the next question is what remains on the server after a one-time secret is read once, read What remains on the server after a one-time secret is read once. If you need to check whether the key after the hash enters HTTP, read Why a URL hash fragment is a fit place for a key—and when that protection fails. This note only draws a line you can write into a conclusion: after you email a password in the body, what Sent, backups, and mailbox admins can still keep.