Email Encryption in Transit: What TLS and STARTTLS Protect and Do Not

"Is my email encrypted?" has two honest answers: yes, almost always, while it moves between servers and apps; and no, not once it lands. Understanding that distinction tells you what TLS buys you, why the STARTTLS setting in your mail app matters, and when you need something stronger. This guide keeps the cryptography to a minimum and focuses on what a business owner can check and control.

Quick answer

TLS (Transport Layer Security) encrypts the connection an email travels over, so anyone watching the network sees scrambled data. It protects three hops: your mail app to your server, your server to the recipient's server, and their server to their app. It does not encrypt the message itself, so both mail providers can read it, and it does nothing if one hop falls back to plain text. End-to-end encryption is the separate tool for content that must stay private from the providers too.

The three hops and how each is protected

1. Your app to your outgoing server (submission). Uses SMTP on port 587 with STARTTLS, or port 465 with implicit TLS. With OquMail the setting is mail.oqumail.com, port 587, STARTTLS; choosing SSL/TLS on 587 is the most common misconfiguration and makes sending fail.
2. Your server to the recipient's server (relay). Uses SMTP on port 25. Almost all major providers offer STARTTLS here, so the hop is encrypted whenever both sides support it. This is called opportunistic TLS: it is used if available and skipped if not.
3. The recipient's server to their app. IMAP on port 993 with SSL/TLS, or webmail over HTTPS. For OquMail mailboxes that is mail.oqumail.com, port 993.

STARTTLS versus SSL/TLS in your mail app

Both encrypt; they differ in how the connection begins. Implicit SSL/TLS (port 465 for SMTP, port 993 for IMAP) is encrypted from the first byte. STARTTLS (port 587 for SMTP, port 143 for IMAP) starts in plain text and upgrades to encryption after a STARTTLS command. Neither is "less secure" when configured correctly; the security problem is picking the wrong one for the port, which makes the connection fail rather than silently downgrade in modern apps.

What TLS in transit does not protect

• The content at rest. Your provider and the recipient's provider store the message readable, which is how search, spam filtering, and webmail work.
• The hop between servers if one side does not support TLS. Opportunistic means optional; a small fraction of servers still accept only plain text.
• Against a fake server. Basic STARTTLS between servers usually does not verify the certificate, so a network attacker could in theory present their own. MTA-STS and DANE exist to close this gap.
• Forwarding. Once a recipient forwards your message, its onward hops are whatever their provider negotiates.
• The recipient's screen, printer, or a compromised account.

How to check whether a message travelled over TLS

1. In Gmail, open the message and click Show original. Each Received: header shows the hop; look for "with ESMTPS" (the S means TLS) and a TLS version such as TLSv1.3.
2. In Outlook desktop, open the message, choose File then Properties, and read the Internet headers box for the same Received: lines.
3. Gmail also shows a small padlock icon on the message; a red open padlock means at least one hop was not encrypted.
4. For your own outgoing mail, check your provider's delivery logs if it keeps them. OquMail records per-message delivery details, which is a quick way to confirm how your mail was handed off.

Making server-to-server TLS mandatory: MTA-STS

MTA-STS (RFC 8461) lets a domain publish a policy saying "only deliver to my mail servers over verified TLS". It requires a TXT records (short text lines in DNS used for email security) at _mta-sts.yourdomain.com, a small HTTPS-hosted policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, and optionally a TLS-RPT record at _smtp._tls.yourdomain.com to receive reports. It protects inbound mail to you, and Gmail, Outlook, and others honour it. It is a worthwhile step once the basics are stable, but check with your mail host that their MX hostnames present certificates matching the policy before setting mode to enforce.

Common questions

Is email over TLS safe enough for customer data?

For everyday business correspondence, yes, and it is what most regulators consider standard practice. For highly sensitive material (medical records, legal privilege, credentials) use end-to-end encryption or a secure link with expiry rather than relying on transit encryption alone.

Why does my mail app say the certificate is invalid?

Usually because the hostname in the app does not match the certificate. Use the exact hostname your provider publishes (for OquMail, mail.oqumail.com) rather than mail.yourdomain.com, unless your provider tells you a custom hostname is supported.

Does TLS affect deliverability?

Indirectly. Major receivers increasingly expect TLS from senders and some show warnings for unencrypted mail. A properly configured provider handles this for you; you do not need to configure anything beyond the correct client settings.