MTA-STS bei DomainWarn hosten
MTA-STS sagt sendenden Mailservern: „Für diese Domain bitte nur verschlüsselt und mit gültigem Zertifikat zustellen.“ Die Policy dafür ist eine Textdatei, die unter https://mta-sts.kunde.de/.well-known/mta-sts.txt liegen muss – mit eigenem Zertifikat für diese Subdomain. Genau daran scheitert die Einrichtung meistens: Für eine Datei mit vier Zeilen braucht es sonst einen eigenen Webserver samt Zertifikatsverlängerung.
DomainWarn übernimmt das Hosten. Im Reiter „E-Mail“ einer Domain öffnest du „MTA-STS“, schaltest unter „Verwaltung“ „Von DomainWarn verwaltet“ ein, wählst Modus und Laufzeit, und der Kunde setzt zwei Records: einen CNAME von mta-sts.kunde.de auf die Website und den TXT-Record _mta-sts.kunde.de. Das Zertifikat für die Subdomain besorgt DomainWarn selbst – beim ersten Abruf, für genau diesen Hostnamen.
Der Modus testing meldet Fehler nur (über TLS-RPT), enforce lässt sendende Server abbrechen, wenn der Mailserver kein gültiges Zertifikat liefert. Beginne mit testing, prüfe die TLS-RPT-Berichte im Reiter „E-Mail“ und stelle erst dann um. Die MX-Hosts in der Policy nimmt DomainWarn aus dem DNS der Domain, solange du nichts eigenes einträgst; ohne bekannte MX-Hosts wird die Datei bewusst nicht ausgeliefert, weil eine Policy mit falschem mx-Eintrag Zustellungen scheitern lässt. Bei Microsoft 365 trägst du *.mail.protection.outlook.com ein: Microsoft kann den MX-Host wechseln, der Platzhalter deckt jeden Host darunter ab.
mta-sts.kunde.de. CNAME domainwarn.com.
_mta-sts.kunde.de. TXT "v=STSv1; id=20260922120000"Die Kennung (id) im TXT-Record muss zur ausgelieferten Datei passen. Sie ändert sich bei jeder Änderung an Modus, Laufzeit oder MX-Liste – das Dashboard zeigt dann den neuen Wert, und der TXT-Record muss nachgezogen werden, sonst holen sendende Server die alte Policy weiter aus ihrem Zwischenspeicher.
Per Klick statt abtippen: Liegt die Zone bei einem verbundenen DNS-Anbieter (Cloudflare, Hetzner DNS, IONOS, netcup, INWX, OVHcloud, Route 53, deSEC oder autoDNS, siehe oben), steht in der Karte „Mit Cloudflare einrichten“ (bzw. mit dem jeweiligen Anbieter). Der erste Klick zeigt eine Vorschau mit Typ, Name und Inhalt beider Records und dem, was beim Anbieter schon dasteht; erst der zweite legt an oder aktualisiert. Bei Cloudflare liegt der CNAME ausdrücklich ohne Proxy („DNS only“) – hinter der orangen Wolke endete die TLS-Verbindung bei Cloudflare, und die Policy-Datei bekäme kein eigenes Zertifikat.
DomainWarn ändert dabei nur, was von DomainWarn stammt: Einen TXT-Record mit einer früheren Kennung dieser Domain aktualisiert es ohne Rückfrage; einen von Hand gesetzten v=STSv1-Record mit fremder Kennung oder einen CNAME auf ein anderes Ziel ersetzt es nur nach ausdrücklicher Bestätigung; stehen mehrere Policy-Records nebeneinander (dann gilt laut RFC 8461 gar keine), bleibt einer und die übrigen werden gelöscht – stammen alle von DomainWarn, ohne Rückfrage, sonst erst nach Bestätigung. A- oder AAAA-Records unter mta-sts.kunde.de löscht DomainWarn nach Bestätigung, bevor es den CNAME anlegt (ein CNAME darf nicht neben ihnen stehen). Jede Löschung steht vorher in der Vorschau und danach im Audit-Log und in der Zeitleiste. Andere TXT-Records unter demselben Namen bleiben unberührt.
Zeigt die letzte Prüfung noch eine alte Kennung, meldet die Karte „Der TXT-Record ist veraltet“ und bietet das Aktualisieren an. Mit dem Schalter „DNS-Record bei Änderungen automatisch nachziehen“ übernimmt DomainWarn das selbst: Nach jeder Änderung der Policy stellt es den TXT-Record im Hintergrund um – nur diesen einen, und nur, solange er von DomainWarn stammt. Scheitert das (etwa weil jemand den Record von Hand geändert hat), steht der Grund in der Karte, und es gibt die Änderungsmeldung „MTA-STS-Record nicht nachgezogen“.
Der MTA-STS-Check prüft anschließend von außen, ob Record, Datei und MX-Hosts zusammenpassen – unabhängig davon, wer die Datei ausliefert.
Siehe auch: Was geprüft wird