So funktioniert’s
Für TLS-RPT legst du einen TXT-Record unter _smtp._tls.example.com an, zum Beispiel v=TLSRPTv1; rua=mailto:tlsrpt@example.com. Hinter rua stehen eine oder mehrere Adressen für die Berichte: eine mailto-Adresse oder eine https-URL, an die der Bericht per POST geschickt wird.
Absender, die TLS-RPT unterstützen, darunter Google und Microsoft, schicken dann einmal am Tag einen Sammelbericht im JSON-Format, meist gzip-komprimiert. Er nennt die angewandte Policy (MTA-STS, DANE oder keine), die Zahl erfolgreicher und gescheiterter TLS-Sitzungen und bei Fehlern die Ursache, etwa abgelaufenes Zertifikat, falscher Hostname, fehlendes STARTTLS oder eine nicht abrufbare MTA-STS-Policy, samt betroffenem MX und IP-Adresse des Absenders.
TLS-RPT schützt selbst nichts und ändert keine Zustellung. Es ist der Rückkanal für MTA-STS und DANE: Ohne die Berichte weißt du nicht, ob deine Policy im Alltag funktioniert oder Absender seit Tagen an deinem Mailserver scheitern.
Warum gefährlich
Ohne TLS-RPT bleiben Zustellprobleme unsichtbar. Läuft das Zertifikat des Mailservers ab oder passt eine MTA-STS-Policy nach einem Anbieterwechsel nicht mehr, verweigern Absender im Modus enforce oder mit DANE die Zustellung – und du erfährst es erst, wenn sich Kunden über fehlende Mails beschweren.
Ein fehlerhafter Record, etwa mit Tippfehler in der Adresse oder ganz ohne rua, wirkt wie ein fehlender: Die Berichte gehen ins Leere. Der Zustellung schadet das nicht, aber der Frühwarnkanal fällt aus, gerade dann, wenn du MTA-STS von testing auf enforce umstellen willst.
So vermeidest du es
- Vor oder zusammen mit MTA-STS bzw. DANE einen TLS-RPT-Record unter _smtp._tls der Domain anlegen.
- Eine eigene Adresse nur für die Berichte nutzen statt eines persönlichen Postfachs: Die Mails kommen täglich und sind für Maschinen gedacht.
- Die Berichte nicht nur sammeln, sondern auswerten lassen, zum Beispiel über die Berichtsadresse von DomainWarn, die DMARC- und TLS-RPT-Berichte direkt im Dashboard zeigt.
- Nur einen Record mit v=TLSRPTv1 veröffentlichen und nach jeder Änderung prüfen, ob er noch gültig ist.
- Vor dem Umstellen von MTA-STS auf enforce die Berichte einige Wochen lang auf gescheiterte Sitzungen durchsehen.
So erkennt DomainWarn es
Der Check TLS-RPT liest den TXT-Record unter _smtp._tls und prüft, ob er mit v=TLSRPTv1 beginnt und mindestens ein plausibles Berichtsziel enthält, also eine mailto-Adresse oder eine https-URL. Fehlt der Record, gibt es einen Hinweis mit Beispiel-Record. Ist er fehlerhaft – kein rua, ein unbrauchbares Ziel oder mehrere Records –, gibt es eine Warnung ohne Incident, weil dabei nur Berichte verloren gehen. Auch der Check MTA-STS weist auf einen fehlenden TLS-RPT-Record hin.
Änderungen am Record meldet DomainWarn als „TLS-RPT geändert“. Trägst du die Berichtsadresse von DomainWarn als rua ein, landen die Berichte selbst im Reiter E-Mail der Domain: Dort siehst du, ob Absender deine Mailserver per TLS erreichen und woran Sitzungen scheitern.
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.