Authentication is not encryption

If you have done the work on email authentication — SPF, DKIM, and DMARC all published and enforcing — you have solved a real and important problem: proving that a message claiming to come from your domain actually did. That stops spoofing and the business email compromise that rides on it. But there is a separate question those three records do not answer at all: when someone sends mail to your domain, does it travel across the internet encrypted, or in the clear?

The uncomfortable default is that mail transport encryption is opportunistic. When a sending server connects to yours, it tries to negotiate TLS — and if that negotiation fails, or is quietly interfered with, most servers fall back to plaintext and deliver the message anyway rather than bounce it. That fallback is invisible. Nobody gets an error. The mail arrives, looks normal, and was readable by anyone positioned on the network path. A determined attacker can even force the downgrade by tampering with the connection setup, stripping the encryption so the fallback kicks in. Your carefully-authenticated mail can still cross the wire naked.

MTA-STS closes the silent-fallback door

MTA-STS — Mail Transfer Agent Strict Transport Security — is the policy that turns "encrypt if convenient" into "encrypt or don't deliver." You publish a policy, discoverable via DNS and served over HTTPS, that tells sending servers: mail for this domain must be delivered over TLS to a valid, certificate-matching mail server, and if it can't be, hold the message rather than fall back to plaintext. A sender that respects the policy — and the major providers do — will refuse to downgrade. The silent plaintext fallback that a network attacker relies on simply stops being available.

It is worth being precise about scope, because overclaiming here is exactly the trap this product avoids:

  • MTA-STS protects the transport of mail to your domain, hop by hop between mail servers. It is not end-to-end message encryption and does not protect a message once it is sitting in a mailbox.
  • It depends on the sender honouring the policy. A sender that ignores MTA-STS is not blocked; the standard is about removing the easy downgrade, not achieving a hard guarantee against every actor.
  • It complements DANE, an alternative TLS-enforcement mechanism anchored in DNSSEC; a lean team without DNSSEC usually reaches for MTA-STS first because it is simpler to deploy.

Rolling it out is a DNS and domain hygiene exercise you can finish: publish the policy in testing mode first so failures are reported but mail still flows, watch the reports, then move to enforce once you are confident nothing legitimate is breaking.

TLS-RPT is the watch half

A policy you cannot observe is a policy you cannot trust. TLS-RPT — TLS Reporting — is the companion record that asks sending servers to send you a daily report of how TLS negotiation went when they delivered to you: how many connections succeeded, how many failed, and why. That turns transport encryption from an invisible assumption into a measured number. Without TLS-RPT you are hoping MTA-STS works; with it, you have evidence, and more importantly you have an early-warning signal.

Those reports are exactly the kind of thing that belongs in your log and detection pipeline rather than an inbox someone glances at once:

  • A sudden spike in TLS failures from a sender that used to succeed is a signal — a certificate that expired on your side, a misconfigured mail server, or, in the worst case, someone actively interfering on the network path.
  • A steady trickle of failures points at a specific sender or a specific server that is falling back, and each is a fixable configuration gap rather than a mystery.
  • A drop to zero reports can itself be a signal that a record broke or a policy stopped being discoverable.

A downgrade report is a finding

The point of watching is to act, and the natural home for a persistent TLS failure is the same findings workflow as everything else — an owner, a severity, a deadline — rather than a report that scrolls past. Ranked, as always, by exposure: a mail server presenting an expired certificate so that inbound mail is silently downgrading is a high-severity issue because it defeats the whole control; a single misbehaving low-volume sender is real but waits behind it. This ties directly into certificate lifecycle monitoring — an expired mail-server certificate is one of the most common reasons MTA-STS enforcement quietly starts rejecting or downgrading legitimate mail.

  • Route TLS-RPT anomalies into the same tracked queue as other risks, so a downgrade trend gets an owner instead of being noticed six weeks late.
  • Correlate failures with certificate expiry so the fix — renew and redeploy — is obvious rather than investigated from scratch.
  • Keep the policy in testing mode long enough to distinguish a real attacker from your own broken configuration before you enforce.

The evidence it produces

An assessor reviewing how you protect data in transit will ask about more than your website's HTTPS. Mail is data in transit too, and encryption in transit that only happens opportunistically is a gap a careful reviewer will notice. A published MTA-STS policy in enforce mode, a TLS-RPT feed you actually monitor, and a record that downgrade reports become tracked findings is exactly the artifact that shows inbound mail encryption is required and verified — and it feeds continuous monitoring and evidence collection instead of being asserted without proof.

One honest caveat: a platform can watch your TLS-RPT reports, alert on a spike in mail-transport encryption failures, and raise a tracked finding when inbound mail starts downgrading — it organizes, watches, and proves the work. It does not publish your MTA-STS policy, renew your mail-server certificates, or force any sender to honour the standard, and it does not grant or guarantee any certification; the DNS records, the enforcement decision, and the remediation are operational steps your team owns, and which data-in-transit obligations apply to you is a question for counsel.

Authenticating your mail proves who sent it; it says nothing about whether it travelled encrypted. Publish MTA-STS so inbound mail must arrive over TLS instead of silently falling back to plaintext, turn on TLS-RPT so the failures become a number you can watch, and treat a downgrade trend as a finding ranked by what it exposes. Make encrypted delivery the requirement, then prove it is holding.