Ihre Domain ist die Adresse, unter der Ihr Unternehmen erreichbar ist, und gleichzeitig der Name, in dem Angreifer am liebsten schreiben. Wer eine Rechnung fälscht, tut das nicht unter eigenem Namen, sondern unter Ihrem. Vier Bausteine verhindern das: DNSSEC, MTA-STS, DANE und DMARC. Sie werden oft einzeln diskutiert, greifen aber ineinander und entfalten ihre Wirkung erst zusammen.

Dieser Beitrag stammt ursprünglich aus dem Februar 2024. Seitdem hat sich einiges bewegt: Microsoft weist seit Mai 2025 nicht authentifizierte Massenmails ab, und seit Juli 2026 legt Microsoft neue Maildomains auf eine DNS-Struktur, die DNSSEC und DANE deutlich einfacher macht. Wir haben den Text entsprechend aktualisiert.

DNSSEC: das Fundament

DNSSEC steht für Domain Name System Security Extensions. Ihre DNS-Einträge werden digital signiert, der abfragende Resolver kann die Signatur prüfen und erkennt damit, ob eine Antwort echt ist oder unterwegs manipuliert wurde.

Ohne diese Signatur ist DNS eine Auskunft, der man einfach glaubt. Das macht zwei Angriffe möglich:

• DNS-Cache-Poisoning: Ein Angreifer schiebt einem DNS-Server gefälschte Einträge unter. Nutzer tippen Ihre Domain ein und landen auf einem Server, der dem Angreifer gehört.
• Man-in-the-Middle: Ein Angreifer hängt sich zwischen zwei Kommunikationspartner, liest mit oder verändert den Verkehr, ohne dass eine der beiden Seiten es merkt.

Wichtiger noch: DNSSEC ist die Voraussetzung für alles Weitere. DANE funktioniert ohne signierte Zone nicht, weil die Vertrauenskette sonst nirgends verankert ist. Wer DNSSEC überspringt, kann die nächsten beiden Kapitel überspringen.

Warum wir unsere DNS-Verwaltung zurückgeholt haben

Wir hatten unsere DNS-Verwaltung eine Zeit lang zu Microsoft ausgelagert. Das war bequem, weil die Einträge für die genutzten Dienste dort automatisch entstanden. Irgendwann kamen aber Anforderungen, die sich dort nicht lösen ließen: eigene Nameserver für einzelne Subdomains, DNSSEC, DANE. Also sind wir mit den DNS-Einträgen zurück zu unserem Domain-Provider gezogen und haben DNSSEC aktiviert.

Diese Abwägung steht in vielen Unternehmen an, und sie geht nicht immer gleich aus. Wenn Ihr Provider DNSSEC anbietet und Sie es mit zwei Klicks einschalten können, tun Sie es. Wenn nicht, ist der Umzug der Zone der Aufwand meist wert.

MTA-STS: verschlüsselter Transport, verbindlich

E-Mail wird zwischen Mailservern per STARTTLS verschlüsselt. Das Problem: Die Server verhandeln diese Verschlüsselung im Klartext. Ein Angreifer in der Mitte kann das Angebot einfach streichen, und beide Server fallen stillschweigend auf eine unverschlüsselte Verbindung zurück. Niemand bekommt eine Warnung.

MTA-STS schließt diese Lücke. Sie hinterlegen eine Richtlinie, die sendenden Servern sagt: Für diese Domain gilt TLS, und zwar verbindlich. Fällt die Verschlüsselung aus oder passt das Zertifikat nicht, wird die Mail nicht zugestellt, statt sie ungeschützt durchzureichen. Das Verfahren ist HSTS nachempfunden, das dasselbe für Webseiten leistet.

Ergänzend gehört TLS-RPT dazu. Damit bekommen Sie Berichte darüber, welche Server beim Verbindungsaufbau gescheitert sind. Ohne diese Rückmeldung merken Sie einen Konfigurationsfehler erst, wenn ein Kunde anruft, weil seine Mails nicht ankommen.

DANE: das Zertifikat im DNS verankern

DANE steht für DNS-based Authentication of Named Entities. Sie hinterlegen im DNS einen TLSA-Eintrag, der festlegt, welches Zertifikat Ihr Mailserver benutzt. Weil dieser Eintrag über DNSSEC signiert ist, kann ihn niemand unterwegs austauschen. Der sendende Server prüft gegen diesen Eintrag statt allein gegen die Liste öffentlicher Zertifizierungsstellen.

MTA-STS und DANE lösen dasselbe Problem auf zwei Wegen. MTA-STS verankert das Vertrauen in HTTPS und einer öffentlichen CA, DANE im signierten DNS. In der Praxis betreibt man beides parallel, weil nicht jeder sendende Server beide Verfahren beherrscht.

Was sich 2026 bei Microsoft geändert hat

Für Exchange Online war DANE lange der schwierigste der vier Punkte. Das hat sich in zwei Schritten geändert.

Zuerst ist eingehendes SMTP DANE mit DNSSEC für Exchange Online allgemein verfügbar geworden. Microsoft kann seitdem selbst DANE-geschützt empfangen. Der zweite Schritt läuft seit Juli 2026: Neue Domains, die Sie in Microsoft 365 aufnehmen, bekommen ihre Einträge nicht mehr unter mail.protection.outlook.com, sondern unter mx.microsoft. Diese Zone ist signiert.

Der praktische Effekt ist erheblich. Ist Ihre eigene Domain mit DNSSEC signiert, setzt sich die Vertrauenskette automatisch bis zum Mailserver fort, und Microsoft veröffentlicht die TLSA-Einträge selbst. DANE ohne manuelle Einrichtung, das war vorher eine mehrstufige Migration.

Zwei Einschränkungen sollten Sie kennen:

• Bestandsdomains bleiben zunächst, wie sie sind. Ihre vorhandenen Einträge unter mail.protection.outlook.com funktionieren unverändert weiter. Die Umstellung des Bestands hat Microsoft angekündigt, aber noch nicht terminiert. Wer heute DANE will, geht für bestehende Domains weiter den manuellen Weg.
• Automatisierung bricht. Skripte, die den MX-Wert nach dem Muster <domain>.mail.protection.outlook.com selbst zusammenbauen, liefern für neue Domains falsche Werte. Das neue Muster lässt sich nicht erraten. Richtig ist, den Wert über die Graph-API abzufragen (serviceConfigurationRecords), statt ihn zu konstruieren. Prüfen Sie Ihre Onboarding-Skripte darauf, bevor die nächste Domain dazukommt.

DMARC: wer in Ihrem Namen schreiben darf

SPF legt fest, welche Server für Ihre Domain senden dürfen. DKIM signiert die Nachricht. DMARC ist die Klammer darüber: Es sagt dem Empfänger, was er tun soll, wenn diese Prüfungen fehlschlagen, und es liefert Ihnen Berichte darüber, wer in Ihrem Namen unterwegs ist.

Drei Richtlinien stehen zur Wahl:

• p=none: Nichts wird abgewiesen, Sie bekommen nur Berichte. Der Startpunkt, nicht das Ziel.
• p=quarantine: Nicht authentifizierte Mails landen im Spam-Ordner.
• p=reject: Nicht authentifizierte Mails werden abgewiesen und gar nicht erst zugestellt.

Wir selbst fahren p=reject. Das ist die einzige Einstellung, die Spoofing wirklich verhindert, statt es nur zu protokollieren.

Die Absenderregeln von Google, Yahoo und Microsoft

Seit dem 1. Februar 2024 stellen Google und Yahoo Anforderungen an Absender, die täglich mehr als 5.000 Mails an Konten bei gmail.com, googlemail.com, yahoo.com oder ymail.com schicken. Dabei zählt das gesamte Volumen, Marketing und Transaktionsmails zusammen.

Microsoft ist am 5. Mai 2025 nachgezogen, mit derselben Schwelle von 5.000 Mails pro Tag an Privatkonten bei outlook.com, hotmail.com und live.com. Microsoft weist nicht konforme Nachrichten hart ab, mit dem Fehlercode 550 5.7.15. Sie landen also nicht im Spam-Ordner, sondern kommen gar nicht an.

Wichtige Abgrenzung: Diese Microsoft-Regel gilt für die Privatkundendienste. Mails an Geschäftsadressen, die in Microsoft 365 liegen, fallen nicht darunter. Das ist ein Detail, das in vielen Zusammenfassungen untergeht.

Verlangt wird an allen drei Stellen im Kern dasselbe:

• SPF und DKIM eingerichtet und gültig
• ein DMARC-Eintrag mit mindestens p=none
• Übereinstimmung der Absenderdomain mit SPF oder DKIM, besser mit beiden
• Abmeldung aus Werbemails mit einem Klick
• eine niedrige Spam-Beschwerderate
• gültige PTR-Einträge für die sendenden IPs, korrekt formatierte Nachrichten, ARC-Header bei regelmäßiger Weiterleitung

Die Schwelle von 5.000 Mails klingt hoch, ist aber schneller erreicht, als die meisten schätzen: ein Newsletter an die Bestandskunden, dazu Rechnungen, Bestellbestätigungen und Terminerinnerungen aus dem ERP. Und unabhängig von der Schwelle gilt: Ein Anbieter nach dem anderen zieht die Regeln an. Wer heute sauber authentifiziert, muss beim nächsten Schritt nicht hetzen.

Von none zu reject, ohne Kollateralschaden

Der Weg zu p=reject ist kein Schalter, sondern eine Aufräumarbeit. In fast jedem Unternehmen versenden mehr Systeme unter der Firmendomain als bekannt: das ERP, das Ticketsystem, ein Newsletter-Tool, das Bewerbermanagement, die Telefonanlage, der Kopierer im Flur.

Deshalb die Reihenfolge: mit p=none starten, die Berichte einige Wochen auswerten, jeden legitimen Absender in SPF und DKIM aufnehmen, dann auf quarantine gehen und zuletzt auf reject. Wer sofort auf reject springt, schaltet zuverlässig irgendeinen Geschäftsprozess ab, von dem niemand wusste, dass er Mails verschickt.

Wo Sie anfangen

Die vier Bausteine bauen aufeinander auf, deshalb lohnt die Reihenfolge:

1. DMARC mit p=none einrichten und Berichte einsammeln. Sofort machbar, kein Risiko, und Sie sehen zum ersten Mal, wer in Ihrem Namen sendet.
2. SPF und DKIM für jedes System sauber ziehen, das laut Berichten legitim sendet.
3. DNSSEC für die Zone aktivieren. Das Fundament für Schritt 5.
4. DMARC schrittweise auf quarantine und dann auf reject anheben.
5. MTA-STS mit TLS-RPT ausrollen, danach DANE.

Das ist Arbeit, aber es ist endliche Arbeit. Der Aufwand steckt in Schritt 2, also im Inventar der sendenden Systeme. Danach ist der Rest Konfiguration.

Wir übernehmen das

Wir richten DNSSEC, MTA-STS, DANE und DMARC für unsere Kunden ein, werten die DMARC-Berichte laufend aus und heben die Richtlinie an, sobald es ohne Ausfälle geht. Was das im Rahmen unserer Security-Leistungen bedeutet, steht dort im Detail.

Wenn Sie nicht sicher sind, wie Ihre Domain heute dasteht, schauen wir gemeinsam drauf. Erstgespräch anfragen.