MTA-STS, TLS-RPT und BIMI: Die nächsten Schritte nach DMARC

MTA-STS: verschlüsselt zustellen oder gar nicht

Mailserver verschlüsseln per STARTTLS, wenn beide Seiten es können, fallen aber auf Klartext zurück, wenn das Angebot fehlt — und ein Angreifer auf dem Weg kann es entfernen. MTA-STS (RFC 8461) veröffentlicht ein Versprechen: „Meine MX-Hosts haben immer gültige Zertifikate; stelle nicht ohne TLS zu.“ Dafür braucht es einen DNS-Eintrag und eine kleine Textdatei auf einem Webserver:

; announces the policy; change id whenever the policy file changes
_mta-sts.example.com.  3600 IN TXT   "v=STSv1; id=20261013T1200"
; the web host that serves the policy file over HTTPS
mta-sts.example.com.   3600 IN CNAME static-host.example.

# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800

• mode: testing meldet Fehler, stellt aber weiter zu; enforce verweigert die Zustellung ohne gültiges TLS; none zieht die Richtlinie zurück.
• mx: eine Zeile pro MX-Host, genau wie in deinen MX-Einträgen. Ein führendes *. passt auf ein Label — für Anbieter mit vielen Hosts.
• max_age: wie lange Absender die Richtlinie zwischenspeichern, in Sekunden. Eine Woche (604800) während des Tests; mehrere Monate, wenn alles stabil ist.

1. Besorge ein gültiges Zertifikat für mta-sts.example.com und stelle die Datei unter /.well-known/mta-sts.txt bereit — jedes statische Hosting genügt.
2. Veröffentliche _mta-sts mit einer neuen id (ein Zeitstempel ist praktisch).
3. Füge den TLS-RPT-Eintrag aus dem nächsten Abschnitt hinzu und laufe zwei bis vier Wochen im Modus testing.
4. Sind die Berichte sauber, stelle mode auf enforce und aktualisiere die id.

TLS-RPT: Berichte über gescheiterte Verschlüsselung

TLS-RPT (RFC 8460) bittet sendende Server, dir täglich eine Zusammenfassung ihrer TLS-Verbindungen zu deinen Mailservern zu schicken: wie viele gelangen und warum die übrigen scheiterten — abgelaufenes Zertifikat, falscher Name, fehlendes STARTTLS, Fehler beim Abruf der Richtlinie.

_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Google, Microsoft und andere große Anbieter schicken diese Berichte als JSON-Dateien. Der Eintrag allein ändert nichts an der Zustellung, du kannst ihn also gefahrlos zuerst veröffentlichen. Mit MTA-STS im Modus testing erfährst du daraus, ob enforce etwas kaputt machen würde.

BIMI: dein Logo im Posteingang

BIMI (Brand Indicators for Message Identification) lässt unterstützende Postfächer dein Logo statt eines Anfangsbuchstabens neben Nachrichten zeigen, die DMARC bestehen. Der Eintrag verweist auf das Logo und meist auf ein Zertifikat, das belegt, dass du es nutzen darfst:

default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"

• DMARC muss durchgesetzt sein: p=quarantine oder p=reject für die Domain, ohne pct unter 100 und ohne sp=none.
• Das Logo ist ein quadratisches SVG im eingeschränkten Profil „SVG Tiny Portable/Secure“, ausgeliefert über HTTPS. Ein gewöhnlicher SVG-Export wird meist abgelehnt.
• Gmail zeigt das Logo nur mit Zertifikat: einem VMC (Verified Mark Certificate), das eine eingetragene Marke voraussetzt, oder einem CMC (Common Mark Certificate), das voraussetzt, dass das Logo seit mindestens einem Jahr verwendet wird. Yahoo zeigt es unter Umständen auch ohne.

In welcher Reihenfolge

1. SPF, DKIM und DMARC mit p=none und Berichten (siehe DMARC einrichten).
2. TLS-RPT — kostenlos, harmlos und vom ersten Tag an aufschlussreich.
3. MTA-STS im Modus testing, dann enforce, sobald die TLS-Berichte sauber sind.
4. DMARC auf p=quarantine und danach auf p=reject anheben.
5. BIMI, wenn dir ein Logo im Posteingang das Zertifikat wert ist.