MTA-STS und TLS-RPT sicher einrichten

MTA-STS und TLS-RPT für die E-Mail-Sicherheit einrichten

MTA-STS ermöglicht es einer Empfängerdomain, sendenden Mailservern mitzuteilen, welche Mailserver ihre Nachrichten annehmen sollen und dass diese Verbindungen TLS mit vertrauenswürdigen Zertifikaten verwenden müssen. TLS-RPT ergänzt eine Berichtsfunktion: Teilnehmende Absender können Ihnen Informationen über fehlgeschlagene TLS-Zustellungen und Richtlinienprobleme senden. Wenn Sie sich fragen: „Wie richte ich MTA-STS und TLS-RPT ein?“, beginnen Sie mit der Konfiguration Ihres eingehenden E-Mail-Verkehrs – nicht mit einem DNS-Eintrag.

Diese Maßnahmen ersetzen SPF, DKIM oder DMARC nicht. Sie betreffen einen anderen Abschnitt des Übertragungswegs: die verschlüsselte Verbindung zwischen Mailservern. Eine Richtlinie, die einen veralteten oder falsch konfigurierten MX-Host aufführt, kann die Zustellung beeinträchtigen. Testen Sie daher die gesamte Konfiguration, bevor Sie die Richtlinie durchsetzen.

1. Prüfen, ob Ihr Mailhosting bereit ist

Beginnen Sie mit den aktuellen MX-Einträgen Ihrer Domain. Notieren Sie alle Hostnamen, auf die sie verweisen, einschließlich der Hosts für Ausweich- oder regionale Zustellungen. Wenn Ihr Anbieter den eingehenden E-Mail-Verkehr verwaltet, lassen Sie sich bestätigen, welche MX-Namen in eine MTA-STS-Richtlinie gehören und ob jeder davon TLS mit einem gültigen Zertifikat unterstützt.

Prüfen Sie die Hostnamen, nicht nur den Namen des Anbieters. Eine Domain kann MX-Einträge wie mx1.mail.example.com und mx2.mail.example.com haben, während der Anbieter weitere Hosts betreibt, die für Ihre Domain nicht aufgeführt sind. Ihre Richtlinie sollte alle MX-Hostnamen abdecken, die E-Mails für die Domain annehmen können.

Prüfen Sie das Zertifikat und die TLS-Konfiguration jedes aufgeführten Hosts. Das Zertifikat muss vertrauenswürdig und für den MX-Hostnamen gültig sein, mit dem sich der sendende Mailserver verbindet. Ein Zertifikat, das zwar die Website des Anbieters, nicht aber dessen Mailhost abdeckt, ist kein geeigneter Ersatz.

Fragen Sie Ihren Mailanbieter auch nach geplanten Hoständerungen. Wenn sich während der Einrichtung ein MX-Hostname ändern soll, warten Sie, bis die endgültige Liste feststeht, oder stimmen Sie die Aktualisierung der Richtlinie mit dem Anbieter ab. Ein nicht aufgeführter Ersatzhost kann Zustellungsprobleme verursachen, sobald ein Absender eine Richtlinie im Durchsetzungsmodus zwischengespeichert hat.

2. Ein Ziel für TLS-RPT-Berichte veröffentlichen

Legen Sie vor der Veröffentlichung des DNS-Eintrags fest, wohin die Berichte gesendet werden sollen. Sie können dafür ein Postfach verwenden, das Berichte annimmt, oder einen TLS-Berichtsdienst, der Ihnen eine E-Mail-Adresse oder ein HTTPS-Ziel bereitstellt. Vergewissern Sie sich, dass das Ziel überwacht wird und Ihr Mailsystem dort eingehende Berichte annimmt.

Veröffentlichen Sie einen TXT-Eintrag unter _smtp._tls.example.com und ersetzen Sie example.com durch Ihre Domain. Für ein E-Mail-Ziel verwenden Sie folgendes Format: v=TLSRPTv1; rua=mailto:tls-reports@example.com. Wenn Ihr Berichtsdienst ein anderes Ziel bereitstellt, verwenden Sie genau den URI, den er angibt. So lässt sich der TLS-RPT DNS-Eintrag konfigurieren, damit teilnehmende Absender wissen, wohin sie Berichte senden können.

Verwenden Sie nach Möglichkeit ein separates Postfach statt des alltäglichen persönlichen Posteingangs. TLS-Berichte können als strukturierte Anhänge eingehen. Ein eigenes Postfach erleichtert es, Zugriffsregeln festzulegen, Nachrichten aufzubewahren und die Prüfung an die für die E-Mail-Zustellung zuständige Administration weiterzuleiten. Prüfen Sie vor der Veröffentlichung des Eintrags die Speicher- und Filtereinstellungen.

