Sending a password by email feels convenient because it is quick and the recipient is already expecting the message. The convenience is the problem. A password in an email body is not a single message seen by one person. It becomes a set of copies that persist in places the sender and recipient rarely think about, and each copy is another chance for it to be read by someone it was never meant for.
Where a sent password ends up
- The sender's Sent folder, which is often synced to every device the sender uses.
- The recipient's inbox, along with any client cache, offline store and search index on each of their devices.
- Forwarding rules and filters, on either side, which may copy the message to an address that is no longer trusted.
- Backups kept by the mail provider and by the recipient's organization, which the sender has no control over.
- Notification previews on lock screens, which may display the body to anyone holding the phone.
- Any application with mail access, including third-party tools granted read permission, as described in OAuth consent phishing.
Deleting the message from one mailbox removes only one of these copies. Nobody can produce a complete list of where a message went after it was sent.
Transport encryption is not end-to-end
Mail between servers is often protected with TLS, and some domains enforce it through MTA-STS or DANE. That protects the connection between two servers. It does not protect the message from the servers themselves, and it is not guaranteed for every hop, because opportunistic TLS falls back to plaintext when the other side does not support it. The message is also stored in clear to the recipient's mail client, which is the point at which most password leaks actually happen. Encryption that exists only on the wire is not a reason to send a password by email. For content that must stay confidential end-to-end, a mechanism such as PGP or S/MIME is required, and even then the password problem remains if the recipient stores the message insecurely.
Email authentication does not help here
SPF, DKIM and DMARC show that a message came from a domain that was authorized to send it. They say nothing about whether the content should have been sent at all. A legitimate sender can send a password to the wrong person, and a compromised legitimate account can send one on purpose. The protections described in SPF, DKIM and DMARC explained are valuable, but they answer a different question.
The phishing angle
Attackers use the same habit against you. A message that asks you to reply with your current password, or that claims a support team needs your login to fix something, is phishing. Legitimate support staff have no need for your password. If a message asks for one, do not reply, do not enter it into a page the message links to, and report the message to security@itpromail.com.
Safer ways to share a secret
- A password manager with sharing features. Some managers can share a single entry with a named person and revoke that access later. The entry is not copied into the message body.
- A one-time secret link. Tools built for this produce a link that expires after one view or after a set time. Use one only from a service you trust, and send the link through a channel separate from anything else about the account.
- A different channel for the reminder. If a credential must be communicated, send it in person, by phone, or in a message on a different system, and never in the same thread as the account name.
- A reset flow instead of a shared password. Where the account allows it, the person who needs access can set their own credential through the official reset process rather than receiving one.
For ITProMail accounts, the right answer is usually not to share a password at all. Each client should have its own app password, created under Account > Security, so a single credential can be revoked without disturbing other devices. The app passwords guide and the account recovery guide describe how to create, revoke and recover credentials.
If a password has already been emailed
Treat the password as exposed. Change it from a session you trust, sign out other sessions, revoke any app passwords that could be affected, and check the account for forwarding rules or filters you did not create. If the password protected anything else, change it there too. Rotating the credential is the only reliable remedy, because the copies already in the mailbox cannot be fully recalled.