blueredix logo
SCAN On-demand vulnerability scans from €149
low mta-sts-missing

MTA-STS not configured

MTA-STS forces the encryption of email coming in to your domain. Without it, an attacker on the network can quietly downgrade incoming mail to unencrypted and read it.

What this means in plain English

When another organisation’s mail server delivers email to your domain, the connection is supposed to be encrypted. The catch: by default the encryption is opportunistic — if encryption is offered, the sender uses it; if it isn’t, the sender falls back to sending in the clear. Worse, an attacker on the network in between can quietly strip the encryption offer, so even servers that would have encrypted fall back to plaintext.

MTA-STS is a public statement you publish that says, in effect: “encryption is mandatory for incoming mail to my domain — refuse to deliver if you can’t encrypt”. Sending servers that respect this statement (which is now most major providers — Google, Microsoft, Yahoo, Apple) won’t send your mail in the clear, no matter what an attacker on the network tries to do.

Why it matters to your business

Without MTA-STS, every email you receive can in principle be read by someone with a network position between the sender and your mail server: a hostile internet provider, a compromised router on the way, a state-level surveillance program, a corporate proxy.

Practical content that crosses your inbound mail every day:

  • Bank statements and invoices.
  • Password-reset links from services you use.
  • Contract drafts, NDAs, internal correspondence.
  • Anything customers send you via a contact form that lands in an inbox.

Mail-content disclosure is also a notifiable data-protection event under DSGVO if it concerns personal data — meaning a successful downgrade attack can turn into a regulatory matter, not just a security one.

How to fix it

MTA-STS has three small pieces. Whoever runs your domain and email hosting can put them in place in an afternoon.

  1. A DNS entry that says you have a policy and points to the policy file.
  2. The policy file itself, served from a small dedicated web address (mta-sts.your-domain.example) over HTTPS. The file lists which mail servers are allowed to receive mail for you and says encryption is mandatory.
  3. An optional reporting entry that lets you receive daily reports about encryption attempts other servers had with you — useful for spotting downgrade attempts or expired certificates.

If you don’t want to host the policy file yourself, services like Hardenize and Mailhardener provide hosted MTA-STS behind a single CNAME entry.

For Google Workspace administrators, MTA-STS is enabled directly from the Admin Console (Apps → Google Workspace → Gmail → Compliance → Secure transport).

A typical rollout starts in “testing” mode for a couple of weeks — encryption isn’t enforced, but you receive reports about what would have happened. Once the reports show no surprises, you flip to “enforce” mode.

Further reading