Fusionen und Übernahmen: E-Mail-Domains ohne Authentifizierungslücke konsolidieren

Von Thomas · virtueller CISO · 30. August 2026

Bei einer Fusion oder Übernahme schafft es die E-Mail fast nie in den Datenraum. Juristen durchkämmen die Verträge, Finanzteams bereinigen die Zahlen, Technikteams auditieren Code und Infrastruktur — aber niemand fragt nach der Liste der DNS-Zonen oder dem Zustand der DMARC-Policies des Übernahmeziels. Am Tag des Closings wird der Käufer dennoch für ein Erbe verantwortlich, das er nie aufgebaut hat: Dutzende E-Mail-Domains, angesammelt über Marken, Tochtergesellschaften und frühere Zukäufe, auf völlig uneinheitlichem Authentifizierungsniveau.

Das Thema geht über technische Schulden hinaus. Die Integrationsphase ist genau der Moment, in dem sich Identitätsmissbrauch am meisten lohnt: Die Transaktion wird öffentlich angekündigt, Adressen ändern sich, Weiterleitungen vervielfachen sich, und jeder Mitarbeiter rechnet mit ungewöhnlichen Nachrichten von noch unbekannten Ansprechpartnern. Betrüger lesen die Wirtschaftspresse — aus ihrer Sicht ist eine Übernahmemeldung ein Angriffskalender.

Dieser Leitfaden beschreibt die Methode, um die Transaktion ohne Authentifizierungslücke zu überstehen: die E-Mail-Due-Diligence vor der Integration, die Absicherung der Übergangsphase, die Konsolidierungsstrategie für die Domains, die DNS-Governance nach der Fusion und das Schicksal der geerbten Domains, die nie wieder versenden werden.

Was eine Übernahme wirklich mitbringt: einen unbekannten Domain-Bestand

Auf dem Papier betrifft die Transaktion ein Unternehmen und seine Hauptdomain. In der Praxis kommt das Übernahmeziel mit einem ganzen Bestand an: die Domains der Handelsmarken, die Länder-Varianten der lokalen Einheiten (.de, .es, .co.uk), die historischen Domains der Firmen, die es selbst ein Jahrzehnt zuvor geschluckt hatte, die defensiv gegen Typosquatting registrierten Namen, die vom Marketing für eine Kampagne angelegten und nie stillgelegten Domains — und ein langer Schwanz geparkter Namen, an deren Ursprung sich niemand mehr erinnert.

Das Authentifizierungsniveau dieses Bestands ist ausnahmslos uneinheitlich. Eine manchmal sauber konfigurierte Hauptdomain; ein paar p=none-Einträge, eines Tages veröffentlicht, ohne dass danach je jemand die Berichte gelesen hätte; widersprüchliche SPF-Einträge, nachgebessert von wechselnden Dienstleistern; DKIM-Selektoren, die auf längst gekündigte Plattformen zeigen; und eine Mehrheit von Domains ganz ohne Eintrag. Schlimmer noch: Die Liste der Juristen — eingetragene Marken, beim Registrar verlängerte Namen — deckt sich nur teilweise mit der operativen Realität. DNS-Zonen leben bei einem zweiten Registrar, eröffnet von einer lokalen Agentur, manchmal unter einem persönlichen Konto.

Der klassische Fehler besteht darin, nur die Hauptdomain des Übernahmeziels zu behandeln und den Rest des Bestands von Vorfall zu Vorfall zu entdecken. Der solide Ansatz dreht das Problem um: erst inventarisieren, dann entscheiden.

Die E-Mail-Due-Diligence: drei Inventare vor der Integration

Idealerweise findet diese Due Diligence vor dem Closing statt, gleichrangig mit dem Sicherheitsaudit; andernfalls eröffnet sie die ersten Wochen der Integration. Es geht um drei Inventare.

Das erste ist der Domain-Bestand selbst: welche Namen, bei welchen Registraren, unter welchen Konten, verlängert von wem und bis wann. Die Kreditorenbuchhaltung des Übernahmeziels (Verlängerungsrechnungen) und eine Inhaberrecherche ergänzen die offizielle Liste sinnvoll — genau dort tauchen die von einer Tochter oder einer Agentur eröffneten Domains auf.

Das zweite ist der Authentifizierungszustand, Domain für Domain: Vorhandensein und Inhalt des SPF, aktive DKIM-Selektoren, DMARC-Eintrag samt Policy, MX und — ein aufschlussreiches Signal — das Vorhandensein einer rua-Adresse, die verrät, ob irgendjemand irgendwann die Berichte angesehen hat. Alles passt in eine Tabelle mit einer Spalte pro Mechanismus, die zur Risikokarte der Integration wird.

