DKIM „No Key for Signature“: Selektor- und Rotations-Fixes (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.

„No key for signature“ bedeutet: Der Empfänger hat den DNS-Eintrag abgefragt, auf den Ihre DKIM-Signatur zeigt — selector._domainkey.yourdomain — und keinen Schlüssel gefunden: Er wurde nie veröffentlicht oder mitten in einer Rotation gelöscht. Veröffentlichen Sie den Selektor, den Ihr Signierer tatsächlich nutzt. Nur 10.092.481 Domains — 3,87% — vervollständigen die SPF+DKIM+DMARC-Trias, laut dem Defaults.Exposed-Zensus über 261.086.232 bewertete Domains.

Der Fix ist ein DNS-Eintrag, gefunden in einem Header. Lesen Sie die Tags s= und d= aus einem echten DKIM-Signature-Header, um zu erfahren, mit welchem Selektor Ihre Mail signiert wird, veröffentlichen (oder reparieren) Sie exakt diesen Eintrag, und bevorzugen Sie CNAME-Delegation, damit Ihr Provider die Schlüssel für Sie rotiert. Rotieren Sie dann nach dem Runbook unten — dieser Fehler bedeutet meist, dass jemand einen alten Selektor zu früh gelöscht hat.

Was bedeutet „dkim no key for signature“?

Jede DKIM-Signatur trägt zwei Tags, die dem Empfänger sagen, wo er den öffentlichen Schlüssel holen soll: d= (Signierdomain) und s= (Selektor). Der Empfänger fragt einen daraus gebauten DNS-Namen ab — s._domainkey.d — nach dem Schlüssel. „No key for signature“ bedeutet: Diese Abfrage kam leer zurück — die Signatur existiert, aber der Schlüssel, den sie benennt, nicht.

Der Wortlaut erscheint in Authentication-Results-Headern und DMARC-Aggregatberichten — die genaue Formulierung variiert je Empfänger, aber zwei Varianten zählen:

Ergebnis-String (Fragment, wie verbreitet beobachtet)	Was tatsächlich passiert ist	Vorübergehend?
`dkim=temperror (no key for signature)`	Die DNS-Abfrage ist fehlgeschlagen oder in einen Timeout gelaufen — der Empfänger bekam gar keine Antwort	Ja — Wiederholungen bestehen oft; nur bei Beharrlichkeit untersuchen
`dkim=permerror (no key for signature)`	Die DNS-Abfrage war erfolgreich und die Antwort lautete „no such record“ — der Selektor fehlt tatsächlich	Nein — der Eintrag fehlt, bis Sie ihn veröffentlichen

Ein einmaliger temperror ist DNS-Wetter. Ein permerror — oder ein temperror, der sich über Tage und Empfänger hinweg wiederholt — bedeutet, dass der Eintrag, auf den die Signatur zeigt, nicht in Ihrer Zone steht. Darum geht es in diesem Leitfaden.

Die Konsequenz: Eine nicht verifizierbare Signatur zählt wie gar kein DKIM, sodass DMARC auf SPF allein zurückfällt — und SPF bricht bei Weiterleitungen. Wenn die Signatur vorhanden, aber ungültig statt fehlend ist (Body-Hash, verstümmelter Schlüssel), ist das ein anderer Fehler — siehe „DKIM signature not valid“.

Wie finde ich heraus, mit welchem Selektor meine Mail signiert wird?

Raten Sie nicht anhand der Dokumentation Ihres Providers — lesen Sie es aus einer echten Nachricht:

Senden Sie eine Nachricht vom betroffenen System an ein Postfach unter Ihrer Kontrolle (eine Gmail-Adresse eignet sich gut).
Öffnen Sie den Rohquelltext („Original anzeigen“ in Gmail, „Nachrichtenquelle anzeigen“ in Outlook).
Suchen Sie den DKIM-Signature:-Header und lesen Sie zwei Tags: s= ist der Selektor, d= die Signierdomain. Ein illustratives Beispiel: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
Der Eintrag, den der Empfänger abfragt, ist s._domainkey.d — hier mail2026._domainkey.yourdomain.com. Prüfen Sie ihn selbst: dig TXT mail2026._domainkey.yourdomain.com +short. Leere Antwort = der Fehler ist für jeden Empfänger real.
Wiederholen Sie das pro Sendesystem. Eine Nachricht kann mehrere DKIM-Signaturen tragen — Postfach-Provider, Newsletter-Tool, Helpdesk — jede mit eigenem s=/d=-Paar und Eintrag. Reparieren Sie die fehlschlagende, und beachten Sie ihr d=: Nur eine Signatur, deren d= mit Ihrer From-Domain übereinstimmt, hilft DMARC.

Warum fehlt der Selektor-Eintrag?

Vier Ursachen erklären fast alle diese Fehler — prüfen Sie sie in dieser Reihenfolge:

Er wurde nie veröffentlicht. Der Signierer wurde eingeschaltet (oder war standardmäßig an) mit einem Selektor, den niemand ins DNS eingetragen hat. Häufig bei neuen Tools und Gateways, die unerwartet signieren.
Er wurde mitten in einer Rotation gelöscht. Jemand hat den alten Selektor „aufgeräumt“, während damit signierte Nachrichten noch unterwegs, in Retry-Queues oder in Weiterleitung waren. Diese Mail ist bereits mit s=old signiert; das Löschen von old._domainkey bricht rückwirkend jede einzelne dieser Nachrichten.
Ihre DNS-Oberfläche hat ein CNAME-Ziel verstümmelt. Viele Provider delegieren per CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), und viele DNS-Panels hängen stillschweigend Ihre Zone an das Ziel — gespeichert wird s1.domainkey.u123.esp.com.yourdomain.com, was zu nichts auflöst. Verifizieren Sie das Ziel: dig CNAME s1._domainkey.yourdomain.com +short. Dieselbe Falle schnappt bei Tool-Migrationen zu — siehe DKIM schlägt nach dem Wechsel des E-Mail-Tools fehl.
Der Provider hat rotiert, Ihre Zone nicht. Ein als statischer TXT-Eintrag eingefügter Provider-Schlüssel (statt der CNAMEs) wird von dessen planmäßiger Rotation verwaist — der Signierer wechselt zu einem Selektor, den Sie nie veröffentlicht haben. 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).

