Den E-Mail-Anbieter wechseln, ohne DMARC zu brechen

Von Thomas · virtueller CISO · 26. August 2026

Mail-Migrationen gehören zum Lebenszyklus jeder IT-Landschaft: der Wechsel von Microsoft 365 zu Google Workspace, die umgekehrte Reise, der Auszug aus der Mail-Lösung eines Hosters in eine Cloud-Suite, die Konsolidierung nach einer Umstrukturierung. Zugleich sind sie, sehr präzise, der Moment, in dem DMARC am häufigsten bricht. Das Paradox ist nur scheinbar eines: SPF, DKIM und DMARC beschreiben minutiös, wer im Namen der Domain versenden darf — und eine Migration ändert genau das. Versand-IP-Adressen, kryptografische Signaturen, Rückwege: alles bewegt sich innerhalb von Tagen, manchmal über Nacht.

Das schmerzhafte Szenario ähnelt sich überall. Die Umstellung passiert an einem Freitagabend; der SPF-Eintrag wird „ersetzt" statt erweitert; das DKIM des neuen Anbieters wurde nie an einer echten Nachricht getestet; und am Montagmorgen landen die Angebote im Spam, während die Fakturierung, noch an den alten SMTP-Server angeschlossen, lautlos scheitert. Steht die Policy bereits auf p=reject, ist der Fehlschlag von innen nicht einmal sichtbar: Die Post wird an der Tür der Empfänger vernichtet, ohne Bounce und ohne Alarm.

Nichts davon ist unvermeidlich. Eine Migration bricht DMARC nur, wenn sie in der falschen Reihenfolge gespielt wird. Die sichere Sequenz besteht aus drei Phasen — vorher, währenddessen, danach — und ruht auf einem einzigen Prinzip: Kein Fluss wechselt je zu einem Anbieter, dessen Authentifizierung nicht bereits bewiesen ist.

Warum die Migration der Moment der Wahrheit ist

Im eingeschwungenen Zustand verlangt ein gut eingestelltes DMARC fast nichts: Die Quellen sind bekannt, die Policy ist stabil, die Berichte gleichen sich von Woche zu Woche. Eine Migration erschüttert alle drei Säulen auf einmal. Die Versand-IPs ändern sich, also wird der bestehende SPF-Eintrag durch Auslassung falsch. Die Signaturen ändern sich, also sagt das bestehende DKIM nichts über die neuen Flüsse. Und das Alignment hängt an Voreinstellungen des neuen Anbieters (technische Domain, Rückweg), die nicht immer zur sichtbaren Domain passen.

Der verbreitetste organisatorische Fehler besteht darin, die Migration als Postfach-Projekt zu behandeln: Datenübernahme, Schulung, MX-Einträge — und die Authentifizierung des Versands kommt zuletzt, wenn überhaupt. Dabei betreffen die MX-Einträge nur den Empfang; DMARC beurteilt ausschließlich den Versand. Eine Domain kann einwandfrei empfangen und zugleich ihre gesamte ausgehende Post abgewiesen sehen. Der andere Klassiker: den Altanbieter zu früh abzuschalten, während die Hälfte der Anwendungen noch über ihn versendet.

Die absolute Vorbedingung, vor jedem Umstellungstermin, bleibt das Inventar der Drittversender: Eine Migration verschiebt keinen Server, sie verschiebt ein ganzes Ökosystem — und was nicht inventarisiert ist, wird kaputtgehen. Auf größerer Skala, wenn ganze Domain-Bestände den Besitzer wechseln, gilt dieselbe Disziplin mit vervielfachten Einsätzen; das ist der Gegenstand von E-Mail-Domains in einer Fusion oder Übernahme.

Vor der Umstellung: ein additives SPF, niemals ein Ersatz

Die goldene Regel der Vorbereitungsphase: Während des gesamten Migrationsfensters autorisiert der SPF-Eintrag beide Welten zugleich. Der Include des neuen Anbieters kommt zu dem des alten hinzu, er ersetzt ihn nicht. Für eine Migration von Microsoft 365 zu Google Workspace sieht der Übergangseintrag so aus:

beispiel.de.  IN TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all"

