Hosting MTA-STS with DomainWarn

MTA-STS tells sending mail servers: "for this domain, deliver only over TLS and with a valid certificate". The policy is a text file that has to live at https://mta-sts.client.example/.well-known/mta-sts.txt – with its own certificate for that subdomain. That is where setups usually fail: a four-line file otherwise needs its own web server including certificate renewal.

DomainWarn hosts it for you. In the "E-Mail" tab of a domain you open "MTA-STS", switch on "Managed by DomainWarn" under "Management", pick mode and lifetime, and the client sets two records: a CNAME from mta-sts.client.example to the website and the TXT record _mta-sts.client.example. DomainWarn obtains the certificate for that subdomain itself – on the first request, for exactly that host name.

Mode testing only reports failures (via TLS-RPT), enforce makes sending servers abort when the mail server does not present a valid certificate. Start with testing, check the TLS-RPT reports in the "Email" tab and only then switch. DomainWarn takes the MX hosts for the policy from the domain's DNS unless you enter your own; without known MX hosts the file is deliberately not served, because a policy with a wrong mx entry makes deliveries fail. For Microsoft 365 enter *.mail.protection.outlook.com: Microsoft may change the MX host, and the wildcard covers every host below it.

In the client's DNS

mta-sts.client.example.    CNAME  domainwarn.com.
_mta-sts.client.example.   TXT    "v=STSv1; id=20260922120000"

The id in the TXT record has to match the served file. It changes whenever you change mode, lifetime or the MX list – the dashboard then shows the new value, and the TXT record has to follow, otherwise sending servers keep using the old policy from their cache.

One click instead of typing: if the zone is hosted at a connected DNS provider (Cloudflare, Hetzner DNS, IONOS, netcup, INWX, OVHcloud, Route 53, deSEC or autoDNS, see above), the card offers "Set up with Cloudflare" (or the respective provider). The first click shows a preview with type, name and content of both records and what already exists at the provider; only the second one creates or updates. At Cloudflare the CNAME is explicitly not proxied ("DNS only") – behind the orange cloud TLS would end at Cloudflare and the policy file could not get a certificate of its own.

DomainWarn only changes what DomainWarn created: a TXT record with an earlier id of this domain is updated without asking; a hand-written v=STSv1 record with a foreign id or a CNAME pointing elsewhere is only replaced after explicit confirmation; A or AAAA records under mta-sts.client.example and several policy records side by side are never deleted – you clean those up yourself. Other TXT records under the same name stay untouched.

If the last check still sees an old id, the card reports "The TXT record is outdated" and offers the update. With the switch "Update the DNS record automatically on changes" DomainWarn does it itself: after every policy change it updates the TXT record in the background – only this one record, and only as long as it was created by DomainWarn. If that fails (for instance because someone edited the record by hand), the card shows the reason and a change notification "MTA-STS record not updated" goes out.

The MTA-STS check then verifies from the outside that record, file and MX hosts line up – regardless of who serves the file.