DKIM schlägt nach dem Wechsel des E-Mail-Tools fehl: der CNAME- und Selektor-Migrationsleitfaden (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.

DKIM bricht nach einem Tool-Wechsel aus zwei mechanischen Gründen: Ihr DNS-Panel hat die CNAME-Ziele des neuen Tools verstümmelt — meist durch Anhängen Ihrer eigenen Zone —, oder die Selektoren des alten Tools wurden entfernt, bevor dessen Mail ausgelaufen war. Nur 3,87% der Domains — 10.092.481 — vervollständigen die SPF+DKIM+DMARC-Trias, laut dem Defaults.Exposed-Zensus über 261.086.232 bewertete Domains.

Die Fix-Reihenfolge: Domain scannen, dann bei jedem neuen CNAME das gespeicherte Ziel mit dig prüfen — ein Ziel, das auf Ihren eigenen Domainnamen endet, ist der rauchende Colt. Reparieren Sie die Einträge an den autoritativen Nameservern, bestätigen Sie, dass das neue Tool signiert und besteht, bevor Sie echte Mail darüber leiten, und lassen Sie die Selektoren des alten Tools veröffentlicht, bis dessen Verkehr ausgelaufen ist.

Warum ist DKIM beim Tool-Wechsel kaputtgegangen?

An DKIM selbst hat sich nichts geändert — an Ihren Selektoren schon. Das alte Tool signierte mit seinen Selektoren; das neue signiert mit anderen, meist delegiert über zwei oder drei CNAME-Einträge, die beim Onboarding hinzugefügt werden. Vier Fallstricke erklären fast jeden DKIM-Fehler nach einer Migration:

Ihr DNS-Panel hat Ihre Zone an das CNAME-Ziel angehängt. Viele Panels behandeln jeden eingefügten Hostnamen als relativ und speichern stillschweigend target.provider.com.yourdomain.com statt target.provider.com. Der Eintrag existiert, das Panel zeigt einen grünen Haken, und er löst zu nichts auf.
Verwirrung um den abschließenden Punkt. Manche Panels verlangen einen abschließenden Punkt (target.provider.com.) als „absolut — häng nicht meine Zone an“; andere weisen den Punkt als ungültig zurück und regeln die Absolutheit selbst. Derselbe eingefügte Wert ist im einen Panel richtig und im nächsten verstümmelt.
Die Selektoren des alten Tools wurden am Umschalttag gelöscht. Mail, die das alte Tool bereits signiert hat, liegt tagelang in Retry-Queues und Weiterleitungspfaden; das Entfernen seiner Selektoren — oder das Schließen des alten Kontos, was dessen delegierte CNAMEs killt — bricht diese Mail rückwirkend.
Sie haben an den falschen Nameservern verifiziert. Wenn die Migration einen Nameserverwechsel einschloss, können die reparierten Einträge an einem NS-Set existieren, während Empfänger noch das andere abfragen.

Nur 51,84% der 261 Millionen Domains im Zensus präsentieren zum Scan-Zeitpunkt einen auffindbaren DKIM-Schlüssel (Stand der Daten: 2026-06-29).

Dieselbe Migration hinterlässt meist auch SPF-Trümmer — 1.013.416 Domains, rund 1 von 138 derjenigen, die SPF versuchen, betreiben zwei v=spf1-Einträge, das klassische Zeichen dafür, dass ein Providerwechsel einen Eintrag hinzugefügt statt zusammengeführt hat. Diese Seite des Umzugs hat einen eigenen Leitfaden: SPF funktioniert nicht mehr, seit Sie den E-Mail-Provider gewechselt haben.

Wie erkenne ich einen verstümmelten CNAME-Eintrag?

Trauen Sie nicht dem Panel — fragen Sie das DNS, was es tatsächlich gespeichert hat. Fragen Sie das CNAME-Ziel für jeden Selektor ab, den das neue Tool Ihnen gegeben hat. Ein illustratives Beispiel im Stil eines delegierten SendGrid-Selektors (die Zielform Ihres Providers wird abweichen):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Der Provider hat s1.domainkey.u1234567.wl123.sendgrid.net verlangt — aber das gespeicherte Ziel endet auf .yourdomain.com. Das Panel hat die Zone angehängt; dieser Name löst zu nichts auf, also finden Empfänger keinen Schlüssel. Die gesunde Version:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Ein einzelner abschließender Punkt in der dig-Ausgabe ist normal — er markiert einen vollqualifizierten Namen.) Wenn das Ziel stimmt, folgen Sie ihm einen Hop weiter: dig TXT s1._domainkey.yourdomain.com +short sollte den Schlüssel des Providers zurückgeben. Eine leere Antwort bei korrektem CNAME bedeutet, dass das Problem auf der Providerseite der Delegation liegt — schließen Sie dessen Verifikationsschritt ab, oder siehe DKIM „no key for signature“ für die Diagnose auf Selektorebene.

