SPF funktioniert nicht mehr, nachdem Sie den E-Mail-Anbieter gewechselt haben — die Migrations-Lösung (2026)

Veröffentlicht 2026-07-08

Zahlen mit Stand 2026-06-29 · Methodik v7. Aggregierte Zensusdaten über 261 Millionen bewertete Domains. Siehe wie wir bewerten.

SPF bricht nach einem E-Mail-Anbieterwechsel meist, weil der Eintrag des neuen Anbieters neben den alten gesetzt wurde. Zwei v=spf1-Einträge sind ein permanenter Fehler — SPF wird vollständig ungültig. 1.013.416 Domains — etwa eine von 138 unter denen, die SPF versuchen — stecken in diesem Zustand, laut dem Defaults.Exposed-Zensus über 261 Millionen Domains. Führen Sie sie zu einem zusammen.

Die Lösung dauert etwa zehn Minuten: Scannen Sie die Domain, um genau zu sehen, was die Migration hinterlassen hat, listen Sie jeden SPF-Eintrag an Ihren autoritativen Nameservern auf, führen Sie sie zu einem einzigen Eintrag zusammen, der nur Ihren neuen Anbieter enthält, und verifizieren Sie erneut mit dig. Dieser Leitfaden geht jeden Schritt durch, plus die DKIM- und Nameserver-Prüfungen, die die meisten Migrationen vergessen.

Warum ist SPF direkt nach der Migration kaputtgegangen?

Weil die Einrichtungsanleitung des neuen Anbieters „fügen Sie diesen TXT-Eintrag hinzu“ sagte — und Sie das taten, neben dem alten. Das ist genau das eine, was der SPF-Standard nicht erlaubt. RFC 7208 (§3.2, Fehlerergebnis vorgeschrieben in §4.5) erlaubt genau einen v=spf1-Eintrag pro Domain; ein Empfänger, der zwei oder mehr findet, muss PermError zurückgeben, statt zu raten, welcher maßgeblich ist. PermError bedeutet, SPF ist ungültig: weder der alte Eintrag noch der neue, überhaupt kein SPF.

Und es endet dort nicht. DMARC behandelt einen PermError als Scheitern auf dem SPF-Bein, also hängt Ihre Mail jetzt vollständig von DKIM ab. Ist das DKIM des neuen Anbieters ebenfalls noch nicht eingerichtet — mitten in der Migration üblich —, senden Sie genau in dem Moment unauthentifiziert, in dem Sie Ihre Infrastruktur geändert haben, also gerade dann, wenn Empfänger Sie am schärfsten prüfen.

Das ist der Copy-Paste, der den Schutz beim Anbieterwechsel zunichtemacht, und es ist nicht selten: 1.013.416 Domains veröffentlichen gerade jetzt zwei oder mehr SPF-Einträge — etwa eine von 138 der 139-Millionen-starken Population, die SPF versucht, laut dem Defaults.Exposed-Zensus über 261 Millionen Domains (Datenstand 2026-06-29). Die vollständigen Zahlen zur Zwei-Einträge-Falle haben einen eigenen Bericht; diese Seite ist die verfahrenstechnische Lösung.

Was hat die Migration hinterlassen?

Fünf Überbleibsel verursachen fast jeden Post-Migrations-SPF-Fehler. Prüfen Sie sie in dieser Reihenfolge:

Was zurückgelassen wurde	Was Sie sehen	Die Lösung
Der alte SPF-Eintrag, noch im DNS neben dem neuen (zwei `v=spf1`-Einträge)	Checker melden „mehrere SPF-Einträge“ oder PermError; SPF funktioniert überhaupt nicht mehr	Zu einem Eintrag zusammenführen, den Rest löschen — Schritte unten
`include:` des alten Anbieters innerhalb Ihres einen Eintrags	SPF funktioniert, aber Sie verschwenden DNS-Lookups, und die Server des alten Anbieters können noch als Sie senden	Entfernen, sobald die Mail vollständig vom alten System ausgelaufen ist
`include:` des neuen Anbieters nie hinzugefügt	Mail vom neuen Anbieter scheitert bei Empfängern an SPF	Zum einzigen bestehenden Eintrag hinzufügen — nie als neuer Eintrag
DKIM-Selektoren für den neuen Anbieter nicht erstellt	`dkim=fail` oder Signaturen von der Standarddomain des Anbieters; DMARC hat kein zweites Bein	Die neuen Selektoren veröffentlichen — Schritt 6 unten
Eintrag nur bei den alten Nameservern aktualisiert	Unterschiedliche Antworten, je nachdem, wen man fragt; sporadische Fehler	Die Zone bei den autoritativen Nameservern reparieren; beide Sätze während der Umstellung prüfen

Wie repariere ich es? Die Migrations-Checkliste

Führen Sie zuerst den kostenlosen Scan bei defaults.exposed durch. Er liest Ihr live DNS und sagt Ihnen, ob Sie mehrere SPF-Einträge, einen fehlenden Include oder eine DKIM-Lücke haben — diagnostizieren, bevor Sie irgendetwas anfassen.
Listen Sie jeden SPF-Eintrag an den autoritativen Nameservern auf. dig +short NS ihredomain.com, dann dig +short TXT ihredomain.com @<nameserver> gegen einen davon. Zählen Sie die mit v=spf1 beginnenden Strings. Die einzig sichere Zahl ist 1.
Zusammenführen zu einem einzigen Eintrag. Ein Eintrag, beginnend mit v=spf1, der den Include Ihres neuen Anbieters und jeden anderen Absender enthält, den Sie noch nutzen (Rechnungstool, CRM, Newsletter-Plattform), ein einziges abschließendes -all oder ~all. Beispiel — altes Google Workspace, neues Microsoft 365, mitten im Auslaufen:
```
Before:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Later:   "v=spf1 include:spf.protection.outlook.com -all"
```
Anbieterwerte und DNS-Panel-Eigenheiten stehen in den Einrichtungsanleitungen für Google Workspace und Microsoft 365.
Löschen Sie die überzähligen Einträge. Zusammenführen ohne Löschen behebt nichts — der PermError kommt von der Anzahl.
Behalten Sie den Include des alten Anbieters nur, solange das alte System noch sendet — geplante Berichte, ein alter CRM-Connector, eine vergessene Mailbox. Ist das Auslaufen abgeschlossen, entfernen Sie ihn: Ein veralteter Include lässt die alte Infrastruktur weiter berechtigt, als Sie zu senden, und jeder Include kostet DNS-Lookups gegen SPFs harte Obergrenze von 10 — mindestens 797.263 Domains haben SPF durch Überschreiten dieser Grenze ungültig gemacht (Zensus, 2026-06-29).
Richten Sie das DKIM des neuen Anbieters ein — und löschen Sie die alten Selektoren noch nicht. Neue Selektoren signieren neue Mail; alte Selektoren müssen veröffentlicht bleiben, bis jede damit signierte Nachricht zugestellt und alle Weiterleitungen abgeschlossen sind. Vollständige Anleitung in DKIM scheitert nach Wechsel der E-Mail-Tools.
Haben Sie auch die Nameserver gewechselt, prüfen Sie beide. DNS-Migrationen laufen oft parallel zu E-Mail-Migrationen. Fragen Sie den alten und den neuen NS-Satz direkt ab (dig TXT ihredomain.com @alter-ns und @neuer-ns) — bis die Registrar-Delegation vollständig propagiert ist, fragen manche Empfänger noch die alten Server, also muss der reparierte Eintrag bei welchem Satz auch immer antwortet vorhanden sein.
Führen Sie den Scan erneut durch und bestätigen Sie, dass SPF einen einzigen gültigen Eintrag mit einem Bestehen zeigt.

Welche Domain prüft SPF eigentlich?

