Why not to send passwords over email, Slack or Teams
Who can read a password sent by email, Slack or Teams, for how long, and whether you can take it back. Plus what to do if you have already sent one.
On this page
Sending passwords over email or Slack is risky for a reason that has little to do with encryption in transit. Email, Slack and Teams are built to keep messages, index them, sync them to every device and hand them to admins and auditors on request. That’s what makes them useful. It also means a password you send to one person can be read by a long list of other people, for years, and you can’t take it back.
So the answer is: send the password as a one-time link, share it from a password manager, or hand it over in person. If you’ve already sent one by email or chat, change the password. Deleting the message is not enough. The rest of this page shows why, concretely, so you can make the case to the colleague who keeps doing it.
Who can read a password you emailed
| Who | For how long | Can you take it back? |
|---|---|---|
| The recipient, and anyone they forward it to | Until each of them deletes it. Every forward is a new copy you don’t know about. | No |
| Everyone on CC, BCC or a distribution list. In a Microsoft 365 group, members who join later can read the conversation history. | As long as the group’s mail exists | No |
Delegates and shared mailboxes: an assistant with delegate access, everyone who can open it@ or support@ | As long as the mailbox exists | No |
| Mail admins at both ends, including the recipient’s IT team, whom you’ve never met. Admins can run content searches across every mailbox. | As long as the message exists anywhere | No |
| Archives, journaling and backups (Microsoft Purview retention, Google Vault, Mimecast and the like) | Set by their retention policy, often years | No, and a legal hold overrides deletion |
| Whoever receives an eDiscovery export: lawyers, investigators, auditors | As long as the export sits on someone’s drive | No |
| Every device that syncs the mailbox: phones, tablets, laptops with an offline cache, the old phone in a drawer | Until each device is wiped | No |
| Anyone using search on those mailboxes, including assistants such as Microsoft 365 Copilot that answer from mail the user can access | As long as the message exists | No |
| Whoever compromises any of the above later | Whenever that happens | No |
Deleting the email from your Sent folder removes one copy out of all of these. In Exchange Online, even that copy moves to Recoverable Items, where it’s kept for 14 days by default, or indefinitely under a retention policy or hold.
Transit isn’t as tidy as people assume, either. Mail between organisations is encrypted with TLS only when both servers agree to it, unless the receiving domain enforces it with MTA-STS or DANE. Most of the time it is encrypted. You can’t tell from your outbox.
Slack and Teams keep it too
Chat feels more ephemeral than email. It isn’t.
| Where | Who else can read it | How long |
|---|---|---|
| A Slack channel | Everyone in it, including people added later who scroll back or search. Single- and multi-channel guests in that channel. | For the life of the workspace by default. Admins can set shorter retention on paid plans. |
| A Slack Connect channel | The other organisation’s members, and their admins’ retention, export and eDiscovery settings, which you don’t control | Whatever the other organisation keeps |
| Slack exports and the Discovery API | Workspace owners on Business+ (once Slack approves the request) and Enterprise plans can export messages from all channels and DMs. Enterprise plans can stream every message, edits and deletions included, to eDiscovery and DLP tools. | As long as the export or archive exists |
| Slack apps and bots | Any app installed with permission to read the channel’s history | Whatever the app’s vendor keeps |
| Notifications | Lock-screen previews, and Slack’s emails about unread messages, which include the message text | As long as the notification email exists |
| A Teams chat or channel | Chat messages are stored in each participant’s Exchange Online mailbox, channel messages in the team’s group mailbox. Compliance admins can find them with an eDiscovery search. | Set by Microsoft Purview retention policies. Under a retention policy, deleted messages are kept in a hidden folder until the period ends. |
| Teams chat with another organisation | Each side’s copy lives in its own tenant, under its own retention | Whatever the other tenant keeps |
The pattern is the same as email. Your “delete” removes the copy you can see. It doesn’t remove the copies that exist precisely so that deletions can be audited.
The compromised mailbox problem
The table describes people with legitimate access. The bigger risk is someone without it.
When an attacker gets into a mailbox or a Slack account, through a phishing page, a stolen session token or a reused password, one of the first things they do is search it. “password”, “login”, “credentials”, “VPN”. Every password sitting in that history extends the damage from one account to every system those messages mention. The Xero login someone emailed to finance two years ago still works if nobody changed it, and the attacker now has it.
This is the strongest argument for one-time links. A link that has already been opened, or has expired, is worth nothing to whoever finds it later. The message history can stay exactly as it is.
Tickets and text messages are no better
Support tickets in Jira, Zendesk or ServiceNow keep every comment, email them out as notifications, show them to everyone with access to the queue, and are routinely exported to reporting tools. Text messages sit on both phones, get backed up to iCloud or Google, and appear on lock screens. Neither is a safe place for a password, and both are where people put them when email feels wrong.
If you’ve already sent one
- Change the password. This is the only step that actually fixes it. Treat it as exposed from the moment it was sent, because you can’t prove who has read it.
- Check whether it was used. Look at the sign-in logs for that account since the message was sent, and for sign-ins from places or devices you don’t recognise.
- Then delete the message. It reduces casual exposure: the next person searching the channel won’t trip over it. Ask the recipients to delete their copies too. Be clear with yourself that this is tidying up, not remediation.
- Send the new password properly. How to send a password securely has the step-by-step.
- Decide whether it’s a breach. If the account gives access to personal data and the logs show someone who shouldn’t have used it, UK GDPR may require you to report it to the ICO within 72 hours of becoming aware. If the logs are clean and you’ve rotated, you’ve closed it.
If the password went into a shared Slack channel or a Slack Connect channel with another company, rotate first and talk afterwards. You can’t recall the other organisation’s copy.
What to do instead
- A password manager when the other person needs ongoing access: share the item through a shared vault (1Password) or collection (Bitwarden).
- A one-time link when they need it once, or when they aren’t in your password manager. ShareShield links open a set number of times (once by default) and are deleted after the last view or at their expiry, whichever comes first. Paste the link into Slack or email as usual; once it’s been opened, the link in your history is dead.
- A secret request when you need someone to send a password to you. They fill in a one-time form instead of writing an email; asking a client for a password covers the wording.
To make it less likely in the first place, data loss prevention helps. Microsoft Purview DLP has built-in sensitive information types for passwords and common credential formats, and can flag or block them in Exchange and Teams. It won’t catch everything, but it catches the habit early, and a policy tip that says “use a one-time link instead” teaches more than an annual training slide.
Send the next one as a link that expires.
ShareShield turns a password, key or file into a link that opens once and is then deleted. You can send a text secret without an account.