Nothing requires anyone to encrypt mail to you

Ask whether company email is encrypted in transit and the answer is usually yes. That answer is also incomplete.

Most modern mail travels over TLS. The sending and receiving servers negotiate encryption and, in normal conditions, use it. The important word is negotiate.

Without an enforced transport policy, successful TLS today does not necessarily mean a sender is required to reject an unsafe path tomorrow.

Opportunistic TLS is designed to deliver the mail

Traditional SMTP prioritizes getting the message through. The receiving server advertises TLS support. The sender normally uses it. If secure negotiation is unavailable, ordinary SMTP can be designed to continue rather than permanently fail the delivery.

That compatibility is why email works between an enormous number of independent systems. It is also why seeing TLS on almost every message is not the same as having a policy that requires authenticated TLS.

A downgrade or routing problem can change what the sender sees. Without another control, successful delivery may still win.

MTA-STS publishes the rule

MTA-STS lets a receiving domain tell supporting senders:

• These are the mail servers that should receive our mail.
• They should support TLS.
• Their certificates should validate correctly.
• When the policy is in enforcement mode, do not silently fall back to an untrusted delivery path if those requirements cannot be satisfied.

The mechanism has a few moving parts. A DNS record announces that the domain publishes an MTA-STS policy. The policy itself is served securely over HTTPS.

That policy states the accepted mail-server pattern, mode and caching period. Supporting senders retrieve and cache it, then use it when deciding how mail should be delivered.

The important change is conceptual: TLS stops being merely something both servers happened to negotiate. It becomes something the receiving organization has published a policy about.

Testing mode exists for a reason

An incorrect transport policy can affect legitimate inbound mail. That is why MTA-STS has a testing mode.

In testing mode, supporting senders can evaluate the policy and report problems without being required to reject delivery because of those policy failures. That gives you a chance to find mistakes before they become availability problems.

Examples include:

• A server name that does not match what the policy expects.
• A certificate problem.
• An MX configuration that changed while the policy did not.
• A policy host that cannot be reached reliably.

These are infrastructure mistakes, not malicious attacks, and they should be found before enforcement. Do not treat testing mode as a ceremonial step before switching on the real setting. The testing period is the engineering work.

TLS-RPT tells you what senders are seeing

MTA-STS defines the expectation. TLS-RPT gives participating senders somewhere to report transport-security results.

Those reports can expose failures that are otherwise difficult to see from your side. You are looking for patterns rather than one isolated error:

• Certificate validation failures.
• Policy mismatches.
• Delivery attempts to hosts that do not satisfy the policy.
• Failures retrieving or applying the policy.

The point is to understand what enforcement would change before asking senders to enforce it. Not every sender supports every mechanism, so the reports are useful evidence rather than a complete view of all mail on the internet.

Treat the policy as infrastructure

The MTA-STS policy is small enough to look like a file you can upload once and forget. It should be treated like infrastructure instead.

Keep it under version control. Document where the DNS record lives. Make changes to the MX environment and the policy through the same change process. Monitor the HTTPS host that serves it. Know who owns the configuration.

The problem with a tiny security file is not that it is difficult to maintain. It is that nobody remembers it is there when the mail architecture changes.

Enforcement is an availability decision too

Moving from testing to enforcement is a security improvement. It is also an availability decision.

A supporting sender that cannot establish a path satisfying the published policy may defer or fail delivery rather than downgrade to something the policy says is unacceptable. That is the desired security behavior. It is also why you want the configuration boring before you enforce it.

The check worth running

Check whether your domain publishes an MTA-STS policy. If it does, read the policy and compare the accepted mail-server entries with your current MX design.

Then look at your TLS-RPT data. If the configuration in DNS, the policy file and the mail environment describe three different versions of reality, fix that before changing enforcement.

Explore this expertise: Email Security

All technical notes