Wie behebe ich „no key for signature“?

Führen Sie den kostenlosen Scan bei defaults.exposed durch, bevor Sie das DNS anfassen. Er liest Ihre Live-DKIM-, SPF- und DMARC-Einträge und zeigt, was Empfänger tatsächlich sehen — einschließlich der Frage, ob der Selektor auflöst und ob ein CNAME-Ziel verstümmelt wurde.
Veröffentlichen Sie den Selektor, den der Signierer tatsächlich nutzt — den s=-Wert aus dem Header, nicht den aus einem alten Runbook. Holen Sie den Eintrag aus der Admin-Konsole Ihres Providers (DKIM-Einrichtung für Google Workspace · DKIM-Einrichtung für Microsoft 365) und fügen Sie ihn exakt unter s._domainkey.yourdomain.com hinzu.
Bevorzugen Sie CNAME-Delegation gegenüber dem Einfügen eines TXT-Schlüssels. Wenn Ihr Provider DKIM-CNAMEs anbietet, nutzen Sie sie: Der Schlüssel lebt in dessen Zone, sodass er rotiert wird, ohne dass Sie das DNS je wieder anfassen — Ursache 4 wird unmöglich. Newsletter-Plattformen arbeiten fast alle so; siehe Mailchimp/Brevo/Klaviyo-Mails scheitern an DMARC.
Verifizieren Sie von außerhalb Ihres Panels. dig TXT s._domainkey.yourdomain.com +short (oder dig CNAME … für delegierte Selektoren) von einer Maschine außerhalb Ihres Netzes. Dass das Panel den Eintrag anzeigt, beweist nichts, wenn die Zone etwas anderes ausliefert.
Erneut scannen und die Testnachricht erneut senden. Authentication-Results sollte jetzt dkim=pass zeigen. Arbeiten Sie dann alles Weitere ab, was der Scan auf der Seite DKIM reparieren markiert — eine bestehende Signatur ohne Alignment mit Ihrer From-Domain scheitert weiterhin an DMARC.

Wie rotiere ich DKIM-Schlüssel, ohne diesen Fehler zu verursachen?

Bei der Rotation gehen funktionierende Setups kaputt. Die Regel, die das verhindert: Ein Selektor wird erst gelöscht, wenn die letzte damit signierte Nachricht ausgelaufen ist — nie beim Umschalten. Signierte Mail lebt länger, als Sie denken: Retry-Queues laufen tagelang, und weitergeleitete Nachrichten werden bei jeder Bewegung neu verifiziert.

