Why TLS Isn't Enough Without Policy

Your mail server supports TLS. Your certificate is valid. You'd assume email is encrypted in transit. In practice, it often isn't — and you'd never know without active monitoring.

The false comfort of "TLS enabled"

Having TLS configured on your mail server is necessary but not sufficient. Here's why:

• Opportunistic TLS can be stripped: STARTTLS is negotiated in plaintext before encryption starts. An attacker can remove the STARTTLS offer, forcing plaintext delivery.
• No certificate validation: Most mail servers don't verify the receiver's certificate. They'll accept self-signed certificates, expired certificates, or certificates for the wrong domain.
• No delivery guarantee: If TLS negotiation fails, mail is still delivered — just in plaintext. There's no mechanism to say "refuse delivery if you can't encrypt."
• No visibility: Without TLS reporting, you can't tell whether inbound email is actually being encrypted. It's entirely possible that some senders are delivering to you in plaintext right now.

What "policy" means

Policy mechanisms turn optional encryption into required encryption. They give you the ability to say:

• "Senders must use TLS when delivering to us" (MTA-STS enforce mode)
• "Senders should tell us when TLS fails" (TLS-RPT)
• "This specific certificate is the only valid one for our mail server" (DANE/TLSA)

Without policy, you're relying on every sending server in the world to correctly negotiate TLS, validate certificates, and choose not to fall back to plaintext. That's not a reliable security posture.

The monitoring gap

The biggest issue isn't attacks — it's misconfiguration. Common scenarios where TLS silently fails:

• Certificate renewal failure: Your cert expires and some senders fall back to plaintext instead of alerting you
• TLS version mismatch: You upgrade to TLS 1.3 only, but some older senders only support TLS 1.2
• Firewall interference: A corporate firewall strips STARTTLS from connections it inspects
• DNS issues: STARTTLS depends on the MX hostname resolving correctly and matching the certificate

All of these cause email to be delivered in plaintext. Without TLS-RPT, you'll never know.

The three layers of email transport security

Layer 1: TLS on your server (baseline)

Configure TLS, install a valid certificate, support modern TLS versions. This is table stakes — without it, nothing else matters.

Layer 2: TLS-RPT (visibility)

Publish a _smtp._tls record so senders report TLS failures. This gives you visibility into whether encryption is actually working for your inbound mail. Deploy this first — it's just one DNS record with no risk.

Layer 3: MTA-STS (enforcement)

Publish an MTA-STS policy that requires TLS for inbound delivery. Start with mode: testing, monitor TLS-RPT reports, then switch to mode: enforce. This is the layer that actually prevents downgrade attacks.

The bottom line

TLS on your server is like having a lock on your door. MTA-STS is like telling the delivery person "don't leave packages unless I can verify it's you." TLS-RPT is the security camera that tells you when something went wrong.

All three layers are needed. TLS alone is not enough.