Diese Koexistenz ist keine Bequemlichkeit, sondern die Bedingung der Überlappungsphase: Solange Benutzer oder Anwendungen noch über die alte Infrastruktur versenden, muss diese autorisiert bleiben. Der Rückbau des alten Include ist keine Geste des Stichtags — er ist eine Geste des Abschlusses, Wochen später.

Ein technischer Vorbehalt begleitet die Addition: die Grenze von zehn DNS-Abfragen in SPF. Zwei Cloud-Suiten, eine Marketing-Plattform, ein Fakturierungswerkzeug, ein CRM — der Zähler steigt schnell, und eine Überschreitung macht den Eintrag ungültig (permerror), also schlimmer als unvollständig. Der gesunde Reflex: veraltete Includes vor dem Hinzufügen des neuen ausmisten und den Zähler nach jeder Änderung erneut prüfen. Eine Migration ist ohnehin oft die ideale Gelegenheit, ein SPF zu entschlacken, das Jahre verlassener Dienstleister mit sich schleppt.

Vor der Umstellung, weiterhin: das DKIM des Neuen, aktiviert und bewiesen

Die zweite vorbereitende Baustelle wiegt mindestens ebenso schwer: Die DKIM-Signatur des neuen Anbieters muss aktiviert, veröffentlicht und verifiziert sein, bevor ein einziger Benutzer wechselt. Konkret: Bei Google Workspace die Veröffentlichung des Selektors google._domainkey als TXT-Eintrag und das Einschalten der Signatur in der Konsole; bei Microsoft 365 zwei CNAME-Einträge (selector1._domainkey und selector2._domainkey), die auf die Microsoft-Infrastruktur zeigen, dann die ausdrückliche Aktivierung der Signatur für die Domain — ohne diesen letzten Schritt gehen die Nachrichten mit der technischen Domain onmicrosoft.com signiert hinaus, ohne Alignment zur sichtbaren Domain.

Außerhalb der beiden großen Suiten ist der Handgriff derselbe, nur die Konsole liegt woanders — und genau dort verlieren Migrationen ihre Tage. Bei GoDaddy wie bei IONOS wird der Eintrag in der DNS-Oberfläche des Registrars gesetzt, die nicht immer ein eigenes DMARC-Feld bietet und die Eingabe als reinen TXT-Eintrag erzwingt; bei Infomaniak und bei Zoho Mail wird der DKIM-Selektor im Verwaltungsbereich erzeugt und anschließend von Hand in die Zone übertragen — mit dem Abschneiderisiko, das jeder lange Schlüssel mit sich bringt. Die Schwierigkeit ist nie konzeptioneller Natur: Sie liegt darin, wo sich die Schaltfläche versteckt.

Die Verifikation stützt sich nicht auf das Wort der Verwaltungskonsole, sondern auf eine echte Nachricht: ein Testversand an externe Postfächer bei mehreren Anbietern, dann die Lektüre des Headers Authentication-Results — dkim=pass allein genügt nicht; das d= der Signatur muss der versendenden Domain entsprechen. Dieses Alignment, und nur dieses, zählt für DMARC.

Dann kommt die Überlappungsphase: zwei bis vier Wochen, in denen beide Anbieter voll authentifiziert sind und die Migration in Wellen voranschreitet — zuerst eine Pilotabteilung, dann die Teams in Gruppen, die Anwendungen zuletzt. Jede Welle, die wechselt, wechselt zu einem Ziel, dessen SPF und DKIM bereits grün sind. Das ist der Kern der Methode: Der Beweis geht der Bewegung voraus.

Währenddessen: die RUA-Berichte, Tag für Tag

Sobald die Umstellung läuft, ändern die aggregierten Berichte (RUA) ihren Status: Vom wöchentlichen Dashboard werden sie zum täglichen Steuerungsinstrument. An jedem Morgen des Migrationsfensters finden ein paar einfache Fragen ihre Antwort in den Daten des Vortags. Verlagert sich das Volumen im Takt der Wellen von der alten Quelle zur neuen? Welche Flüsse hängen noch an der alten Infrastruktur — und sind sie identifiziert, eingeplant oder vergessen? Produziert der neue Anbieter noch Alignment-Fehler, das verräterische Zeichen einer Standard-Domain oder eines falsch eingestellten Rückwegs?