Das Migrations-Runbook: vorher, währenddessen, danach

Der Fehler liegt meist nicht in den Einträgen — sondern in der Reihenfolge. DKIM-Migrationen scheitern am Umschaltpunkt, weil die Verifikation nach dem Wechsel stattfindet, wenn echte Mail bereits fehlschlägt.

Phase	Was zu tun ist	Gate vor dem Weitergehen
Vor dem Wechsel	Fügen Sie die DKIM-CNAMEs des neuen Tools hinzu (und die Bounce-Domain-Einträge), dann beweisen Sie sie: `dig` auf das gespeicherte Ziel jedes CNAME von außerhalb Ihres Netzes, den eigenen Verifikationsschritt des Tools abschließen und einen Test über das neue Tool an ein Postfach unter Ihrer Kontrolle senden	Testnachricht zeigt `dkim=pass` mit `d=` = Ihre Domain — leiten Sie nie echte Mail über ein unverifiziertes Tool
Umschalttag	Verlagern Sie den echten Verkehr auf das neue Tool. Fassen Sie nichts an, was dem alten Tool gehört: Selektoren, CNAMEs und Konto am Leben lassen	Mail des neuen Tools besteht bei echten Empfängern; das alte Tool besteht weiter für alles, was noch darüber fließt
Nach dem Auslaufen	Beobachten Sie die DMARC-Aggregatberichte, bis die Selektoren des alten Tools nicht mehr auftauchen (Retry-Queues und Weiterleitungen laufen tagelang — rechnen Sie mit einer Woche oder mehr), und ziehen Sie dann dessen Einträge und Konto zurück	Alte Selektoren ≥ 7 Tage aus den Berichten verschwunden, bevor Sie entfernen

Die fette Zeile ist der Ort, an dem Migrationen gerettet oder verloren werden: Jede Prüfung darin lässt sich Tage vor dem Umschalten erledigen, mit null Risiko für die laufende Mail. Die Mechanik des Selektor-Rückzugs — einschließlich der Frage, warum das Neuveröffentlichen mit leerem p= dem Löschen überlegen ist — behandelt das Rotations-Runbook; in dieser Tabelle geht es um die Reihenfolge des Tool-Wechsels selbst.

Wie repariere ich DKIM nach dem Wechsel?

Führen Sie den kostenlosen Scan bei defaults.exposed durch, bevor Sie das DNS anfassen. Er liest Ihre Live-Einträge und zeigt, was Empfänger tatsächlich sehen — einschließlich CNAME-Zielen, an die die Zone angehängt wurde, und Selektoren, die nicht auflösen.
Listen Sie die DKIM-Einträge auf, die das neue Tool erwartet. Aus dessen Admin-Konsole — für Postfach-Provider zeigen die Einrichtungsanleitungen für Google Workspace und Microsoft 365, wo; Newsletter- und CRM-Tools listen ihre CNAMEs unter Domain-Authentifizierung (siehe Mailchimp/Brevo/Klaviyo-Mails scheitern an DMARC).
Prüfen Sie den gespeicherten Wert jedes Eintrags mit dig CNAME <name> +short und vergleichen Sie ihn Zeichen für Zeichen mit dem, was das Tool verlangt hat. Ein Ziel, das auf Ihre eigene Domain endet = zonen-angehängt; geben Sie es neu ein, und wenn das Panel weiter anhängt, ergänzen Sie den abschließenden Punkt (oder entfernen Sie ihn, wenn das Panel Punkte ablehnt).
Verifizieren Sie an den autoritativen Nameservern. dig +short NS yourdomain.com, dann wiederholen Sie die CNAME-Prüfungen @<dieser Nameserver>. Wenn die Migration die Nameserver geändert hat, prüfen Sie beide Sets — Empfänger fragen möglicherweise noch das alte ab, bis die Delegation propagiert ist.
Führen Sie die Verifikation des Tools erneut aus und senden Sie eine Testnachricht. Der Authentication-Results-Header sollte dkim=pass mit d= gleich Ihrer Domain zeigen — ein Bestehen auf der Standarddomain des Tools ist für DMARC nicht ausgerichtet.
Lassen Sie die Selektoren des alten Tools veröffentlicht, bis dessen Mail ausgelaufen ist, und ziehen Sie sie dann gezielt zurück. Scannen Sie anschließend erneut und arbeiten Sie alles Weitere ab, was auf der Seite DKIM reparieren markiert ist.

