MTA-STS

Dieser Leitfaden ist Teil unseres Leitfadens zur E-Mail-Authentifizierung. Verwandt: BIMI und DKIM vs DMARC.

MTA-STS (SMTP MTA Strict Transport Security) ist ein Standard, mit dem eine Domain verlangen kann, dass eingehende Post über verschlüsseltes, authentifiziertes TLS zugestellt wird, und der so Downgrade- und Man-in-the-Middle-Angriffe verhindert. TLS-RPT ist der begleitende Reporting-Standard, der tägliche Reports über TLS-Fehler bei der Zustellung sammelt. MTA-STS schützt die Transportschicht und ergänzt SPF, DKIM und DMARC, die den Absender statt der Verbindung authentifizieren.

Das Problem, das MTA-STS löst

Wenn zwei Mailserver Nachrichten über SMTP austauschen, handeln sie die Verschlüsselung normalerweise per STARTTLS aus. Der Haken ist, dass STARTTLS opportunistisch ist: Der sendende Server fragt, ob der Empfänger TLS unterstützt, und wenn die Antwort Nein lautet, fällt er stillschweigend auf Klartext zurück. Diese Frage und Antwort geschehen unverschlüsselt, was bedeutet, dass ein Angreifer, der zwischen den beiden Servern positioniert ist, den STARTTLS-Befehl aus der Konversation entfernen kann. Der sendende Server glaubt dann, der Empfänger habe keine TLS-Unterstützung, und stellt die Nachricht unverschlüsselt zu oder verbindet sich mit einem Betrügerserver, der ein gefälschtes Zertifikat vorweist.

Diese werden als Downgrade- und Man-in-the-Middle-Angriffe bezeichnet. Da SMTP zuerst für Interoperabilität und erst später für Sicherheit entworfen wurde, gab es historisch keine Möglichkeit für eine empfangende Domain zu sagen: „Verschlüssle Post an mich immer und weigere dich, sie zuzustellen, wenn du es nicht kannst.” MTA-STS füllt genau diese Lücke. Es lässt eine Domain eine Richtlinie veröffentlichen, die erklärt, dass eingehende Post über TLS zugestellt werden muss, unter Verwendung eines gültigen Zertifikats, das zu einem ihrer veröffentlichten MX-Hosts passt. Sendende Server, die MTA-STS unterstützen, respektieren die Richtlinie und stellen eine Nachricht zurück oder senden einen Bounce, anstatt sie im Klartext zu versenden.

Wie MTA-STS funktioniert

MTA-STS beruht auf zwei zusammenwirkenden Bestandteilen: einem DNS-TXT-Record, der die Richtlinie ankündigt, und einer über HTTPS gehosteten Richtliniendatei, die sie definiert.

Veröffentlichen Sie zunächst einen TXT-Record unter _mta-sts.yourdomain.com. Dieser Record signalisiert, dass eine Richtlinie existiert, und trägt eine ID, die sich immer dann ändert, wenn Sie die Richtlinie aktualisieren, sodass sendende Server wissen, wann sie sie erneut abrufen müssen.

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260910T120000;"

Zweitens stellen Sie die Richtliniendatei über HTTPS an einem festen, bekannten Ort bereit: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Die HTTPS-Anforderung ist wichtig, weil das Zertifikat auf diesem Host belegt, dass die Richtlinie authentisch ist und während der Übertragung nicht manipuliert wurde.

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

Die mx-Zeilen listen jeden Hostnamen auf, der Ihre Post empfangen darf, passend zu Ihren MX-Records. max_age teilt sendenden Servern mit, wie lange sie die Richtlinie zwischenspeichern sollen, in Sekunden (604800 ist eine Woche). Ein längerer Cache ist widerstandsfähiger gegen einen Angreifer, der DNS kurzzeitig manipulieren kann, daher wird ein Wert von mindestens einigen Tagen empfohlen, sobald Sie Ihrer Einrichtung vertrauen.

Enforce- vs. Testing-Modus

Das Feld mode in der Richtliniendatei steuert, wie streng die Richtlinie angewendet wird, und es ist der wichtigste Regler bei der Einführung von MTA-STS.

Beginnen Sie mit mode: testing. Im Testing-Modus werten sendende Server Ihre Richtlinie aus, blockieren die Zustellung aber niemals, wenn sie fehlschlägt. Stattdessen melden sie Fehler in Kombination mit dem unten genannten TLS-RPT an Sie zurück. So können Sie fehlkonfigurierte MX-Hosts, abgelaufene Zertifikate oder Hostnamen-Diskrepanzen entdecken, ohne jemals eine legitime Nachricht zu verlieren.

