Email Encryption: What It Is, TLS vs S/MIME vs PGP, and How to Encrypt in Gmail and Outlook

Email was not designed to be private. A message crosses several servers on its way to the recipient, and without encryption each of them could, in principle, read it. Today most email is protected in transit, but that protection is only part of the picture, and the phrase "email encryption" covers several very different things. This guide explains what email encryption is, the difference between encryption in transit and encryption of the message itself, how TLS, S/MIME and PGP work, what Gmail and Outlook actually offer, what "confidential mode" does and does not do, when you need a dedicated encryption service and how to choose one. It is written for people who send sensitive messages and for teams that want a clear, honest picture without marketing language.

What is email encryption?

Email encryption is the use of cryptography to make the content of a message unreadable to anyone who does not hold the right key. The word covers three layers that are often mixed up:

1. Encryption in transit. The connection between your mail app and your provider, and between mail servers, is encrypted so that someone watching the network cannot read the traffic. This is done with TLS. See what email SSL, TLS and STARTTLS mean.
2. Encryption at rest. The provider stores your mailbox in encrypted form on its disks. This protects against stolen hardware but not against the provider itself, which usually holds the keys.
3. End-to-end (message-level) encryption. The message body, and sometimes attachments, is encrypted on the sender's device with the recipient's public key, so only the recipient's private key can open it. Intermediate servers, including the providers, see only scrambled data. S/MIME and PGP provide this.

When someone says they need "email encryption", ask which layer they mean. Transit encryption is already the default for most providers, while end-to-end encryption needs setup on both sides.

Encryption in transit: TLS

When your server sends mail to another server, it can start an encrypted TLS session using the STARTTLS command in SMTP. If both sides support it, the content of the connection is encrypted. If the receiving server does not support TLS, many senders still deliver the message unencrypted, because refusing would break delivery. That is called opportunistic TLS. Stricter policies exist, such as MTA-STS and DANE, which let a domain announce that it expects encrypted connections, but they require extra DNS setup. Our SMTP relay requires an encrypted connection on port 587 using STARTTLS, so mail submitted by your applications is protected on the first hop. For ports and the differences between them, see SMTP ports explained.

TLS has a limit worth understanding. It protects the connection, not the message. Every server that handles the message decrypts it, reads it if needed and re-encrypts it for the next hop. Your provider, the recipient's provider and any filtering service in the path can all technically access the content.

Message-level encryption: S/MIME and PGP

Both approaches need the sender to have the recipient's public key. This is the main reason end-to-end email encryption is less common than it could be: both parties must set it up, lose their keys and lose access, and some features such as server-side search stop working on encrypted content. Subject lines and addresses are usually not encrypted, because servers need them to route the message.

Encrypting email in Gmail

• Default protection. Gmail uses TLS when the other server supports it and shows a warning icon when a message was received over a connection that was not encrypted.
• Confidential mode. This lets you set an expiry date, require a passcode and block forwarding, copying and printing in the Gmail interface. It is a useful access control but it is not end-to-end encryption, and a determined recipient can still take screenshots or photos.
• S/MIME in Google Workspace. Administrators of some Workspace editions can enable S/MIME so that users can send and receive signed and encrypted messages.
• Client-side encryption. Some Workspace editions offer a feature where keys are controlled by the customer, so Google cannot read the content. Availability depends on the edition and administrator settings, so check Google's current documentation.

Encrypting email in Outlook and Microsoft 365

• Default protection. Microsoft 365 uses TLS between servers when possible and encrypts mailboxes at rest.
• S/MIME. Outlook supports S/MIME. You install a certificate, then choose to encrypt or sign a message from the options in the message window.
• Microsoft Purview Message Encryption. For business plans that include it, you can encrypt a message and apply rights restrictions, and recipients outside your organisation read it through a portal or a one-time passcode. Which plan includes which feature changes over time, so consult your administrator or Microsoft's documentation.
• Sensitivity labels. Administrators can apply encryption automatically to messages that match rules, for example those containing financial data.

The consumer Outlook.com service has fewer options than the business plans, so look at your own account's menus.

When do you need an email encryption service?

Search volume for "email encryption service" is high because organisations with compliance duties need a simple way to protect messages sent to people who have not set up keys. A typical service works as a gateway or add-in: you send a message, a rule detects sensitive content or a user clicks an encrypt button, and the recipient receives a notice with a link to a secure portal or a passcode-protected attachment. You might need such a service if you:

• send health, financial, legal or personal data by email and your rules require protection beyond ordinary TLS;
• must prove who sent a message, using digital signatures;
• exchange files with customers who cannot be asked to install certificates;
• operate under contracts or regulations that specify encryption controls.

Questions to ask any provider: Who holds the keys? Can the provider read the content? How do recipients open messages and what do they need to install? How are lost passwords handled? Does it work with your mail system and mobile devices? Where is data stored? What logs exist? We deliberately do not recommend a specific product here, because the right choice depends on your regulations, your mail platform and your recipients. Regulations such as HIPAA in the United States and the GDPR in Europe may influence what you need; this is general information, not legal advice.

Encryption does not stop phishing or account takeover

An encrypted message sent to the wrong address is still a leak, and an attacker with your password reads your mailbox in plain form. Pair encryption with strong account security: unique passwords, multi-factor authentication and attention to phishing. See how to spot a phishing email. Encryption also does not prove that a message really came from the claimed domain. That is the job of authentication through SPF, DKIM and DMARC; see email authentication explained.

A practical approach for most teams

1. Make sure every system that sends your mail uses TLS and authenticates your domain.
2. Do not email passwords, card numbers or identity documents at all if there is a safer channel, such as a secure portal.
3. For regulated data, adopt S/MIME or a gateway-based service, with a written policy on what must be encrypted.
4. Train staff to double-check recipients, as a misdirected encrypted message may still reach an unintended person.
5. Review the setup yearly, including certificate expiry dates.

Free options

People search for free email encryption, and free options exist: PGP tools are open source, some privacy-focused mail providers include end-to-end encryption by default between their own users, and S/MIME certificates are sometimes available at no cost for personal use. Free tools shift the effort to you, since you must manage keys, back them up and persuade recipients to cooperate. For an organisation with many users, administration time usually outweighs licence cost.

References and further reading

• RFC 3207: SMTP Service Extension for Secure SMTP over TLS
• RFC 8551: S/MIME Version 4.0 Message Specification
• RFC 4880: OpenPGP Message Format