Häufig gestellte Fragen

Brauche ich den abschließenden Punkt an meinem DKIM-CNAME oder nicht? Das hängt vollständig vom Panel ab. Der Punkt bedeutet „absoluter Name — häng nicht meine Zone an“; manche Panels verlangen ihn, manche ergänzen ihn für Sie, manche lehnen ihn ab. Der einzige Test, der zählt, ist die Ausgabe von dig CNAME <selector>._domainkey.yourdomain.com +short nach dem Speichern: Endet das Ziel auf Ihrer eigenen Domain, hat das Panel die Zone angehängt, und Sie brauchen den Punkt (oder ein anderes Eingabeformat).

Kann ich die DKIM-Einträge des alten Tools am Umschalttag löschen? Nein. Mail, die das alte Tool signiert hat, steckt noch in Retry-Queues und Weiterleitungspfaden, und das Löschen des Schlüssels, auf den sie zeigt, bricht diese Nachrichten rückwirkend. Halten Sie die alten Selektoren live, bis sie nicht mehr in Ihren DMARC-Aggregatberichten auftauchen — eine Woche oder länger —, und schließen Sie bis dahin auch nicht das alte Konto.

Mein DNS-Panel und das neue Tool sagen beide „verifiziert“, aber Empfänger lassen DKIM weiter durchfallen. Wie das? Zwei häufige Fälle: Das Tool hat gegen eine zwischengespeicherte Prüfung verifiziert, während die autoritativen Nameserver etwas anderes ausliefern (fragen Sie sie direkt mit dig @<ns> ab), oder DKIM besteht, aber auf der Standard-Signierdomain des Tools statt Ihrer, sodass DMARC weiterhin am Alignment scheitert. Der Scan unterscheidet die beiden.

Können die DKIM-Einträge beider Tools während der Überlappung koexistieren? Ja — und sie sollten es. DKIM kennt keine Ein-Eintrag-Regel: Jeder Selektor ist ein eigener DNS-Name, sodass die Einträge beider Tools konfliktfrei nebeneinander leben — was die Regel „alte Selektoren bis zum Auslaufen behalten“ kostenlos befolgbar macht. (SPF ist das Gegenteil — zwei v=spf1-Einträge machen es ungültig, weshalb es im SPF-Migrationsleitfaden ums Zusammenführen geht.)

Senden Sie dem Inhaber den Bericht

Wenn Sie diese Migration für einen Kunden oder Ihren Arbeitgeber durchführen, schließen Sie sie mit einem Beleg ab. Sobald das neue Tool signiert und ausrichtet, führen Sie den kostenlosen Scan erneut durch und leiten Sie den bewerteten Bericht an den Geschäftsinhaber weiter: ein datierter Nachweis in klarer Sprache, dass der Wechsel die Domain vollständig authentifiziert hinterlassen hat. Das ist das Dokument, das er für die Cyberversicherungs-Verlängerung und den nächsten Lieferanten-Sicherheitsfragebogen braucht — es macht aus „die Migration ist fertig“ eine Behauptung mit Beleg.

Prüfen Sie Ihr DKIM kostenlos

Sehen Sie, ob die Selektoren Ihres neuen Tools auflösen — und was genau zu reparieren ist — privat und nur für den Inhaber.

Prüfen Sie Ihre Domain → · SPF nach Providerwechsel kaputt → · DKIM reparieren → · DKIM auf Google Workspace einrichten → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.