Sobald Ihre Reports ein bis zwei Wochen lang sauber zurückkommen, wechseln Sie zu mode: enforce. Nun weigern sich sendende Server, Post zuzustellen, die nicht über authentifiziertes TLS an einen gelisteten MX-Host gesendet werden kann. Ein dritter Wert, mode: none, deaktiviert die Richtlinie praktisch und wird verwendet, um MTA-STS geordnet außer Betrieb zu nehmen. Wechseln Sie stets bewusst von testing zu enforce, niemals überstürzt umgekehrt.

TLS-RPT: Reporting

MTA-STS allein sagt Ihnen nichts darüber, wie die Zustellung verläuft. TLS-RPT (SMTP TLS Reporting) ist der Rückkanal. Sie veröffentlichen einen zweiten TXT-Record unter _smtp._tls.yourdomain.com, der eine Adresse benennt, die aggregierte Reports erhalten soll.

_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

Teilnehmende sendende Server senden Ihnen einen täglichen JSON-Report, der erfolgreiche und fehlgeschlagene TLS-Sitzungen zu Ihrer Domain zusammenfasst, einschließlich des Grundes für jeden Fehler, etwa ein Zertifikat, das nicht validierte, oder eine STARTTLS-Aushandlung, die entfernt wurde. Diese Reports machen den Testing-Modus nützlich, und sie bleiben im Enforce-Modus als Frühwarnsystem für Zertifikatsablauf oder MX-Änderungen wertvoll. Viele Teams leiten die rua-Adresse eher in ein Monitoring-Dashboard als in einen menschlichen Posteingang.

Wo es sich neben SPF, DKIM und DMARC einordnet

Es ist leicht, MTA-STS mit den anderen Abkürzungen in einen Topf zu werfen, aber es löst ein anderes Problem. SPF, DKIM und DMARC authentifizieren den Absender und beantworten die Frage „Stammt diese Nachricht wirklich von der Domain, die sie vorgibt?” MTA-STS sichert die Verbindung und beantwortet die Frage „Wird diese Nachricht vertraulich und an den richtigen Server zugestellt?” Sie wollen beides. Eine Nachricht kann perfekt authentifiziert und dennoch während der Übertragung abgefangen werden, und eine perfekt verschlüsselte Verbindung kann trotzdem eine gefälschte Nachricht transportieren.

Für das vollständige Bild der Absenderauthentifizierung siehe unseren Leitfaden zur E-Mail-Authentifizierung. MTA-STS passt als Ergänzung auf der Transportschicht natürlich zu diesen Standards, und sobald Sie sie eingerichtet haben, ist BIMI eine weitere fortgeschrittene Schicht, die eine Überlegung wert ist, da sie es Ihnen ermöglicht, ein verifiziertes Markenlogo in unterstützenden Postfächern anzuzeigen.

Häufig gestellte Fragen

Was ist MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security) ist ein Standard, mit dem eine Domain verlangen kann, dass eingehende E-Mails über verschlüsseltes, authentifiziertes TLS zugestellt werden. Es veröffentlicht einen DNS-Record und eine über HTTPS gehostete Richtliniendatei, sodass sendende Server die Verschlüsselung durchsetzen und sich weigern, auf Klartext zurückzufallen, was Downgrade- und Man-in-the-Middle-Angriffe gegen SMTP blockiert.

Was ist der Unterschied zwischen MTA-STS und TLS-RPT?

MTA-STS ist der Durchsetzungsstandard: Er definiert die Richtlinie, die TLS-Zustellung verlangt. TLS-RPT ist der Reporting-Standard: Er definiert einen DNS-Record und ein JSON-Report-Format, sodass sendende Server Ihnen tägliche Zusammenfassungen über Erfolge und Fehler bei der TLS-Zustellung senden. Sie setzen sie gemeinsam ein und nutzen TLS-RPT, um eine MTA-STS-Richtlinie sicher zu validieren, bevor Sie sie durchsetzen.

Ist MTA-STS erforderlich?

Nein, MTA-STS ist nicht obligatorisch, und E-Mail funktioniert auch ohne. Für jede Domain, die sensible Post verarbeitet, wird es jedoch dringend empfohlen, da es eine reale Lücke schließt, die SPF, DKIM und DMARC nicht adressieren. Es zunächst im Testing-Modus einzusetzen birgt kein Zustellungsrisiko, sodass es kaum einen Grund gibt, es nicht zu übernehmen.

Ersetzt MTA-STS SPF, DKIM oder DMARC?

Nein. MTA-STS arbeitet auf einer anderen Schicht. SPF, DKIM und DMARC authentifizieren den Absender und erkennen Spoofing, während MTA-STS die Transportverbindung sichert, damit Post vertraulich an den korrekten Server zugestellt wird. Sie sind sich ergänzende Kontrollen, und eine gut geschützte Domain setzt sie alle gemeinsam ein, statt eine gegenüber einer anderen zu wählen.