Es kann eine Weile dauern, bis DNS-Änderungen überall sichtbar sind, da Resolver Einträge entsprechend ihrer TTL zwischenspeichern. Fragen Sie nach der Veröffentlichung des Eintrags sowohl den autoritativen DNS-Dienst als auch einen öffentlichen Resolver ab und prüfen Sie, ob beide den gewünschten TXT-Wert zurückgeben. Ein Tippfehler im Eintragsnamen kann dazu führen, dass Absender das Ziel nicht finden.

3. Die MTA-STS-Richtliniendatei bereitstellen

Legen Sie die Richtliniendatei unter https://mta-sts.example.com/.well-known/mta-sts.txt ab und ersetzen Sie example.com durch Ihre eigene Domain. Der Endpunkt muss über HTTPS erreichbar sein, und sein Zertifikat muss für den Hostnamen mta-sts.example.com gültig sein. Eine Datei im üblichen Homepage-Pfad der Website erfüllt diese Anforderung nicht.

Die Richtliniendatei ist eine einfache Textdatei. Verwenden Sie für einen ersten Test beispielsweise folgende Felder:

• version: STSv1
• mode: testing
• mx: mx1.mail.example.com
• mx: mx2.mail.example.com
• max_age: 86400

Ersetzen Sie die Beispiel-MX-Namen durch die tatsächlichen Hosts, die eingehende E-Mails für Ihre Domain annehmen. Der Wert max_age gibt an, wie viele Sekunden ein Absender die Richtlinie zwischenspeichern darf; das Beispiel oben entspricht einem Tag. Eine kürzere Anfangsdauer kann die Überarbeitung einer Testrichtlinie erleichtern, während eine längere Dauer bedeutet, dass Absender die Richtlinie länger speichern können.

Verwenden Sie zunächst testing, bevor Sie die Richtlinie durchsetzen. In diesem Modus können Absender Richtlinienverstöße melden, ohne die Richtlinie als Aufforderung zu behandeln, E-Mails abzulehnen, die sich nicht unter den vorgeschriebenen TLS-Bedingungen zustellen lassen. Rufen Sie die URL von außerhalb Ihres Netzwerks auf und prüfen Sie, ob die Datei ohne Anmeldung, Weiterleitungsschleife oder Fehler der Webanwendung bereitgestellt wird.

4. Den MTA-STS-Erkennungseintrag veröffentlichen

Absender finden die Richtlinie über einen TXT-Eintrag unter _mta-sts.example.com. Sein Wert enthält die Version und eine Kennung für die Richtlinie, zum Beispiel: v=STSv1; id=20261104a. Wählen Sie eine Kennung, die Sie in Ihrem Änderungsprotokoll nachverfolgen können, statt einen alten Wert wiederzuverwenden.

Ändern Sie die Kennung jedes Mal, wenn Sie eine überarbeitete Richtliniendatei veröffentlichen. So erfahren sendende Systeme, dass sie die aktualisierte Richtlinie abrufen sollten, statt sich nur auf eine zwischengespeicherte Kopie zu verlassen. Die Kennung dient der Erkennung; sie ersetzt weder die Richtliniendatei noch deren HTTPS-Bereitstellung.

Veröffentlichen Sie den Eintrag erst, nachdem die Richtliniendatei unter der vorgeschriebenen URL erreichbar ist. Fragen Sie anschließend den TXT-Eintrag ab und rufen Sie die URL über eine externe Verbindung auf. DNS-Eintrag und Datei müssen dieselbe aktuelle Konfiguration beschreiben: Eine neue Kennung, die auf eine fehlende oder veraltete Datei verweist, macht die Bereitstellung nicht funktionsfähig.

5. Erkennung, Richtlinie und MX-Abdeckung prüfen

Prüfen Sie jede Ebene separat. Fragen Sie die TXT-Einträge _smtp._tls und _mta-sts ab, rufen Sie die Richtlinien-URL über HTTPS auf und vergleichen Sie jede Zeile mit mx: mit Ihren aktuellen MX-Einträgen. Diese dreiteilige Prüfung deckt Fehler auf, die eine reine DNS-Abfrage nicht erkennen kann.

Vergewissern Sie sich, dass die HTTPS-Antwort ein vertrauenswürdiges Zertifikat für den MTA-STS-Hostnamen verwendet und die Datei die erwarteten Felder enthält. Prüfen Sie dann jeden MX-Host auf TLS-Unterstützung und ein Zertifikat, das für genau diesen Host gültig ist. Wenn Ihr Anbieter mehrere eingehende MX-Namen betreibt, testen Sie jeden einzelnen, statt von einer identischen Zertifikatkonfiguration auszugehen.

Dokumentieren Sie die Ergebnisse, einschließlich der DNS-Werte, der Kennung der Richtlinie, der MX-Hostnamen und des Prüfdatums. Das liefert der nächsten zuständigen Person eine hilfreiche Ausgangsbasis, falls Berichte später auf einen Fehler hinweisen. Weitere Informationen zur E-Mail-Konfiguration finden Sie im RSS-Feed des YourTrend-Blogs, den Sie in die Referenzliste Ihres Teams aufnehmen können.