Die Berichte spielen auch ihre Rolle als Wachturm: Eine völlig unbekannte Quelle, die mitten in der Migration auftaucht, ist entweder ein vergessener interner Fluss, der wieder an die Oberfläche kommt, oder ein opportunistischer Fälschungsversuch — Betrüger lieben Übergangsphasen, in denen eine „IT-Abteilung"-Mail zur Ankündigung eines Mailsystem-Wechsels völlig plausibel wirkt. In beiden Fällen ist die Entdeckung am nächsten Tag unendlich mehr wert als die Entdeckung nach einem Monat.

Eine Fehlerspitze, konzentriert auf einen bestimmten Fluss, ist ein Stoppsignal: Die nächste Welle wartet, bis die Ursache verstanden und behoben ist. Diese Disziplin trennt eine gesteuerte Migration von einer erlittenen.

Die Policy eine Stufe herabsetzen: eine Abwägung, kein Reflex

Sollte die DMARC-Policy während des Fensters gelockert werden? Die ehrliche Antwort: manchmal, und nie standardmäßig. Eine Domain auf p=reject, deren Inventar Grauzonen lässt — schlecht kartierte Anwendungen, autonome Tochtergesellschaften, zweifelhafte DNS-Historie — kann für die Dauer des Umzugs legitim auf p=quarantine heruntergehen: Ein vergessener Fluss landet dann im Spam, wiederherstellbar, statt vernichtet zu werden.

_dmarc.beispiel.de.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:rua@beispiel.de"

Aber diese Herabstufung ist eine dokumentierte Abwägung, kein harmloser technischer Handgriff, denn sie öffnet für ihre gesamte Dauer ein Fälschungsfenster. Die Entscheidung verdient eine schriftliche Spur — Grund, Umfang, geplantes Rückkehrdatum — und der Wiederaufstieg zu p=reject ist fester Bestandteil des Migrationsplans, kein vages „später". Erwähnenswert: DMARCbis, der aktuelle Standard, hat das pct-Tag gestrichen, das früher eine schrittweise prozentuale Verschärfung erlaubte; die Policy-Stufen sind heute ganz oder gar nicht, und der Testmodus wird über das Flag t=y ausgedrückt. Eine Stufe herabzugehen ist also eine ganze Entscheidung, die als solche zu verantworten ist.

Der nützliche Vergleichspunkt: Eine Domain mit vollständigem Inventar und bewiesenem DKIM beim neuen Anbieter migriert bestens bei konstantem p=reject. Die Herabstufung kompensiert eine Sichtbarkeitslücke — die Vorbereitungsarbeit ersetzt sie nicht.

Danach: die Abschaltung des Altanbieters

Die Migration endet nicht, wenn der letzte Benutzer wechselt, sondern wenn der Altanbieter jede Versandmacht verloren hat. Diese zu oft vernachlässigte Bereinigung hat drei Teile. Zuerst SPF: Der Include des Alten wird entfernt, sobald dreißig Tage RUA-Berichte keinen legitimen Versand über seine Infrastruktur mehr zeigen. Dann DKIM: Die Selektoren des Altanbieters werden aus dem DNS widerrufen — herumliegende Signaturschlüssel sind Signaturmacht in der Hand eines Dritten, der nicht mehr unter Vertrag steht, genau das Risiko, das ein sauberer Wechsel der Signaturschlüssel abdeckt. Zuletzt die Zugänge: Dienstkonten, Anwendungspasswörter, ausgehende SMTP-Konnektoren, geteilte Postfächer und die „für den Übergang" angelegten temporären Weiterleitungen werden eines nach dem anderen geschlossen.

Eine schlecht bereinigte Domain schleppt jahrelang Phantom-Autorisierungen mit sich: einen SPF-Include, der den Versand an eine vergessene Infrastruktur delegiert, einen DKIM-Schlüssel, der bei einem längst verlassenen Anbieter aktiv bleibt. Genau diese Art von Altlast kommt, auf der Käuferseite, in der E-Mail-Vergangenheit einer gekauften Domain ans Licht — besser, nicht der Verkäufer zu sein, der sie hinterlassen hat.

Die klassischen Vergessenen: Drucker, Fachanwendungen, Aliasse

