# Opportunistic vs enforced TLS

> TLS encrypts email in transit between mail servers. Opportunistic TLS prioritizes delivery; enforced TLS prioritizes confidentiality. Here is the tradeoff.

TLS (Transport Layer Security) encrypts an email **in transit** as it travels from the sending mail server to the receiving mail server over SMTP. Whether that encryption is best-effort or mandatory is the difference between **opportunistic** and **enforced** TLS — and it is a real tradeoff between getting the mail delivered and guaranteeing it was encrypted.

> **Note:** For SMTP connections, the supported protocol versions are **TLS 1.2, TLS 1.1, and TLS 1.0** — the receiving server negotiates the highest version both sides support.

## Opportunistic TLS

With **opportunistic** TLS, the sending server **tries** to negotiate an encrypted connection (via STARTTLS). If the receiving server supports TLS, the message is encrypted in transit. If the receiving server does not support TLS — or the handshake fails — the sender **falls back to plaintext** and delivers the message anyway.

- **Delivery first.** The message is almost never blocked for a TLS reason; it goes through encrypted when possible, plaintext when not.
- **No guarantee of confidentiality.** A silent downgrade (including an active downgrade attack that strips STARTTLS) leaves the message in cleartext, and you would not know.
- This is the **default** behavior across most of the internet's mail, and what MailBlastr uses for normal sending so legitimate mail is not bounced by a receiver with a weak or misconfigured TLS setup.

## Enforced TLS

With **enforced** (required) TLS, encryption is **mandatory**. If the receiving server cannot negotiate a valid TLS connection, the message is **not delivered** — it is deferred or bounced rather than sent in plaintext.

- **Confidentiality first.** The message is never transmitted unencrypted; a downgrade attack causes a delivery failure instead of a silent leak.
- **Delivery can fail.** Any receiver with no TLS, an expired certificate, or a misconfigured handshake will reject your mail — so enforced TLS can cause bounces that opportunistic TLS would have delivered.
- Appropriate for **sensitive or regulated** mail (e.g. healthcare, finance) where leaking content in transit is worse than a bounce, often paired with **MTA-STS** and **TLS-RPT** so receivers advertise and you monitor TLS enforcement.

## Which should I use?

|  | Opportunistic TLS | Enforced TLS |
| --- | --- | --- |
| Priority | Maximize delivery | Guarantee confidentiality |
| If receiver has no/broken TLS | Sends in plaintext anyway | Fails (defer/bounce) |
| Downgrade attack | Can silently strip encryption | Delivery fails instead of leaking |
| Best for | General transactional & marketing mail | Sensitive / regulated communications |

> **Note:** For most senders, **opportunistic TLS is the right default** — it encrypts the vast majority of mail in practice without sacrificing delivery. Reach for enforced TLS only when a confidentiality requirement outweighs the risk of bounced mail to receivers with poor TLS support.