Das dritte, langwierigste Inventar betrifft die Drittversender des Übernahmeziels: CRM, Rechnungsstellung, Gehaltsabrechnung, Support, Marketing-Plattformen, Fachanwendungen, die „im Namen" seiner Domains versenden. Die Methode ist exakt die von dem Inventar der Drittversender, mit einer fusionsspezifischen Schwierigkeit: Das zu kartierende Ökosystem kennt niemand im Integrationsteam, und die Menschen, die es kannten, verlassen das Unternehmen manchmal mit der Transaktion.

Ein sofortiger Reflex zahlt sich reich aus: v=DMARC1; p=none; rua=mailto:… auf jeder Domain des Übernahmeziels veröffentlichen, die nichts hat. Diese Maßnahme kostet nichts, blockiert keine einzige legitime Nachricht und verpflichtet zu nichts — sie macht nur sichtbar, was ohnehin geschieht. Eine Handvoll TXT-Einträge genügt, damit während der gesamten Integration Daten einlaufen — wenn die Konsolidierungsentscheidungen anstehen, liegen bereits Wochen an Berichten vor, statt dass die Beobachtung erst dann beginnt.

Die Übergangsphase: der Moment der größten Exposition

Der Übergang beginnt meist mit einer harmlos wirkenden Entscheidung: die Adressen der alten Firma auf die neuen umzuleiten. vorname.name@beispiel.net wird zur automatischen Weiterleitung auf vorname.name@beispiel.de, oft für Hunderte Postfächer auf einmal. Doch die klassische SMTP-Weiterleitung zerstört SPF: Jede Nachricht, die ein Dritter an die alte Adresse schickt und die weitergereicht wird, scheitert bei der Ankunft an der Prüfung, weil die IP des weiterleitenden Servers nicht im SPF-Eintrag des ursprünglichen Absenders steht. DKIM überlebt, solange der Inhalt unberührt bleibt, und ARC hilft bei den großen Anbietern — aber ein massiver Weiterleitungsstrom verschlechtert mechanisch das Alignment, verschmutzt die Berichte beider Bestände mit falschen Positiven und verliert die Nachrichten von Absendern auf p=reject, deren DKIM-Signatur nicht standhält.

Das zweite Risiko wiegt schwerer: der opportunistische Missbrauch. Eine Fusionsankündigung ist per Konstruktion öffentlich — Pressemitteilung, Fachpresse, Handelsregister. Das lukrativste Szenario ist der Bankdaten-Betrug: eine Rechnung mit dem Hinweis „im Zuge unserer Fusion ändern sich unsere Bankverbindungen", verschickt an Lieferanten und Kunden beider Einheiten, von einer gefälschten oder täuschend ähnlichen Domain. Die Bedingungen sind ideal: Alle rechnen mit Veränderung, die Freigabeprozesse sind durcheinander, die Ansprechpartner kennen einander noch nicht. Eine Domain des Übernahmeziels, die in diesem Fenster auf p=none bleibt, ist eine offene Tür — zum denkbar schlechtesten Zeitpunkt.

Das dritte Risiko ist still: die Verwässerung der Verantwortung. Zwei IT-Teams existieren nebeneinander, Zuständigkeiten überlappen sich, und die aggregierten Berichte haben monatelang keinen festen Leser. Die Gegenmaßnahme passt in eine Entscheidung: ab dem Tag der Unterschrift einen einzigen Verantwortlichen für die E-Mail-Authentifizierung beider Bestände benennen, mit allen Berichten an einem Ort gebündelt.

Die Konsolidierungsstrategie: welche Domain überlebt

Die erste strukturelle Entscheidung ist die überlebende Domain — meist die des Käufers, manchmal die des Übernahmeziels, wenn dessen Handelsmarke erhalten bleibt. Muss die Marke ohne ihre Domain weiterleben, bietet eine Übergangs-Subdomain der überlebenden Domain (marke.beispiel.de) einen sauberen Weg: Die sichtbare Identität bleibt erhalten, die Authentifizierung steht unter der Organisations-Policy der Gruppe, und es bleibt nur ein Bestand zu verwalten. Dann kommt der Kalender, in drei Phasen.

Das Doppelleben. Beide Domains versenden parallel, während Postfächer und Werkzeuge migrieren, unter Beobachtung der Berichte. In dieser Phase wechseln die Anwendungsflüsse — Rechnungsstellung, CRM, Benachrichtigungen, Gehaltsabrechnung — einer nach dem anderen auf die überlebende Domain, mit derselben Mechanik wie bei einem Wechsel des E-Mail-Providers: Quelle für Quelle, nie als Big Bang.

Der Versandstopp. Ab einem intern angekündigten Datum verlässt keine legitime Post mehr die alte Domain. Die Berichte dienen dann als Beweis: Einige Wochen mit legitimem Nullvolumen bestätigen, dass der Stopp wirkt und kein vergessener Fluss übrig ist. Der Testmodus von DMARCbis (t=y, Nachfolger des aus dem Standard entfernten pct-Tags) erlaubt, die Policy zu verschärfen und die Wirkung zu beobachten, bevor sie endgültig wird.

