MTA-STS und TLS-RPT einrichten: Mails nur noch verschlüsselt

_mta-sts.beispiel.at     TXT  "v=STSv1; id=20261009T0800"
_smtp._tls.beispiel.at   TXT  "v=TLSRPTv1; rua=mailto:tls-berichte@beispiel.at"

# https://mta-sts.beispiel.at/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.beispiel.at
max_age: 604800

Zwei DNS-Einträge und eine Textdatei mit vier Zeilen. Mehr braucht MTA-STS nicht. Der TXT-Eintrag _mta-sts sagt einem sendenden Server: Für diese Domain gibt es eine Richtlinie. Die Datei sagt ihm, welche Mailserver gelten und ob er die Mail zurückhalten muss, wenn die Verbindung nicht verschlüsselt oder das Zertifikat nicht gültig ist. Der Eintrag _smtp._tls bestellt die Berichte dazu.

MTA-STS schützt die Strecke zwischen dem Server des Absenders und deinem Eingangsserver. Mit SPF, DKIM und DMARC hat es nichts zu tun: Die prüfen, ob eine Mail von dir stammt. MTA-STS prüft, ob unterwegs jemand mitlesen oder umleiten kann. Wer die drei noch nicht sauber hat, fängt dort an, in DMARC einrichten.

Warum STARTTLS allein nicht reicht#

Mailserver reden über SMTP miteinander, ursprünglich im Klartext. STARTTLS ist die Erweiterung, mit der beide Seiten mitten im Gespräch auf TLS umschalten. Der empfangende Server bietet sie in seiner Antwort auf EHLO an, der sendende nimmt das Angebot an oder nicht.

Genau dort liegt die Schwäche, und RFC 3207 benennt sie selbst: Ein Angreifer zwischen den Servern kann die Zeile 250 STARTTLS aus der Antwort löschen. Der Absender sieht kein Angebot, schickt die Mail im Klartext und hält das für normal. Dass er das darf, ist sogar Absicht: Ein öffentlich erreichbarer Mailserver darf STARTTLS laut demselben RFC nicht verlangen, sonst bliebe Post von Servern ohne TLS liegen.

Die zweite Lücke nennt RFC 8461 gleich in der Einleitung: Wer den MX-Eintrag der Zieldomain überschreiben oder die ganze Sitzung umleiten kann, landet mit seinem eigenen Server im Gespräch. STARTTLS allein legt nicht fest, dass der Absender ein gültiges Zertifikat für den richtigen Namen verlangen muss. Gegen passives Mitlesen ist das eine hohe Hürde, gegen einen aktiven Angreifer keine.

MTA-STS dreht diese Logik für deine Domain um: Wer deine Richtlinie kennt, stellt nur noch zu, wenn TLS klappt, das Zertifikat gültig ist und der Server in deiner Liste steht.

Die drei Teile im Einzelnen#

Die Felder der Datei, nach RFC 8461:

• mode hat drei Werte. enforce: Absender dürfen nur an Server zustellen, die in der Liste stehen, TLS anbieten und ein gültiges Zertifikat zeigen. testing: Absender stellen trotzdem zu, melden Fehler aber über TLS-RPT. none: als gäbe es keine Richtlinie, gedacht zum geordneten Abschalten.
• mx nennt jeden Mailserver in einer eigenen Zeile. Ein Stern gilt für genau eine Ebene: *.beispiel.at passt auf mail.beispiel.at, aber nicht auf beispiel.at und nicht auf a.mail.beispiel.at.
• max_age ist die Zeit in Sekunden, die ein Absender die Richtlinie zwischenspeichert, höchstens 31.557.600, also gut ein Jahr. Google empfiehlt für den Testbetrieb 604.800 bis 1.209.600 Sekunden, eine bis zwei Wochen.

Eine Schwäche hat das Verfahren, und der Standard verschweigt sie nicht: Schutz gibt es erst ab dem zweiten Kontakt. Wer die Richtlinie noch nie abgerufen hat, kann beim ersten Mal getäuscht werden. Deshalb ist ein langes max_age im Endbetrieb sinnvoll.

Einrichten in sechs Schritten#

1. MX-Server und Zertifikate prüfen. Bevor eine Richtlinie Mails zurückhalten darf, muss jeder Eingangsserver TLS mit einem gültigen Zertifikat für seinen eigenen Namen anbieten. Prüfen lässt sich das von einem Rechner, der ausgehend Port 25 erreicht (manche Anschlüsse sperren ihn):

dig +short MX beispiel.at
openssl s_client -starttls smtp -connect mail.beispiel.at:25 \
  -servername mail.beispiel.at -verify_return_error -brief </dev/null

Steht am Ende Verification: OK und passt der Name im Zertifikat zum MX-Eintrag, ist der Server bereit. Bei einem gemieteten Postfach ist das Sache des Anbieters, und die großen erfüllen es.