6. Berichte prüfen, bevor Sie die Richtlinie durchsetzen

Lassen Sie die Richtlinie im Testmodus, während Sie TLS-RPT-Rückmeldungen sammeln und den normalen E-Mail-Verkehr überprüfen. Berichte können auf sendende Systeme hinweisen, bei denen ein Zertifikatsproblem, ein TLS-Aushandlungsfehler oder eine Abweichung zwischen den bekannt gegebenen MX-Hosts und der Richtlinie aufgetreten ist. Ein Bericht ist ein Anlass zur Untersuchung, keine automatische Aufforderung, einen DNS-Eintrag zu ändern.

Prüfen Sie den Berichtszeitraum, die betroffene Richtliniendomain und die Angaben zum empfangenden Host. Vergleichen Sie diese mit Ihrer MX-Übersicht und der Konfiguration Ihres Anbieters. Fehlt ein legitimer Host, aktualisieren Sie die Richtliniendatei und ändern Sie die Kennung der Richtlinie. Ist ein Zertifikat fehlerhaft, lassen Sie den Anbieter das Problem beheben, bevor Sie die Richtlinie durchsetzen.

Testen Sie auch die Zustellung von den Mailservern, auf die Ihre Organisation angewiesen ist, zum Beispiel von einem Geschäftspartner oder einem separaten Dienst, den Sie selbst kontrollieren. Vergewissern Sie sich, dass die Nachrichten ankommen und Ihre Eingangsprotokolle erfolgreiche TLS-Verbindungen ausweisen. Ein leeres Berichts-Postfach allein beweist nicht, dass jeder Absender Ihre Richtlinie getestet hat.

Legen Sie einen Prüfzeitraum fest, der Ihrem E-Mail-Aufkommen und Ihren betrieblichen Anforderungen entspricht. Es gibt keine allgemein gültige Anzahl von Tagen, nach der garantiert alle sendenden Systeme in den Berichten auftauchen. Betrachten Sie daher einen bestimmten Zeitraum nicht als Nachweis für eine vollständige Abdeckung. Dokumentieren Sie, was Sie geprüft haben und welche bekannten Absender während des Tests erfolgreich zugestellt haben.

7. Die Konfiguration durchsetzen, überwachen und pflegen

Wenn MX-Liste, Zertifikate, HTTPS-Richtlinie und Testergebnisse bereit sind, ändern Sie den Richtlinienmodus von testing zu enforce. Veröffentlichen Sie die geänderte Richtliniendatei und eine neue Kennung für _mta-sts. Prüfen Sie nach der Aktualisierung beides von außerhalb Ihres Netzwerks und kontrollieren Sie anschließend weiterhin die TLS-RPT-Berichte und die E-Mail-Verkehrsprotokolle.

Im Durchsetzungsmodus wird von einem sendenden System, das MTA-STS unterstützt, erwartet, TLS zu verwenden und den empfangenden Host gemäß der Richtlinie zu überprüfen. Ist das nicht möglich, kann sich die Zustellung verzögern, während der Absender weitere Zustellversuche unternimmt, statt die Nachricht über eine ungeschützte Verbindung zu senden. Stimmen Sie die Änderung mit Ihrem Mailanbieter und dem Supportteam ab, damit diese wissen, wie eine verzögerte Zustellung zu diagnostizieren ist.

Dokumentieren Sie die Wartungsschritte zusammen mit der Richtlinien-URL und den DNS-Einträgen. Ändert sich ein MX-Host, aktualisieren Sie die Richtlinie, bevor Sie sich auf den neuen Host verlassen. Wird ein Zertifikat erneuert, prüfen Sie, für welche Hostnamen es gültig ist und ob die Vertrauenskette korrekt ist. Falls der Durchsetzungsmodus ein Problem offenlegt, können Sie die Auswirkungen der Richtlinie verringern, indem Sie wieder in den Testmodus wechseln. Aktualisieren Sie dabei die Kennung der Richtlinie und prüfen Sie, ob die überarbeitete Datei korrekt bereitgestellt wird.

Bestimmen Sie eine zuständige Person, die das Berichts-Postfach oder den Berichtsdienst prüft und DNS- sowie Zertifikatsänderungen nachverfolgt. Wenn Sie betriebliche Hinweise oder Aktualisierungen zu Maildiensten für Ihre Kolleginnen und Kollegen veröffentlichen, können diese auch den Blog-Feed von YourTrend abonnieren. Eine klar benannte Zuständigkeit und ein dokumentiertes Verfahren für MX-Änderungen erleichtern die nächste Zertifikatserneuerung oder den Wechsel des Anbieters.

Wer die praktische Anleitung sucht, um eine MTA-STS Richtlinie für eine Domain erstellen zu können, sollte die Richtliniendatei zuerst im Testmodus mit allen tatsächlichen MX-Hosts bereitstellen und erst nach erfolgreicher Prüfung auf „enforce“ umstellen.