Schritt	Aktion	Gate vor dem nächsten Schritt
1. Hinzufügen	Veröffentlichen Sie den neuen Selektor (`s2._domainkey…`) neben dem alten	`dig` bestätigt, dass er von außen auflöst
2. Umschalten	Richten Sie den Signierer auf den neuen Selektor	Testnachricht zeigt `s=s2` und `dkim=pass`
3. Warten	Lassen Sie den alten Selektor veröffentlicht, während unterwegs befindlicher, gequeueter und weitergeleiteter Verkehr ausläuft	≥ 7 Tage; DMARC-Aggregatberichte beobachten, bis der alte Selektor nicht mehr auftaucht
4. Zurückziehen	Entfernen Sie den alten Schlüssel — oder besser: Veröffentlichen Sie ihn mit leerem `p=`-Tag neu: „im Ruhestand“, nicht „nie existiert“	Beginnen Sie damit nie beim Umschalten — vorzeitiges Löschen ist Ursache Nr. 1 für „no key for signature“

Mit CNAME-Delegation fährt Ihr Provider genau dieses Runbook in seiner eigenen Zone, und Sie bekommen es nie zu sehen — das stärkste Argument fürs Delegieren.

Häufig gestellte Fragen

Ist „no key for signature“ ein temperror oder ein permerror? Beide Strings existieren: temperror ist ein DNS-Lookup, der fehlschlug oder in einen Timeout lief — vorübergehend, beim Wiederholen oft verschwunden —, während permerror bedeutet, dass DNS mit „no such record“ geantwortet hat. Ein temperror, der sich über Empfänger hinweg wiederholt, entpuppt sich meist ebenfalls als tatsächlich fehlender Eintrag. Prüfen Sie mit dig und vertrauen Sie der Antwort, nicht dem Etikett.

Bedeutet dieser Fehler, dass jemand meine Domain spooft? Nein — ein Spoofer würde nicht mit Ihrem Selektor signieren. Er bedeutet, dass Ihre eigene Mail eine Signatur trägt, die Empfänger nicht verifizieren können; sie zählt also als unsigniert, und DMARC stützt sich auf SPF allein. Vollständige, ausgerichtete Authentifizierung ist selten: Nur 10.092.481 von 261.086.232 Domains (3,87%) haben im Defaults.Exposed-Zensus die SPF+DKIM+DMARC-Trias vervollständigt (Stand der Daten: 2026-06-29).

Kann ich den alten Selektor einfach löschen, sobald der neue funktioniert? Nicht sofort. Damit signierte Nachrichten stecken noch in Retry-Queues und Weiterleitungspfaden; das Löschen des Schlüssels bricht sie rückwirkend. Behalten Sie den alten Eintrag mindestens eine Woche, beobachten Sie Ihre DMARC-Berichte, bis der alte Selektor nicht mehr auftaucht, und ziehen Sie ihn dann zurück — idealerweise mit leerem p= statt Löschung.

Der Checker meines Providers sagt, DKIM sei konfiguriert, aber Empfänger melden weiter „no key“. Wie das? Fast immer die CNAME-Ziel-Falle: Ihr DNS-Panel hat Ihre Zone an das Ziel angehängt (…esp.com.yourdomain.com), sodass der Eintrag existiert, aber ins Leere zeigt. dig CNAME selector._domainkey.yourdomain.com +short zeigt das gespeicherte Ziel wortwörtlich — vergleichen Sie es Zeichen für Zeichen mit dem, was der Provider verlangt hat.

Senden Sie dem Inhaber den Bericht

Wenn Sie das für einen Kunden oder Ihren Arbeitgeber beheben, schließen Sie den Kreis mit einem Beleg. Führen Sie den kostenlosen Scan erneut durch, sobald der Selektor auflöst, und leiten Sie den bewerteten Bericht an den Geschäftsinhaber weiter: datiert, in klarer Sprache, DKIM verifiziert jetzt. Das ist das Dokument, das er für die Cyberversicherungs-Verlängerung und den nächsten Lieferanten-Sicherheitsfragebogen braucht — der Nachweis einer funktionierenden Kontrolle, nicht nur ein geschlossenes Ticket.

Prüfen Sie Ihr DKIM kostenlos

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

Prüfen Sie Ihre Domain → · „DKIM signature not valid“ → · DKIM reparieren → · DKIM auf Google Workspace einrichten → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.