2. TLS-RPT zuerst. Der Eintrag _smtp._tls kostet nichts und ändert an der Zustellung nichts. Er sorgt nur dafür, dass Absender, die mitmachen, täglich melden, wie die Verbindungen zu deinen Servern gelaufen sind. Für die Berichte eine eigene Adresse nehmen, es werden viele.

3. Die Datei mit mode: testing anlegen. Für eigene Server stehen die eigenen MX-Namen in den mx-Zeilen. Für Microsoft 365 nennt Microsoft selbst die Zeile mx: *.mail.protection.outlook.com, ausdrücklich nur für Exchange Online und nicht als allgemeines Muster. Bei Google Workspace stehen die Google-MX-Namen der Domain darin, Google empfiehlt zwei Wochen testing.

4. Die Datei veröffentlichen. Sie braucht eine Subdomain mta-sts.<domain> mit eigenem gültigem Zertifikat, und unter /.well-known/mta-sts.txt muss die Datei direkt antworten, nicht über eine Weiterleitung. Microsoft betont, dass Exchange Online die Datei nicht für Kunden bereitstellt. Jeder Webspace, der eine Subdomain mit Let's-Encrypt-Zertifikat kann, reicht dafür. Ob alles stimmt:

curl -sS -D - https://mta-sts.beispiel.at/.well-known/mta-sts.txt

Erwartet wird HTTP/2 200, ein content-type: text/plain und die vier Zeilen. Ein 301 oder eine HTML-Seite heißt: Absender sehen keine Richtlinie.

5. Den TXT-Eintrag _mta-sts setzen. Erst jetzt, wenn die Datei abrufbar ist. Als id eignet sich ein Zeitstempel wie 20261009T0800, Microsoft schlägt dasselbe Muster vor.

6. Zwei Wochen Berichte lesen, dann enforce. Zeigen die TLS-Berichte keine Fehler für eigene Server, mode: enforce eintragen, max_age hochsetzen und die id im TXT-Eintrag ändern. Ohne neue id arbeiten Absender bis zum Ablauf von max_age mit der zwischengespeicherten Fassung weiter.

Ändern sich später die MX-Server, etwa beim Anbieterwechsel, kommt zuerst die Datei dran, mit neuer id, und erst danach der MX-Eintrag. Andersherum weisen Absender, die die alte Richtlinie kennen, deine Post an den neuen Server ab. Microsoft beschreibt für Störungen genau diesen Rückweg: auf testing stellen, id ändern, Fehler suchen.

Einen TLS-Bericht lesen#

Die Berichte sind JSON-Dateien, laut RFC 8460 je Tag von 00:00 bis 24:00 UTC und je meldendem Absender eine. Das Gerüst, gekürzt und mit Beispielwerten:

{
  "organization-name": "Beispiel-Mailanbieter",
  "date-range": { "start-datetime": "2026-10-10T00:00:00Z", "end-datetime": "2026-10-10T23:59:59Z" },
  "policies": [{
    "policy": { "policy-type": "sts", "policy-domain": "beispiel.at", "mx-host": ["mail.beispiel.at"] },
    "summary": { "total-successful-session-count": 212, "total-failure-session-count": 3 },
    "failure-details": [{ "result-type": "certificate-expired", "receiving-mx-hostname": "mail.beispiel.at", "failed-session-count": 3 }]
  }]
}

policy-type sagt, wonach geprüft wurde: sts für MTA-STS, tlsa für DANE, no-policy-found, wenn es keines von beiden gab. Bei den Fehlern kommen vor allem diese vor: starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, dazu die richtlinienbezogenen sts-policy-fetch-error (Datei nicht abrufbar), sts-policy-invalid und sts-webpki-invalid (Zertifikat der Richtlinien-Subdomain ungültig). Steht bei testing ein Fehler für einen eigenen Server, wäre genau diese Zahl an Mails bei enforce liegen geblieben.

DANE: dasselbe Ziel über DNSSEC#

DANE löst dasselbe Problem auf anderem Weg. Statt einer Datei im Web veröffentlicht der Betreiber des Mailservers im DNS einen TLSA-Eintrag, der das Zertifikat beschreibt, für mail.beispiel.at unter _25._tcp.mail.beispiel.at. Findet ein Absender einen gesicherten TLSA-Eintrag, muss er laut RFC 7672 TLS verwenden und das Zertifikat danach prüfen. Die übliche Form ist 3 1 1 mit dem SHA-256-Hash des öffentlichen Schlüssels.

Der Haken: DANE gilt nur mit DNSSEC, also signierten Zonen für die Domain und für den Mailserver. RFC 8461 fasst den Unterschied in einem Satz: DANE braucht DNSSEC, MTA-STS verlässt sich auf Zertifizierungsstellen und kommt ohne aus, um den Preis, dass der erste Abruf angreifbar ist. Beides gleichzeitig ist erlaubt.