Drei Familien von Versendern entgehen den Migrationsplänen fast systematisch, weil kein Mensch sie je versenden sieht. Zuerst die Kopierer und Scanner: Die Funktion „Scan an E-Mail" ist mit authentifiziertem SMTP gegen den alten Server konfiguriert, mit einem Passwort, das vor fünf Jahren ein längst verschwundener Dienstleister gesetzt hat. An dem Tag, an dem das alte SMTP erlischt, hört das Scannen auf — und die Verbindung zur Mail-Migration wird nicht sofort hergestellt.

Dann die Fachanwendungen: das ERP, das die Rechnungen verschickt, das CRM, das die Mahnungen verschickt, das Monitoring, das die Alarme verschickt, die Backups, die ihre nächtlichen Zusammenfassungen senden, die geplanten Skripte eines längst gegangenen Entwicklers. Jede trägt SMTP-Zugangsdaten aus der alten Welt in sich. Das typische Symptom ist verzögert: Drei Wochen lang funktioniert alles, dann scheitern die vierteljährlichen Zahlungserinnerungen massenhaft — weil genau dieser Fluss nur einmal pro Quartal feuert.

Zuletzt die Aliasse und Weiterleitungen: Eine Weiterleitung versendet die Nachricht von der weiterleitenden Infrastruktur neu, was SPF stromabwärts bricht; nur eine intakte DKIM-Signatur hält die Authentifizierung dann am Leben. Eine Migration zeichnet diese Umleitungswege neu, und ein historischer Alias kann von einem Fall „DKIM überlebt" in einen Fall „nichts kommt mehr durch" rutschen. Die RUA-Berichte der Überlappungsphase sind der einzige Ort, an dem diese stillen Flüsse sichtbar werden.

Die Checkliste zum Migrationsabschluss

Eine Migration ist abgeschlossen, wenn jede Zeile dieser Liste ein festgestellter Zustand ist — keine Absicht:

der SPF-Include des Altanbieters ist entfernt, und der DNS-Abfragezähler nach dem Entfernen erneut geprüft;
die DKIM-Selektoren des Altanbieters sind aus dem DNS widerrufen, mit protokolliertem Widerrufsdatum;
die Dienstkonten, Anwendungspasswörter und SMTP-Konnektoren der alten Infrastruktur sind geschlossen;
dreißig Tage RUA-Berichte zeigen keinerlei Versand mehr über den Altanbieter;
die DMARC-Policy steht wieder auf ihrem vorherigen Niveau, falls sie herabgesetzt war, und die Abwägung ist archiviert;
das Versender-Inventar ist aktuell, Kopierer, Fachanwendungen und Aliasse eingeschlossen;
die DNS-Dokumentation spiegelt den Endzustand: ein entschlacktes SPF, die aktiven Selektoren, der DMARC-Eintrag.

Sieben Zeilen, keine davon heroisch; ihre einzige Schwierigkeit besteht darin, schriftlich zu existieren und zu einem festen Datum geprüft zu werden statt „irgendwann".

Fazit

Eine Mail-Migration bricht DMARC, wenn sie in der falschen Reihenfolge gespielt wird: SPF ersetzt statt erweitert, DKIM nie bewiesen, Altanbieter zu früh gekappt oder nie bereinigt. Die sichere Sequenz kehrt die Beweislast um: Vor der Umstellung lässt ein additives SPF beide Anbieter koexistieren, und das DKIM des neuen wird an echten Nachrichten verifiziert; währenddessen werden die RUA-Berichte täglich gelesen, und die Policy geht nur nach dokumentierter Abwägung eine Stufe herunter, mit Rückkehrdatum; danach verliert der Altanbieter methodisch jede Versandmacht — Include entfernt, Schlüssel widerrufen, Konten geschlossen. Die Kopierer, die Fachanwendungen und die Weiterleitungs-Aliasse sind die Vergessenen, die ganz allein entscheiden, ob die Migration gut endet.

Der richtige Ausgangspunkt hängt an keinem Umstellungskalender: Eine kostenlose DMARC-Analyse der Domain zeigt, noch bevor ein Datum gewählt ist, wer wirklich in ihrem Namen versendet und was die Migration bewahren muss. Und um das Überlappungsfenster anhand der Tagesberichte statt im Blindflug zu steuern, gibt die Eröffnung eines Kontos der Migration das Instrument, das ihr am häufigsten fehlt: den Beweis, Tag für Tag, dass nichts zerbrochen ist.