Last updated: July 2026

In short: MTA-STS can’t be activated with a click at the large German shared hosts (IONOS, Strato, All-Inkl, Netcup, domainfactory, united-domains, checkdomain). The DNS part is trivial — the hurdle is the policy file served over HTTPS. This article explains why, and shows the paths that remain open to you.

What MTA-STS requires

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) ensures that other mail servers only deliver messages to your domain over a connection that is “authenticated with a valid public certificate” and “encrypted with TLS 1.2 or higher”. This closes a dangerous gap: normally, “if a TLS connection can’t be created, servers often send the message anyway” — that is, in the clear. That’s exactly what makes SMTP vulnerable, because “SMTP connections are at risk for man-in-the-middle and other types of malicious attacks”.

The catch: MTA-STS consists of two parts — and only one of them is DNS.

  1. DNS TXT record under _mta-sts.your-domain (v=STSv1; id=…). Any host that allows TXT records can do this — so all of them.
  2. Policy file at https://mta-sts.your-domain/.well-known/mta-sts.txt. And here it gets inconvenient.

Why the policy file is the hurdle

The policy file must, per the standard, be reachable over HTTPS — on a subdomain whose name starts with mta-sts, with a valid certificate signed by a real CA. Concretely you need:

  • a subdomain mta-sts.your-domain pointing to a web server,
  • a valid TLS certificate for exactly this subdomain,
  • the ability to serve a static text file under /.well-known/,
  • and the discipline to increment the id in DNS on every policy change.

Managed mail servers take this off your hands — Mailcow, for instance, “hosts the policy file centrally to simplify management”, generates the policy dynamically, and maintains the id itself. Google Workspace and Microsoft 365 document MTA-STS thoroughly, but require that you host the policy file (Microsoft suggests Azure).

The German shared hosts simply offer no MTA-STS function — neither a toggle nor central policy hosting. They don’t know your MX configuration as a “feature” and provide no policy URL.

The paths that remain at a shared host

You can still implement MTA-STS — just manually:

A) Host the policy file on your webspace. If you have a web hosting package at the same host, set up the subdomain mta-sts.your-domain, obtain a certificate (usually Let’s Encrypt via one click in the host panel), and place the file at /.well-known/mta-sts.txt. The policy file itself is simple:

version: STSv1
mode: testing
mx: mail.your-host.com
max_age: 86400

The mx lines must contain exactly the hostnames of your MX records. Start with mode: testing, analyze TLS-RPT reports, then switch to enforce.

B) Use an external MTA-STS host. There are specialized services and self-hosting templates (static webspace, a small cloud bucket with HTTPS, or a Cloudflare Worker) that only serve the policy file. Your domain DNS stays at the host, only the mta-sts subdomain points elsewhere.

C) The foundation first, then MTA-STS. Honestly: MTA-STS is the finishing touch. If SPF, DKIM, and DMARC aren’t cleanly in place yet, do that first — the security gain per effort is significantly higher there.

And TLS-RPT?

Unlike MTA-STS, TLS-RPT is a pure DNS TXT record with no HTTPS file — you can set it easily at any shared host. It’s worth activating TLS-RPT even if you don’t (yet) implement MTA-STS: the reports show you how often mail to your domain is delivered over TLS.

Verify the result

The free MXAudit scanner checks whether your _mta-sts record exists, whether the policy file is reachable, and whether its certificate is valid — together with TLS-RPT and your general TLS status.

Further reading