Email is fine for sending a link. It is a poor place to leave passwords, account numbers, private notes, or credentials in the message body forever.
Keep sensitive text out of the email. Put it in an encrypted, expiring link, email the link, and send an optional passphrase through a different channel. Use textdrop.sh to make the link in your browser, then share the link instead of the sensitive text.
Make an encrypted paste, then send the URL in a neutral email. Add a passphrase for higher-risk information.
Most email services use transport encryption while a message moves between servers, but that does not stop the sender's and recipient's mailboxes, backups, forwarding rules, or a compromised account from exposing the contents later.
A secure link limits the sensitive material's lifespan. The email carries a pointer rather than the data itself; a short expiry and a separately shared passphrase reduce the impact if the message is forwarded or an inbox is compromised.
Yes, but do not put the sensitive content in the email itself. Send an encrypted, expiring link or use an approved encrypted-email or secure-portal workflow required by your organization.
No. Confidential mode can limit actions and set expiry, but it is not end-to-end encryption. Choose a method appropriate to the information and your organization's requirements.
Use a neutral subject such as 'Requested information' and avoid account numbers, health details, credentials, or other sensitive context that could remain visible in inboxes and notifications.
Skip the doc, the wiki, and the email thread. Drop your notes into a Markdown paste, set an expiry, and send a single link your team can read in their browser.
AES-256-GCM, PBKDF2 key wrapping, and what zero-knowledge actually means here.