Empfänger bewerten SPF gegen die Return-Path-Domain (RFC5321.MailFrom) — die Bounce-Adresse —, nicht den From-Header, den Ihre Empfänger sehen. Nach einer Migration zählt das doppelt: Ihr neuer Anbieter nutzt möglicherweise seine eigene Bounce-Domain, bis Sie eine eigene konfigurieren, und ein SPF-„Bestehen“ auf einer Domain, die nicht Ihre ist, aligned nicht für DMARC. Die Lösung dafür ist das DKIM des neuen Anbieters, signiert mit Ihrer Domain.

Migrieren und gleichzeitig umbenennen?

Auch die Domain gewechselt, nicht nur den Anbieter? Behandeln Sie es als zwei Aufgaben. Die neue Domain braucht den vollen Stack — SPF, DKIM, DMARC — vom ersten Tag an; nutzen Sie die Checkliste für neue Domains. Die alte Domain bleibt authentifiziert, solange Weiterleitungs- oder Antwortverkehr über sie läuft, und wird explizit verriegelt (nicht nur aufgegeben), sobald sie geparkt ist. Eine alte Domain mit übrig gebliebenem, halb kaputtem SPF ist ein Spoofing-Ziel, das Ihren früheren Namen trägt.

Häufig gestellte Fragen

Kann ich während der Migration zwei SPF-Einträge behalten? Nein. Es gibt keine Karenzzeit im Standard — zwei v=spf1-Einträge sind ein PermError, sobald der zweite existiert, und 1.013.416 Domains stecken laut Zensus (2026-06-29) genau darin fest. Das migrationssichere Muster ist ein einziger Eintrag, der während der Überlappung die Includes beider Anbieter trägt.

Wie lange sollte ich den Include des alten Anbieters behalten? Bis nichts mehr über den alten Anbieter sendet — typischerweise die Länge Ihres Überlappungsfensters, Tage bis wenige Wochen. Beobachten Sie den Return-Path von allem, was noch über das alte System ankommt; hört dieser Verkehr auf, entfernen Sie den Include und prüfen Sie Ihre Lookup-Anzahl erneut.

Warum zeigt ein Checker meinen alten Eintrag noch, nachdem ich ihn repariert habe? DNS-Caching respektiert die TTL des Eintrags, und wenn sich Ihre Nameserver geändert haben, fragen manche Resolver noch den alten Satz. Verifizieren Sie direkt an den autoritativen Nameservern mit dig TXT ihredomain.com @<ns> — steht die richtige Antwort dort, ist die Reparatur fertig, und die Caches ziehen nach. Ist sie bei einem NS-Satz falsch, siehe „SPF record not found“ — die echten Ursachen.

Muss ich DMARC ändern, wenn ich den Anbieter wechsle? Meist nicht den Eintrag selbst — er nennt Ihre Berichts-Mailbox und Richtlinie, nicht Ihren Anbieter. Aber Ihre DMARC-Ergebnisse hängen von dem SPF und DKIM ab, das Sie gerade migriert haben: Erwarten Sie während der Umstellung einen Einbruch bei den Berichten, und bestätigen Sie, dass beide Beine bestehen, bevor Sie die Richtlinie verschärfen. Beginnen Sie bei SPF reparieren, wenn der Scan zeigt, dass das SPF-Bein noch scheitert.

Senden Sie dem Inhaber den Bericht

Wenn Sie diese Migration für einen Kunden durchführen, schließen Sie mit einem Beleg ab. Führen Sie den kostenlosen Scan erneut durch, sobald die Zusammenführung live ist, und leiten Sie den bewerteten Bericht an den Geschäftsinhaber weiter: SPF, DKIM und DMARC bestehen beim neuen Anbieter, in klarer Sprache, datiert. Das ist das Artefakt, das er für die Cyberversicherungs-Verlängerung und den nächsten Lieferanten-Sicherheitsfragebogen ablegt — der Beweis, dass die Migration die Domain besser authentifiziert zurückgelassen hat, als sie begonnen hat.

Prüfen Sie Ihre Domain → · DKIM scheitert nach Wechsel der E-Mail-Tools → · „SPF record not found“ — die echten Ursachen → · Wie wir bewerten → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.