Inhaltsverzeichnis
  1. Die kurze Antwort
  2. Warum STARTTLS allein nicht reicht
  3. Wie MTA-STS aufgebaut ist
  4. Die Reihenfolge, die euch vor Ausfall schützt
  5. TLS-RPT: der Teil, der euch überhaupt erst informiert
  6. So prüft ihr eure eigene Einrichtung
  7. Was in der Praxis schiefgeht
  8. Lohnt sich das für euch

SPF, DKIM und DMARC klären eine einzige Frage: Ist der Absender echt? Über den Weg, den die Mail nimmt, sagen sie nichts. Sie kann verschlüsselt gelaufen sein oder im Klartext, und ihr würdet den Unterschied nie erfahren.

Für diese zweite Frage gibt es zwei weitere DNS-Einträge. Sie sind Kür, nicht Pflicht, und sie sind erst sinnvoll, wenn die ersten drei stehen. Aber sie schließen eine Lücke, die viele gar nicht kennen.

Die kurze Antwort

MTA-STS erzwingt, dass eingehende Mail verschlüsselt zu euch kommt. TLS-RPT sorgt dafür, dass ihr es erfahrt, wenn das nicht klappt. Beide sind TXT-Einträge im DNS, MTA-STS braucht zusätzlich eine kleine Datei auf einem Webserver.

Warum STARTTLS allein nicht reicht

Zwischen zwei Mailservern läuft die Verschlüsselung heute über STARTTLS. Der empfangende Server sagt beim Verbindungsaufbau sinngemäß „ich kann verschlüsseln“, der sendende nimmt das Angebot an, und ab da ist die Verbindung dicht.

Das Verfahren hat einen Konstruktionsfehler: Es ist freiwillig, und das Angebot steht unverschlüsselt im Klartext. Wer sich zwischen die beiden Server setzt, streicht die Zeile mit dem Angebot einfach heraus. Der Sender sieht dann einen Empfänger, der angeblich kein TLS kann, und schickt die Mail im Klartext. Niemand bekommt eine Fehlermeldung, denn aus Sicht beider Seiten lief alles normal.

Diese Masche heißt STARTTLS-Stripping. Sie ist der Grund, warum es MTA-STS gibt: Der Sender soll vorher wissen, dass ihr TLS könnt, und zwar aus einer Quelle, die sich unterwegs nicht manipulieren lässt.

Wie MTA-STS aufgebaut ist

MTA-STS besteht aus zwei Teilen, die zusammenpassen müssen. Fehlt einer, wirkt gar nichts.

Erstens ein TXT-Eintrag unter _mta-sts.firma.de:

v=STSv1; id=202608141200

Die id ist eine frei gewählte Kennung, üblich ist ein Zeitstempel. Sie ist das Signal für alle Sender: Ändert sie sich, holen sie die Regeln neu. Wer die Regeln bearbeitet und die id stehen lässt, ändert für Wochen nichts, weil alle mit der zwischengespeicherten Fassung weiterarbeiten.

Zweitens eine Datei, erreichbar unter genau dieser Adresse:

https://mta-sts.firma.de/.well-known/mta-sts.txt

Mit diesem Inhalt:

version: STSv1
mode: testing
mx: mx01.provider.de
mx: mx02.provider.de
max_age: 86400

Die mx-Zeilen müssen alle Server aufführen, die für euch Mail annehmen, also genau das, was auch in euren MX-Einträgen steht. Ein Sternchen ist erlaubt (mx: *.provider.de), aber nur für eine Ebene.

Die Reihenfolge, die euch vor Ausfall schützt

mode kennt drei Werte, und die Reihenfolge ist keine Empfehlung, sondern Selbstschutz:

WertWas passiert
testingVerstöße werden gemeldet, die Mail kommt trotzdem an
enforcePasst der Server nicht oder fehlt TLS, wird nicht zugestellt
noneAbschalten, ohne die Datei zu löschen

Startet mit testing und einem kurzen max_age. Steht ein MX nicht in der Liste oder stimmt ein Zertifikat nicht, seht ihr das in den Berichten, statt es an ausbleibender Mail zu merken. Erst wenn über einige Wochen nichts auffällt, geht es auf enforce, und dann darf max_age auch länger werden.

Das ist dieselbe Logik wie bei DMARC, wo man von p=none über p=quarantine nach p=reject geht. Wer sie abkürzt, verliert Mail. Ausführlich steht der Weg in SPF, DKIM und DMARC: was die drei wirklich tun.

