E-Mails werden zwischen Servern heute fast immer verschlüsselt übertragen. Fast immer – und genau darin liegt das Problem.
Die Verschlüsselung wird beim Verbindungsaufbau ausgehandelt: Der sendende Server fragt, ob der empfangende verschlüsseln kann, und wenn ja, wird verschlüsselt. Wenn nein, wird trotzdem zugestellt, nur eben offen. Das ist gut gemeint – niemand soll Post verlieren –, hat aber eine unangenehme Folge: Wer sich in die Verbindung hängt, muss die Verschlüsselung nicht brechen. Es genügt, die Frage danach zu unterdrücken. Beide Seiten halten den offenen Versand dann für normal.
Dagegen helfen die drei Einträge auf dieser Seite. Sie gehören zur Kür, nicht zur Pflicht – wer sie nicht hat, macht nichts falsch. Wer sie hat, schließt aber eine Lücke, die sonst dauerhaft offensteht.
MTA-STS ist eine Zusage an alle Absender: „Zu meinen Servern wird verschlüsselt zugestellt, und zwar zu genau diesen Namen. Wenn das nicht geht, liefere lieber nicht aus." Ein Angreifer kann die Verschlüsselung damit nicht mehr stillschweigend wegverhandeln – der Absender bricht ab, statt offen zuzustellen.
MTA-STS besteht aus zwei Teilen, und beide müssen da sein:
Ein DNS-Eintrag unter _mta-sts.<deine-domain>:
v=STSv1; id=20260916000000Die id ist nur eine Versionsnummer. Änderst du die Richtlinie, änderst du auch die id – daran erkennen Absender, dass sie neu laden müssen.
Eine Datei, abrufbar unter https://mta-sts.<deine-domain>/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mx00.ionos.de
mx: mx01.ionos.de
max_age: 604800Für den Namen mta-sts.deine-domain.de brauchst du einen DNS-Eintrag auf deinen Webserver und ein gültiges HTTPS-Zertifikat – bei den meisten Hostern ist das eine Subdomain mit automatischem Zertifikat, also eine Sache von Minuten.
TLS-RPT ist der kleine Bruder und mit einer Zeile erledigt. Ein TXT-Eintrag unter _smtp._tls.<deine-domain>:
v=TLSRPTv1; rua=mailto:tls@beispiel.deDamit melden dir die großen Anbieter täglich, wenn die Übertragung zu dir unverschlüsselt lief oder fehlschlug. Das ist die einzige Möglichkeit, das überhaupt zu bemerken – ein abgelaufenes Zertifikat auf dem Mailserver oder eine kaputte Richtlinie fällt sonst monatelang niemandem auf.
Der Eintrag lohnt sich auch ohne MTA-STS: Er kostet nichts und verwandelt ein unsichtbares Problem in eine E-Mail.
Alle Einträge, um die es in diesem Check geht, stehen im DNS. SPF, DKIM, DMARC, MX: Sie schützen genau so weit, wie man den Antworten des DNS trauen kann. Ohne DNSSEC kann jemand, der in der Leitung sitzt, diese Antworten austauschen – einen anderen MX-Eintrag unterschieben, einen SPF-Eintrag entfernen.
DNSSEC signiert die Einträge deiner Zone, sodass Auflöser eine Fälschung erkennen. Bei den meisten Anbietern ist es ein Schalter in der Domain-Verwaltung: bei IONOS, STRATO und den anderen großen Hostern einmal einschalten, fertig. Nur wenn Domain und DNS-Zone bei verschiedenen Anbietern liegen, sind zwei Schritte nötig – dann muss der Schlüssel der Zone beim Registrar hinterlegt werden.
Ein Nebeneffekt, der selten erwähnt wird: MTA-STS gibt es unter anderem deshalb, weil ein älteres Verfahren namens DANE zwingend DNSSEC voraussetzt und sich deshalb nie breit durchgesetzt hat. Wer DNSSEC hat, kann zusätzlich DANE einrichten – für die meisten kleinen Betriebe ist MTA-STS aber der einfachere Weg.
testing – Eintrag und Datei anlegen, ein paar Wochen die Meldungen beobachten.enforce – wenn nichts auffällt.Zulässig ist einer; bei mehreren ist die Angabe unbrauchbar.
Was zu tun ist: Auf einen Eintrag zusammenführen.
Die Richtlinie steht auf mode: testing. Es wird nichts erzwungen, Abweichungen werden nur gemeldet. Als Einstieg genau richtig.
Was zu tun ist: Wenn seit einigen Wochen keine Meldungen mehr kommen, auf mode: enforce wechseln. Vorher die mx:-Liste mit den tatsächlichen MX-Einträgen abgleichen.
Die Richtlinie ist ausdrücklich außer Kraft gesetzt. Meist ein Rest aus einer Abschaltung, den jemand vergessen hat.
Was zu tun ist: Entweder auf testing oder enforce setzen – oder Eintrag und Datei ganz entfernen, damit der Zustand eindeutig ist.
max_age liegt unter einem Tag. Damit halten Absender die Richtlinie kaum vor, und der Schutz greift praktisch nicht – er beruht gerade darauf, dass die Zusage zwischengespeichert wird.
Was zu tun ist: max_age auf mindestens 86400 (ein Tag) setzen; üblich sind 604800 (eine Woche).
In der mx:-Liste fehlen Server, die im MX-Eintrag stehen. Im Testbetrieb führt das zu Fehlermeldungen, aber noch nicht zu Ausfällen.
Was zu tun ist: Die fehlenden Namen in die Datei aufnehmen – bevor du auf enforce wechselst.
Die Richtlinie gilt im Durchgriff, nennt aber nicht alle Mailserver der Domain. Absender, die sich daran halten, brechen die Zustellung ab – deine eigene Post kommt nicht an, und der Absender bekommt eine Fehlermeldung, die nach einem Problem auf seiner Seite aussieht.
Was zu tun ist: Sofort handeln. Entweder alle MX-Namen in die Datei aufnehmen oder die Richtlinie vorübergehend auf mode: testing zurückstellen, bis die Liste stimmt. Vergiss nicht, danach die id im DNS-Eintrag zu ändern, sonst laden Absender die alte Fassung weiter.
Im DNS steht ein MTA-STS-Eintrag, die zugehörige Datei ist aber nicht abrufbar. Absender, die den Eintrag sehen und die Datei nicht bekommen, können die Zustellung abbrechen.
Was zu tun ist: Die Datei unter https://mta-sts.<deine-domain>/.well-known/mta-sts.txt bereitstellen – mit gültigem HTTPS-Zertifikat und ohne Weiterleitung. Solange sie fehlt, ist es sicherer, den DNS-Eintrag zu entfernen.
Der Eintrag existiert, nennt aber keine Adresse. Damit werden keine Berichte zugestellt – der Eintrag bewirkt nichts.
Was zu tun ist: rua=mailto:… ergänzen.
Pflicht ist keines davon, und der Check zieht dafür auch keine Punkte ab. DNSSEC und TLS-RPT kosten zusammen zehn Minuten und sind praktisch risikofrei – die würde ich immer mitnehmen. MTA-STS ist etwas aufwendiger und will sorgfältig gemacht sein.
Nicht verlieren – Absender brechen ab und versuchen es später erneut, die Nachricht bleibt beim Absender. Dauerhaft falsch eingestellt kommt die Post allerdings gar nicht mehr an. Deshalb der Weg über testing.
Bei den großen Hostern nicht – dort wird alles automatisch verwaltet. Riskanter wird es, wenn du die Zone später zu einem anderen Anbieter umziehst: Dann müssen die Schlüssel korrekt übergeben werden, sonst ist die Domain kurzzeitig nicht erreichbar. Vor einem Umzug also daran denken.
Mit diesem Check: Er liest den DNS-Eintrag, ruft die Richtliniendatei wirklich ab, vergleicht die mx:-Liste mit deinen tatsächlichen MX-Einträgen und meldet das AD-Flag für DNSSEC.
Grafikdesigner & Programmierer. Seit über 25 Jahren in der Werbung zuhause – heute mit Fokus auf Websites, 3D, SEO und KI-Automation für Agenturen und Unternehmen.
Unverbindlich und auf Augenhöhe – ich sage dir ehrlich, was sinnvoll ist.
Termin vereinbaren → oder Kontaktdaten ansehen