Ein DMARC-Eintrag in der DNS-Zone abzulegen, erledigt gar nichts: Er bewirkt nichts, solange niemand die Reports liest, die er täglich generiert. Die Domain-Überwachung bezeichnet diese kontinuierliche Lesearbeit, verteilt auf 4 Bereiche: die DMARC-Reports, die DNS-Einträge (MX, SPF, DKIM), das Ablaufdatum der Domain und ähnliche Domains, die von Dritten registriert werden. Ohne sie entdeckt ein Growth-Team die Störung erst im Nachhinein, wenn der CMO fragt, warum die Öffnungsrate eingebrochen ist. Ein klassischer Fall kursiert in Email-Marketing-Foren: eine sender reputation, die innerhalb von drei Monaten um 30 % einbricht, ohne dass sich ein Kampagneninhalt geändert hätte. Die Ursache liegt fast immer in einem DNS-Eintrag, der geändert wurde, ohne dass es jemand bemerkt hat.
Die 4 Bereiche der Domain-Überwachung
Eine schlecht überwachte Domain verliert an 4 Fronten gleichzeitig die Kontrolle, selten nur an einer. Der erste Bereich betrifft die aggregierten DMARC-Reports (RUA), die täglich in einem dedizierten Postfach eintreffen und die kaum ein Team öffnet. Der zweite umfasst die DNS-Einträge selbst: SPF, DKIM und der DMARC-Eintrag können von einem externen Dienstleister oder einem Migrationsskript geändert werden, ohne dass ein Alarm ausgelöst wird. Der dritte Bereich betrifft den Ablauf der Domain, ein administratives Thema, das niemand gerne übernimmt. Der vierte betrifft Domains, die der eigenen bis auf ein Zeichen ähneln und registriert werden, um Kunden durch Identitätsdiebstahl zu täuschen; der Mechanismus dieser Bedrohung folgt weiter unten. Die Domain-Überwachung blockiert für sich genommen keinen einzigen Angriff. Sie löst frühzeitig Alarm aus, auf allen 4 Fronten gleichzeitig.
DMARC-Reports lesen, statt sie nur zu veröffentlichen
Ein DMARC-Eintrag mit p=none weist keine einzige Nachricht zurück und stellt sie auch nicht unter Quarantäne. Er löst den Versand aggregierter Reports (RUA) im XML-Format aus, im Durchschnitt einmal täglich, von jedem Anbieter, der signierte Mails Ihrer Domain empfängt: Gmail, Outlook, Yahoo sowie Unternehmensserver, die DMARC anwenden. Forensische Reports (RUF) hingegen beschreiben eine einzelne fehlgeschlagene Nachricht im Detail. Google versendet sie nicht mehr. Microsoft und Yahoo tun dies noch gelegentlich. Die Felder eines aggregierten Reports zu entschlüsseln (Quell-IP, SPF/DKIM-Alignment, vom empfangenden Server angewendete Disposition) ist eine eigene technische Übung; unser Artikel so lesen Sie einen aggregierten DMARC-Bericht fehlerfrei geht sie Feld für Feld durch. Hier lässt sich der praktische Punkt in einem Satz zusammenfassen: Ohne regelmäßige Lektüre bleibt die Policy bei p=none stecken. Das ist bei den meisten geschützten Domains weltweit der Fall, weil niemand da ist, um den XML-Datenstrom auszuwerten und die Policy schrittweise auf p=quarantine und dann p=reject anzuheben.
Nicht autorisierte DNS-Änderungen bei MX, SPF, DKIM, DMARC erkennen
Tools wie MXToolbox, CaptainDNS oder DNS Assistant fragen die DNS-Zone in regelmäßigen Abständen ab und lösen eine E-Mail- oder Slack-Benachrichtigung aus, sobald sich ein MX-, SPF-, DKIM- oder DMARC-Eintrag im Wert ändert, nach Abgleich mit dem vorherigen Wert. Die Differenz zwischen altem und neuem Wert steht direkt in der Benachrichtigung, wodurch eine vollständige Diagnose bei jedem Vorfall entfällt. Ein SPF-Eintrag, der sein Limit von 10 DNS-Abfragen überschreitet, schlägt fehl, ohne Bounce oder sichtbaren Alarm auf Seiten des Absenders. Wie das im Detail abläuft, steht in unserem Artikel über das SPF-Limit von 10 DNS-Lookups. Ein DKIM-Eintrag, der nach einem Hoster-Wechsel gelöscht wird, zerstört ebenso die Signatur aller ausgehenden E-Mails; das einzig sichtbare Symptom ist manchmal ein NDR (Non-Delivery Report) mit dem Enhanced Status Code 5.7.1, ohne offensichtlichen Zusammenhang zur DNS-Änderung vom Vortag. Eine geplante Protokollumstellung, wie der von DMARCbis vorgesehene Wegfall des pct-Tags, erzeugt dieselbe Art von scheinbar verdächtiger, aber legitimer Änderung: Vorher-Nachher-Vergleiche bleiben zuverlässiger als blindes Reagieren. In einem ohnehin mit Alarmen überladenen Stack gibt es morgens nichts zu prüfen: Diese Dienste laufen im Hintergrund und melden sich nur, wenn sich ein Wert tatsächlich ändert. Ein einziger Fall rechtfertigt die Einrichtung bereits. Eine stabilisierte Domain ändert ihre DNS-Konfiguration selten. Wenn sie sich ändert, ist es fast immer eine bewusste Änderung von jemandem im Team. Das Monitoring dient dazu, genau die Änderung zu erkennen, die kein internes Ticket ankündigt, die häufigste Spur hinter einem gekaperten Eintrag ohne kompromittiertes Registrar-Konto. Ein Szenario, das von Infoblox und Eclypsium unter dem Namen Sitting Ducks dokumentiert wurde.
Fast 800.000 identifizierte gefährdete Domains und über 30.000 bestätigte Übernahmen seit 2019, ohne dass ein einziges Registrar-Konto kompromittiert wurde (Infoblox und Eclypsium, 2024).
Ablauf und Verlängerung der Domain überwachen
Der Zyklus nach einem Ablauf umfasst drei Phasen: eine Kulanzfrist von etwa 30 Tagen, in der die Verlängerung noch einfach ist, eine Rückholfrist von etwa 30 Tagen mit einer Strafgebühr von 80 bis 200 Euro, dann ein finales Löschfenster von 5 bis 15 Tagen vor dem öffentlichen Wiederverkauf. 13 % der abgelaufenen Unternehmensdomains werden laut internen Recherchen von CSC aus dem Jahr 2024 von Dritten neu registriert. Dieser Wert steigt bei historischen Domains, die im blinden Fleck eines Markenportfolios liegen, das nach einer Fusion oder einem Dienstleisterwechsel nie geprüft wurde. Eine in diesem Stadium verlorene Domain reißt die Website und die geschäftlichen E-Mail-Adressen mit sich. Sie löscht auch das über Jahre aufgebaute Google-Ranking.
Ähnliche Domains und Typosquatting erkennen
Eine um ein Zeichen kopierte Domain (Ersetzen eines kleinen l durch ein großes I, ein zusätzlicher Bindestrich, die Endung .co statt .com) genügt, um eine glaubwürdige Phishing-Seite oder eine Absenderadresse aufzubauen, die einen eiligen Kunden täuscht. Über 30.000 Lookalike-Domains, die bekannte Marken imitierten, wurden zwischen Februar und Juli 2024 von Zscaler ThreatLabz erfasst, davon über 10.000 als bösartig identifiziert. Allein im März 2025 wurden über 26.000 Domains, die Marken oder öffentliche Dienste imitierten, von Palo Alto Networks Unit 42 bei Smishing-Kampagnen entdeckt. Wie ein Angreifer den Absender einer E-Mail überhaupt fälscht, erklären wir in unserem Artikel zum Thema E-Mail-Spoofing. Frühzeitige Erkennung, noch vor dem Versand der ersten betrügerischen Kampagne, begrenzt den Schaden. Ein Überwachungsdienst für Varianten in der Nähe des eingetragenen Markennamens ergänzt das Ganze.
Empfohlene Prüffrequenz nach Bereich
| Überwachter Bereich | Empfohlene Frequenz | Auslösendes Signal | Maßnahme bei Alarm |
|---|---|---|---|
| DMARC-Reports (RUA) | Wöchentliche Lektüre | Nicht identifizierte Quell-IP, fehlgeschlagenes SPF-/DKIM-Alignment | Absender identifizieren, SPF anpassen oder Policy auf p=quarantine anheben |
| DNS-Einträge (MX, SPF, DKIM) | Kontinuierliches Monitoring mit automatischem Alarm | Wert ohne geplante Änderung modifiziert | Alt/Neu vergleichen, bei fehlender Autorisierung wiederherstellen |
| Ablauf der Domain | Vierteljährliche Portfolioprüfung | Verlängerung unter 60 Tagen | Automatische Verlängerung und Registrar-Sperre aktivieren |
| Ähnliche Domains / Typosquatting | Monatliche Beobachtung | Registrierung einer markennahen Variante | Meldung an den Registrar, UDRP-Verfahren bei bestätigtem Betrugsversuch |
Dieser Rhythmus passt für die meisten beobachteten Konfigurationen bereits stabilisierter Domains. Eine Domain, die gerade zu einem neuen E-Mail-Dienstleister migriert ist, rechtfertigt im ersten Monat eine tägliche DMARC-Lektüre, bis sich das SPF- und DKIM-Alignment auf der neuen Infrastruktur stabilisiert hat.
Was die Domain-Überwachung nicht abdeckt
Die Ursache einer einbrechenden Zustellbarkeit liegt manchmal woanders als bei der Domain: fast immer bei der Liste selbst, mit einer steigenden Hard-Bounce-Rate und Catchall-Adressen, die sich über die Importe angesammelt haben. Eine Domain kann perfekt überwacht sein (DMARC gelesen, DNS stabil, Verlängerung vorausschauend geplant, keine typosquattende Variante entdeckt) und trotzdem einen Einbruch der Zustellbarkeit erleben. Auch die Complaint Rate steigt, sichtbar über die Feedback Loops mehrerer Mailbox-Provider. Diese Signale schädigen die Sender Reputation ebenso wie ein defekter SPF-Eintrag. Kein DNS-Monitoring-Tool erkennt sie, und auch das Microsoft-Pendant zum Google Postmaster (SNDS, Smart Network Data Services, weniger genutzt, aber ebenso aufschlussreich) deckt nicht die Qualität der versendeten Adressen ab. Der einzige Weg, um zu wissen, ob die Liste parallel zum DNS abgedriftet ist, bleibt, sie vor dem nächsten Versand systematisch zu prüfen, statt das Problem erst in einem Dashboard zu entdecken, wenn die Reputation bereits gelitten hat.
Der BIMI-Standard, der das Logo des Absenders im Posteingang anzeigt, verlangt bei den meisten Anbietern ein seit mehreren Wochen stabiles DMARC mit p=reject, um aktiviert zu werden. Nur wenige Domains erfüllen diese Bedingung 2026 noch.
