How to Send a Secure, Confidential Email From a Business Mailbox

Email between modern providers is encrypted in transit, which protects it from eavesdropping on the network but not from anyone with access to either mailbox, a forwarded copy or a lost phone. Sending something confidential safely is mostly about choosing what to put in the message and what to put behind a link. Here is what TLS covers, a checklist for sensitive sends, and the cases where email is simply the wrong tool.

Quick summary

• Your app to your server: connections on IMAP 993 (SSL/TLS) and SMTP 587 (STARTTLS) are encrypted. That is why the port and security settings matter.
• Server to server: most providers use opportunistic TLS between them, so the message is encrypted on the wire between OquMail and Gmail, Microsoft and the other large hosts. You can confirm on a received message: Gmail shows a padlock, and the Received headers mention TLS.
• Not protected: the message at rest in either mailbox, any copy that is forwarded, printed or synced to a device, and the recipient's own security habits.
• Confirm the recipient's address by typing it fresh or picking it from a reply, not from autocomplete, which is how confidential mail reaches the wrong Ana.
• Put the sensitive content behind a link to a file you control (a shared drive with access restricted to the recipient's account, with an expiry), rather than attaching it. You can revoke a link; you cannot recall an attachment.

What is already protected

• Your app to your server: connections on IMAP 993 (SSL/TLS) and SMTP 587 (STARTTLS) are encrypted. That is why the port and security settings matter.
• Server to server: most providers use opportunistic TLS between them, so the message is encrypted on the wire between OquMail and Gmail, Microsoft and the other large hosts. You can confirm on a received message: Gmail shows a padlock, and the Received headers mention TLS.
• Not protected: the message at rest in either mailbox, any copy that is forwarded, printed or synced to a device, and the recipient's own security habits.

Checklist before sending something sensitive

1. Confirm the recipient's address by typing it fresh or picking it from a reply, not from autocomplete, which is how confidential mail reaches the wrong Ana.
2. Put the sensitive content behind a link to a file you control (a shared drive with access restricted to the recipient's account, with an expiry), rather than attaching it. You can revoke a link; you cannot recall an attachment.
3. If you must attach, use an encrypted PDF or a password-protected archive, and send the password by a different channel: a text message or a phone call, never in the same or a following email.
4. Keep identifiers out of the subject line. "Contract for A. Okafor" rather than the account number, because subjects appear in notifications and previews.
5. Write the minimum. Reference numbers instead of full card or ID numbers; last four digits are usually enough.
6. Check the thread history you are quoting. Confidential detail in an earlier reply travels with every new one.

Things to never send by email

• Full card numbers, CVV codes, bank login details, national ID numbers in full.
• Passwords, even "temporary" ones. Use a password manager's share feature or a link that expires after one view.
• Medical or legal detail about a named person unless your industry rules explicitly allow it and the recipient's system is approved.
• Anything you would not want read aloud in a dispute; email is discoverable and permanent.

End-to-end encryption, and why most small businesses skip it

S/MIME and PGP encrypt the message body so only the recipient's key can read it, and they work in Outlook, Apple Mail and Thunderbird. The catch is that the recipient must have a key and a compatible setup, which most customers do not. Use them with specific partners who ask for them; for everyone else, the link-plus-separate-password approach gives most of the protection with none of the setup.

Reduce the damage if a mailbox is compromised

• Turn on two-factor authentication for webmail and use a long unique password, so a leaked password alone does not open the mailbox.
• Archive old confidential threads out of the live mailbox to an offline file, so a compromise exposes months of mail rather than years.
• Keep confidential documents in file storage with access controls rather than in mailboxes at all; email carries the link.
• Publish SPF, DKIM and DMARC so nobody can send convincing mail as your domain. OquMail sets these up with live verification during domain setup.

Common questions

Does "confidential" in the subject or a legal footer protect anything?

No. A disclaimer has no technical effect and little legal weight once the message is delivered. It is a courtesy, not a control.

Is a password-protected PDF secure?

A modern PDF with a long password uses strong encryption and is reasonable for documents. A ZIP with a short password is weak. In both cases the security is only as good as how you send the password, so use another channel.

How do I know if the recipient's provider supports TLS?

Send yourself a test from their domain or ask them to send you one, then read the Received headers; look for "with ESMTPS" or a TLS version in the line describing the hop to your server. The major providers all support it. For a small self-hosted server you cannot verify, prefer a link over an attachment.