An ops engineer drops a temporary database password into an email, subject “use this tonight,” sends it to a colleague, and CCs themselves as a backup. Ten minutes later it feels wrong. They open Sent and delete the message. The colleague’s lock screen still shows that line. The work laptop’s Outlook has already synced the same copy. Both sides think they “deleted it.” The plaintext is still sitting in more than one place they can open.
An earlier piece asked if you paste a one-time link into Slack or WeChat, does the preview burn it first: that is “did a card spend the one read before a person clicked.” This piece asks a different question: once the password itself is in the email body, which leftover copies can you still open. If the secret instead travels on a one-time link, the shape is still s.html?id=…#…. Create and read need no account. MyPassGen’s tools open without sign-up. This is not a tour of compose-window buttons. It is a walk through official help pages and what you can see in Sent, the notification shade, and the address bar.
Keep two facts apart
Undo Send is usually a short hold before delivery, not a later pull from the other person’s mailbox. Confidential mode turns off Forward, Copy, Print, and Download in the Gmail UI. Google’s own Important note says screenshots and photos still work. Deleting your Sent copy does not prove the recipient’s Inbox, a phone preview, or mailbox search is empty.
Why deleting Sent does not erase the password
Email is not a one-shot slip that vanishes after Send. RFC 5321 §2.1 states SMTP’s job as transferring mail reliably and efficiently: a client hands a message to a server; that server may be the final delivery point or a relay. A relay stores the message, then hands it to the next hop. Each hop is a transfer of responsibility. Once the password is in the body, it rides the whole RFC 5322 message. It does not flash only in the compose window you just closed.
After delivery, the message usually stays in server folders instead of being wiped from the network. RFC 9051 defines IMAP4rev2 as a way for a client to access and manipulate mail on a server; a remote mailbox is functionally equivalent to a local folder. Phone, webmail, and desktop clients read the same server copy. Deleting Sent in the browser only changes one folder on your account. The recipient’s Inbox, a copy already pulled onto their phone, and any journal or retention policy on a company tenant do not vanish with that click.
So “email it to myself as a backup” and “email a colleague, then delete” both leave plaintext. When you mail yourself, Sent and Inbox are often two doors into the same message; search the subject or those few words and it opens again. When you mail someone else, you at least have sender Sent, recipient Inbox, and the first lines on a lock-screen notification. Clearing one door does not prove the others are empty.
Undo Send and recall undo different steps
Gmail’s Undo Send is documented on the official help page. After Send, the lower left shows “Message sent,” and you can click Undo. The cancellation period is set under Settings to 5, 10, 20, or 30 seconds. Send or unsend Gmail messages does not say you can later pull a delivered copy out of the other mailbox. Google’s own product blog also writes that the default window is five seconds and the maximum is 30. After that window, the password email has left the compose view on the SMTP path. It is delayed delivery, not a later recall.
Outlook’s recall boundary is narrower. Microsoft’s How to recall an email in Outlook says you can recall from new or classic Outlook for Windows, or Outlook on the web, only when both sides use a Microsoft 365 work or school account in the same organization, and the recipient has not opened the message yet. Personal accounts — Gmail, Hotmail, Outlook.com — cannot use message recall. Outlook.com’s own note is blunt: addresses ending in @outlook.com, @hotmail.com, @live.com, or @msn.com leave your mail server once sent. What a personal account can use is an Undo Send delay, also up to 30 seconds.
Even after a recall request goes out, Microsoft lists failure cases: the recipient already read it, they forwarded it by hand, or an Inbox rule changed where it landed. The Message Recall Report can show success, pending, or failed. If the mailbox is temporarily unavailable, the service retries for up to about 24 hours before marking failure. Exchange Online’s cloud-based recall can also pull already-read copies unless a tenant admin turns that off — Microsoft Learn says the Outlook dialog that still says “unread only” is no longer accurate for that cloud path. None of that makes recall a reliable burn. External mailboxes, someone who already opened the notification, and your own Gmail sit outside the promise.
Confidential mode hides buttons, not copies
Gmail confidential mode is often treated as “email with burn-after-reading.” Official help, Send & open confidential emails, lists what it can do: set an expiration, revoke access at any time, turn off Forward, Copy, Print, and Download in the recipient UI, and optionally require an SMS passcode. The Important note at the top is clearer: confidential mode can reduce accidental forwarding, but recipients can still take screenshots or photos; malware on their device may still copy or download the message.
Revoke lives in the sender’s Sent folder: open that confidential message and click Remove access. After expire or revoke, the recipient cannot open the body or attachments. The sender’s Sent copy stays unless you delete it separately. Expiration withdraws the other side’s access link. It does not physically wipe plaintext from Google’s systems, and it does not burn your Sent copy with it. Putting a password in a confidential email still hands the plaintext to a hosted body, then adds UI limits. Google Workspace help is explicit on the transport: Gmail removes the body and attachments from the recipient copy and replaces them with a link; only the subject and that link go out over SMTP.
The SMS passcode is not worldwide. Google lists North America, South America, Europe, Australia, and in Asia only India, Korea, and Japan. Outside those regions you often have to pick “No SMS passcode.” Without that extra step, anyone who can open the mail can read the body. Confidential mode answers “Gmail shows fewer buttons.” It does not answer “only the recipient’s browser ever sees the key.” That is a different design from MyPassGen’s one-time link: the browser encrypts with AES-256-GCM, the key sits after # in the URL, and the server parks ciphertext only. How to check the algorithm and that plaintext was not uploaded is in How to verify that browser encryption did not upload plaintext.
Where Sent, sync, and lock-screen previews differ
Once the same password is in the message, four doors usually stay open. First is the sender’s Sent folder. Webmail, Outlook, and Apple Mail that sync Sent to the server will show the original on any other signed-in computer if you search the subject. Dismissing a phone notification does not clear that copy.
Second is the recipient’s Inbox, plus any offline copy already downloaded. IMAP clients often cache the whole message on a laptop. If they Forward or Reply and quote the original, the password is copied into a new thread. Third is the lock screen and notification shade. Many mail apps draw the subject and the first lines of the body on the banner. If the password is the first sentence, or the subject is “password is xxx,” the preview holds the plaintext up to anyone who can see the screen. On iPhone, Apple documents Show Previews under Settings → Notifications: Always shows contents on the Lock Screen without unlocking. When Unlocked and Never hide that snippet. Fourth is search: Gmail and Outlook can find old mail by body keyword. If the password itself hits, it never left the mailbox index.
A company mailbox may add another hop. An earlier piece covered Microsoft Defender Safe Links rewriting and scanning URLs — that is a link-preview and gateway problem. When the password is in the body, the scanner is not looking at s.html?id=…. It is looking at plaintext. Whether a gateway, journal rule, or eDiscovery keeps another copy depends on the tenant. You cannot read that from a product slogan. What you can open on the spot is still Sent, Inbox, the notification preview, and search.
Mailing it to yourself is not the same as holding it only in your hand
“Send it to my inbox, then forward to a colleague” creates one Sent copy and one Inbox copy. Phone mail, web search, and a browser that offers to save the password can add another layer. Who else can read the clipboard after Copy is in Who else can read the clipboard after you copy a password. Phone numbers and ID numbers in a ticket body belong under Which fields to redact before sending tickets and chat logs. A password is not just another field in the same email.
What leftover a password in email still has
Use the same test password and the same subject on a normal send, an Undo Send cancel inside the window, an Outlook recall, and Gmail confidential mode. The pages you can open are not the same. The table is written by “places you can click,” not by marketing names.
| What you did | Sender Sent | Typical recipient result |
|---|---|---|
| Normal send, then delete your Sent copy | Your side may be empty; search first | Inbox, notification preview, and downloaded copies can still hold the original |
| Gmail Undo Send (Undo inside 5–30 seconds) | Usually back in compose; no Sent copy | Cancel inside the window and they never get it; after timeout it matches a normal send |
| Outlook recall (same org; help page still says unread) | Original plus a recall report still sit there | May be pulled; already read, external, or personal mail often fail |
| Gmail confidential mode, then expire or Remove access | Sent still has a copy until you delete it | Body will not open; screenshots and photos are outside the button limits |
| Body sends only the one-time id; key goes by phone | Mail never holds the key after # |
Preview and search cannot assemble a working credential; both halves are required to decrypt |
Do not mix the fifth row with the first four. Pasting a full s.html?id=…#… into mail still leaves one credential in the thread — the server cannot see the key, but a person can copy the whole string. Preview bots usually never receive the slice after #. Split the id and the key, and mailbox search cannot find a complete working link. The full URL is still a credential. Do not save it as a bookmark.
Check it on the spot
These steps do not depend on any brand promise. Use a test password that will never log into a real account, for example orange-lake-7, with subject “test — do not open production.” Do not practice with a live master password, a production key, or a real one-time link.
- From a personal test mailbox, send yourself one message whose body is only the test password. Open Sent at once and confirm the original is there. Open the phone mail notification and see whether the lock screen or shade shows the test password or the subject. Do not use a production work mailbox for this step.
- In webmail, search
orange-lake-7. A hit means the body was indexed. Note every door that still opens: Sent, Inbox, conversation view. Delete Sent, then search again: does Inbox or All Mail still hit? - Open Gmail settings and read Undo Send. Note whether the period is 5, 10, 20, or 30 seconds. Send the same test mail and click Undo inside the window. Sent and Inbox should both stay empty of that copy. Send another, wait out the window, and confirm both sides show the original. This only proves the delay boundary. It does not prove a later recall.
- If you have two Microsoft 365 test accounts in the same organization, send to an unread colleague test box, then follow the official recall steps. Open the Message Recall Report and read success or failure. A control message to Gmail or Outlook.com should not offer a usable recall. Personal accounts, per Microsoft, use the Undo Send delay instead.
- If your Gmail shows confidential mode, send a confidential test password to a second test box you own. Check: are Forward and Copy unavailable; does a system screenshot still capture the test password; after Remove access in Sent, can the recipient still open the body; does sender Sent still show the original?
- Create a MyPassGen one-time link with the same test sentence, expiry 24 hours, reads left at 1. In the email, paste only the part before the hash,
s.html?id=…. Speak the key on a call or in person. Opens without an account. With only the id, the recipient should see an incomplete link; both halves are required to decrypt. After reading, overwrite the clipboard. Do not store an address that still has#in Sent.
On a company mailbox, add half a step: count how many times the test mail was forwarded in the conversation, and whether the phone preview still shows the test password. MyPassGen will not tell you whether a given gateway stored another copy. Trust the windows you just opened.
If mail is the only channel, split the credential
For a one-to-one handoff the other person can open now, do not put the password in the body. Generate it on this device, then wrap it in a one-time link. MyPassGen’s password generator uses a random mode of 6–128 characters, default 16, and warns below 8. It opens without an account. The result is not uploaded as business data. On create, the browser encrypts with AES-256-GCM. A single note caps at 32 KB. Reads default to 1 and cap at 10. Expiry can be 1 hour, 24 hours, 7 days, or count-only with no TTL. The server parks ciphertext only. Why the key belongs after # is in When you send a password once, why the decryption key belongs after # in the URL.
When mail is required, split the channel. The email carries only the id and the sentence “key by phone.” Do not paste a full link into a mailbox that syncs, indexes, and draws notification previews. A call, an in-person handoff, or a different messenger account carries only the slice after #. Neither half decrypts alone. That is a usage pattern, not a product default. The create page still emits one full link, which is convenient for a one-to-one send. For a large list or a channel that draws preview cards, run a test link first and see whether the preview counts a read before you send a live secret.
A certificate pack or export larger than 32 KB does not belong on a one-time text link. Use the file encryption box: streaming AES-256-GCM in the browser, one file up to 5 GB, output .lock / .enc, passphrase sent separately. Drive or a mail attachment should hold ciphertext only. See Before you drop a file in the cloud, who can read the plaintext. An unencrypted spreadsheet attached to mail is the same class of problem as a password in the body: the attachment rides Sent and every forward.
After you have checked “does search still hit after I delete Sent” and “does the notification preview show the test password,” you can answer this article’s question: once a password is in the email body, Sent, Inbox, a forward chain, and a phone preview can all show the plaintext again. Undo Send covers tens of seconds. Recall covers same-org mail, and even then it can fail. Confidential mode covers buttons, not screenshots. Mail is a fine channel for an id. It is a poor channel for the password itself.
FAQ
If I delete Sent, can the other person still see it?
Emptying your folder does not empty theirs. IMAP keeps the message on the server and on devices that already synced. Search the test password: Inbox, All Mail, and the phone notification. If they already read or forwarded it, recall does not apply. Do not treat “I deleted Sent” as a password rotation.
Can Gmail confidential mode stand in for a one-time link?
No. Google writes that it can reduce accidental forwards, but screenshots and photos still work, and malware may still copy. After expire or Remove access, sender Sent usually still holds a copy. The body is hosted by the service; plaintext does not appear only in the recipient’s browser. To check “did the server see anything besides ciphertext,” use a one-time link and Network. Do not substitute confidential mode.
How is a full one-time URL in mail better than the password in the body?
Server logs and HTML-only previews usually cannot see the key after #, and the read page waits for script to fetch ciphertext before it counts. The thread, Sent, and a notification preview can still hold the whole URL. Whoever copies it can open it before it burns. Safer: mail only the id; send the key on another channel.
Do create and read need an account? If I send the wrong channel, can support recover it?
No sign-up. Create and read are public to a visitor. After ciphertext burns by count or expiry, there is no server-side plaintext backup and no support inbox that can recover it. Generate a new password and a new link. Do not keep refreshing the same URL to see if it comes back.