Für Microsoft 365 ist das praktisch relevant. Exchange Online prüft beim Versand DANE und MTA-STS der Empfänger ohne jede Einstellung. Für den Empfang bietet Microsoft „Inbound SMTP DANE with DNSSEC“ an: Der MX-Eintrag zeigt danach auf einen neuen Namen unter mx.microsoft statt auf mail.protection.outlook.com, und die volle Wirkung gibt es nur, wenn die eigene Domain DNSSEC hat. Wer schon MTA-STS nutzt, muss die Richtlinie vor dem Umstieg auf testing stellen und den neuen MX-Namen aufnehmen, sonst bricht Microsofts Prüfung beim Einschalten mit einer Fehlermeldung ab.

BIMI in zwei Absätzen#

BIMI wird oft im selben Atemzug genannt, hat mit Verschlüsselung aber nichts zu tun. Es zeigt das Firmenlogo neben der Mail im Posteingang. Google verlangt dafür eine DMARC-Richtlinie mit p=quarantine oder p=reject, das Logo im Format SVG Tiny Portable/Secure und für das Häkchen in Gmail ein Markenzertifikat (VMC) oder ein Common Mark Certificate.

Für die meisten kleinen Betriebe ist BIMI deshalb der letzte Schritt, nicht der erste. Was es voraussetzt, eine wirksame DMARC-Richtlinie, bringt dagegen sofort Schutz. Wann die Umstellung passt, steht in DMARC-Policy: none, quarantine oder reject.

Messung: 146 Tiroler Domains#

In eigener Sache: Am 05.10.2026 um 08:12 UTC habe ich für dieselben 149 Tiroler Domains wie in den bisherigen Messungen, 34 Tourismusverbände und 115 Betriebe aus meiner Akquise-Liste, die Einträge _mta-sts und _smtp._tls abgefragt, dazu die MX-Einträge mit DNSSEC-Prüfbit und für jeden MX-Server den TLSA-Eintrag unter _25._tcp. Wo es einen MTA-STS-Eintrag gab, habe ich die Richtliniendatei per HTTPS abgerufen. Alles passiv über DNS-over-HTTPS bei Cloudflare, ohne Verbindung zu einem Mailserver. Drei Domains gibt es nicht mehr, bleiben 146.

• 1 Domain hat einen MTA-STS-Eintrag. Die Datei ist erreichbar und korrekt aufgebaut, steht aber auf mode: none, also ausdrücklich ohne Wirkung. Dieselbe Domain hat als einzige auch TLS-RPT.
• 0 Domains erzwingen TLS über MTA-STS.
• 4 Domains haben eine DNSSEC-signierte Zone. Zwei davon empfangen über Microsoft 365, wo DANE den Umstieg auf den neuen MX-Namen voraussetzt. Den nutzt keine der 66 Tiroler Domains, deren MX auf mail.protection.outlook.com zeigt.
• 3 Domains haben einen DNSSEC-gesicherten TLSA-Eintrag an ihren Mailservern, alle drei, weil der Dienst, der ihre Post annimmt, ihn für seine eigenen Server veröffentlicht. Nur bei einer ist auch die eigene Zone signiert, und auch dort tragen nur 2 der 6 MX-Server einen TLSA-Eintrag. Eine vierte Domain hat einen TLSA-Eintrag ohne DNSSEC, den kein Absender beachten darf.
• 141 von 146 haben nichts davon. Ihre Post wird verschlüsselt, wenn beide Server es anbieten, und im Klartext, wenn jemand das Angebot unterdrückt.

Namen veröffentliche ich nicht. Ob die eigene Domain SPF, DKIM und DMARC richtig gesetzt hat, zeigt der E-Mail-Check. MTA-STS und TLS-RPT prüft er bisher nicht, dafür reichen die Befehle oben.

Was nicht hilft#

Gleich mit mode: enforce anfangen. Ein vergessener Ersatz-MX oder ein abgelaufenes Zertifikat, und Absender, die mitmachen, halten deine Post zurück. Ohne TLS-RPT erfährst du nicht einmal, warum.

Die Datei per Weiterleitung ausliefern, etwa weil mta-sts.<domain> auf die Hauptseite umleitet. RFC 8461 verbietet Absendern, Weiterleitungen zu folgen. Die Richtlinie existiert dann für niemanden.

Die Datei ändern und die id vergessen. Absender arbeiten mit der zwischengespeicherten Fassung weiter, bis max_age abläuft, bei einem Jahr ein Jahr lang.

Einen TLSA-Eintrag ohne DNSSEC setzen. Ohne Signatur ist er für Absender wertlos.

MTA-STS für ein Mittel gegen Spoofing halten. Gegen gefälschte Absender helfen SPF, DKIM und DMARC, siehe E-Mail-Spoofing.

Häufige Fragen#

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. MTA-STS ist der Schritt nach SPF, DKIM und DMARC. Die drei bringt das Paket E-Mail-Schutz beim bestehenden Anbieter in Ordnung, und wo SPF, DKIM und DMARC heute stehen, zeigt kostenlos der E-Mail-Check.

Stand 05.10.2026. Quellen an diesem Tag abgerufen, DNS-Messung am 05.10.2026.