Die Verriegelung. Das SPF der alten Domain schrumpft auf v=spf1 -all, die Policy wechselt auf p=reject, ergänzt auf der Organisationsdomain durch sp=reject und durch das np=-Tag von DMARCbis, das nicht existierende Subdomains abdeckt — wertvoll bei einer Domain, deren historischer Baum nicht mehr beherrscht wird. Der Empfang kann derweil weiterlaufen: Die MX-Einträge jahrelang zu behalten, damit keine an die alten Postfächer adressierte Nachricht verloren geht, ist mit der Abweisung gefälschter Ausgangspost vollkommen vereinbar.

Governance: wem gehört das DNS nach der Fusion

Die Frage klingt administrativ; sie ist strukturell. Solange die DNS-Zonen des Übernahmeziels bei ihrem historischen Registrar bleiben, unter den Konten seiner früheren Dienstleister, kann jeder Authentifizierungseintrag außerhalb jeder Kontrolle geändert werden. Die Governance-Arbeit passt in fünf Punkte: die Registrar-Konten unter der steuernden Einheit konsolidieren; die Zugänge von Agenturen, Dienstleistern und mit der Transaktion ausgeschiedenen Mitarbeitern widerrufen; die Zonen unter Änderungskontrolle stellen, idealerweise als Infrastructure-as-Code; für jede Domain einen Eigentümer benennen; und den Empfang aller Berichte in einem einzigen Multi-Domain-Werkzeug zentralisieren.

Das Zielmodell ist das von der Governance eines Multi-Marken-Portfolios: zentrale Policy, delegierte Ausführung, und kein Authentifizierungseintrag wird außerhalb des Prozesses geändert. Die Monate nach einer Fusion sind genau die Zeit, in der ein vergessener Dienstleister ein SPF „wie früher" nachbessert und ein Alignment zerstört, ohne dass irgendjemand versteht, woher der Vorfall kommt — ein aktuell gehaltenes Verzeichnis, wem was gehört, ist das einzige Gegenmittel.

Das Schicksal der schlafenden Erb-Domains

Nach abgeschlossener Konsolidierung bleibt der lange Schwanz: aufgegebene Marken, die Namen über die Jahre geschluckter Firmen, aufbewahrt aus markenrechtlichen Gründen oder schlichter Vorsicht. Diese Domains werden nie wieder eine legitime E-Mail versenden — und doch bleibt jede eine fälschbare Identität, mit der Geschichte und der Glaubwürdigkeit einer echten Marke. Gerade weil dort niemand mehr hinschaut, sind solche Namen für Betrüger attraktiver als eine aktiv überwachte Hauptdomain.

Die Behandlung ist Standard und wird in dem Schutz geparkter Domains ausgeführt: SPF reduziert auf v=spf1 -all, eine p=reject-Policy — mit einer rua-Adresse, um zuzusehen, wie Fälschungsversuche weiter scheitern —, und ein Null-MX (RFC 7505), wenn die Domain nichts mehr empfängt. Zwei Rituale runden das Dispositiv ab: bei jeder Verlängerung prüfen, ob die Verriegelung noch greift; und vor jeder erwogenen Aufgabe daran denken, dass eine abgelaufene Domain gekauft werden kann — sie würde dann wieder aufleben, mit zwanzig Jahren Markengeschichte, in den Händen eines Fremden.

Fazit

Eine Fusion oder Übernahme bringt immer einen Domain-Bestand mit, der größer, älter und schlechter authentifiziert ist als erwartet. Die Methode passt in fünf Schritte: inventarisieren — Domains, Policies, Drittversender des Übernahmeziels — vor oder direkt beim Closing; p=none und Berichtsadressen überall dort veröffentlichen, wo nichts existiert; den Übergang in dem Wissen durchqueren, dass Massenweiterleitungen SPF verschlechtern und die öffentliche Ankündigung den Betrug anzieht; in Phasen konsolidieren — Doppelleben, Versandstopp, Verriegelung auf p=reject; dann das vereinigte DNS als Vermögenswert verwalten, bis hinunter zu den schlafenden Domains auf v=spf1 -all.

Der erste Schritt verlangt weder Budget noch Zugänge: Jede Domain des Bestands — die des Käufers wie die des Übernahmeziels — durch eine kostenlose DMARC-Analyse laufen zu lassen, liefert in Sekunden die Karte der Authentifizierungslücken. Um anschließend Dutzende Domains durch die Integration zu begleiten und den Aufstieg zu p=reject zu dokumentieren, bündelt die Eröffnung eines Kontos Berichte, Alarme und Historie — das natürliche Werkzeug einer Konsolidierung, die keine Domain zurücklässt.