TLS-RPT: der Teil, der euch überhaupt erst informiert

MTA-STS allein macht euch blind streng. TLS-RPT ist die Gegenrichtung: ein einzelner TXT-Eintrag unter _smtp._tls.firma.de:

v=TLSRPTv1; rua=mailto:tls@firma.de

Damit schicken euch Google, Microsoft und die anderen großen Versender täglich eine maschinenlesbare Zusammenfassung: Wie viele Verbindungen kamen zustande, wie viele scheiterten, und woran. Das ist die einzige Möglichkeit zu erfahren, dass jemand euch keine Mail mehr zustellen kann.

Ohne TLS-RPT ist mode: enforce ein Blindflug. Deshalb gehören die beiden zusammen, auch wenn sie technisch unabhängig sind.

So prüft ihr eure eigene Einrichtung

Drei Handgriffe, alle ohne zusätzliches Werkzeug.

Der TXT-Eintrag:

nslookup -type=TXT _mta-sts.firma.de

Kommt hier nichts zurück, ist alles Weitere egal. Sender fragen zuerst an dieser Stelle nach und gehen ohne Antwort ihren gewohnten Weg, ganz gleich, was auf eurem Webserver liegt.

Die Regeldatei:

curl -v https://mta-sts.firma.de/.well-known/mta-sts.txt

Wichtig ist nicht nur der Inhalt, sondern die Zeile zum Zertifikat. Wenn curl an dieser Stelle meckert, tun es die Mailserver auch, nur ohne dass es jemand mitbekommt.

Die MX-Liste gegenprüfen:

nslookup -type=MX firma.de

Jeder Server aus dieser Antwort muss in der Regeldatei stehen. Genau hier fällt bei enforce die Post aus, und genau hier ändert sich etwas, sobald jemand einen Spamfilter vorschaltet oder den Anbieter wechselt.

Bei einem Anbieterwechsel gehören deshalb beide Stellen auf die Umzugsliste, die MX-Einträge und die Regeldatei. Wer nur die MX ändert, sperrt seine eigene Post aus.

Was in der Praxis schiefgeht

Vier Fehler sehen wir immer wieder:

  1. Das Zertifikat der Subdomain. Die Datei muss über HTTPS mit einem gültigen Zertifikat für mta-sts.firma.de ausgeliefert werden. Ein abgelaufenes oder auf die Hauptdomain ausgestelltes Zertifikat macht die ganze Konstruktion wirkungslos, und zwar still.
  2. Die id bleibt stehen. Regeln geändert, Kennung vergessen: Für alle Sender hat sich nichts geändert.
  3. Die MX-Liste ist unvollständig. Backup-Server und Spamfilter-Vorschaltungen werden gern übersehen. Bei enforce fällt genau deren Post aus.
  4. max_age steht zu hoch, während noch getestet wird. Der Wert sagt Sendern, wie lange sie die Regeln zwischenspeichern dürfen. Wer beim Ausprobieren ein Jahr einträgt, kann einen Fehler nicht mehr schnell zurücknehmen.

Die Spezifikationen sind kurz und frei lesbar: RFC 8461 beschreibt MTA-STS, RFC 8460 TLS-RPT.

Lohnt sich das für euch

Ehrliche Antwort: erst danach. Wer noch kein DMARC hat oder es auf p=none stehen lässt, holt mit denselben zwei Stunden Arbeit an anderer Stelle deutlich mehr heraus. MTA-STS schützt gegen einen Angreifer, der bereits zwischen zwei Mailservern sitzt. Absenderfälschung dagegen kostet niemanden mehr als eine Minute.

Und wenn eure Domain gar keine Mail empfängt, ist das Thema für euch erledigt, denn MTA-STS regelt ausschließlich den eingehenden Weg.

Wo ihr steht, zeigt der kostenlose DMARC-Check: Er prüft neben SPF, DKIM und DMARC auch, ob MTA-STS und TLS-RPT hinterlegt sind, und sagt dazu, ob sie bei euch überhaupt eine Rolle spielen.

Wenn es jemand einrichten soll: Wir machen das in der richtigen Reihenfolge, mit testing vorweg, und behalten die Berichte bei laufender Wartung im Blick. Erstgespräch vereinbaren, 30 Minuten, kostenlos.