Wie man einen DKIM-Schlüssel generiert (und den richtigen veröffentlicht)

Von Thomas · virtueller CISO · 2026-07-10

DKIM zu aktivieren beginnt mit einer scheinbar einfachen Frage: Wie generiert man einen DKIM-Schlüssel? Die Antwort hängt davon ab, wer die Post signiert — in der großen Mehrheit der Fälle generiert die Versandplattform den Schlüssel selbst, und die verbleibende Arbeit beschränkt sich darauf, den richtigen DNS-Eintrag zu veröffentlichen. Aber es gibt Entscheidungen, die zählen (die Schlüsselgröße, das CNAME vs. das TXT, die Ausrichtung) und Fallen zu vermeiden. Dieser Leitfaden erklärt, wie man einen gültigen DKIM-Schlüssel erhält, wohin jedes Teil gehört und wie man prüft, dass alles korrekt ist.

Was ein „DKIM-Schlüssel" wirklich ist

Ein DKIM-Schlüssel ist kein einzelnes Objekt, sondern ein Paar:

ein privater Schlüssel, der dazu dient, die Nachrichten beim Versand zu signieren. Er bleibt geheim, gespeichert von der Versandplattform. Er verlässt diese Umgebung nie.
ein öffentlicher Schlüssel, abgeleitet aus dem privaten, der im DNS veröffentlicht wird. Die Empfänger holen ihn ab, um die Signatur zu verifizieren.

Einen DKIM-Schlüssel zu generieren heißt also, dieses Paar zu erzeugen. Der nach außen sichtbare Teil — der DNS-Eintrag — enthält nur den öffentlichen Schlüssel. Taucht der private Schlüssel in einem DNS-Eintrag auf, ist das ein schwerer Fehler: Er darf dort niemals stehen.

Der häufigste Fall: die Plattform generiert selbst

Für Microsoft 365, Google Workspace, einen Marketing-Router oder die meisten SaaS ist kein kryptografischer Befehl auszuführen. Die Plattform generiert das Paar, behält den privaten Schlüssel und liefert den zu veröffentlichenden DNS-Eintrag. Die Vorgehensweise:

DKIM aktivieren in der Konsole der Plattform.
Den Eintrag abholen, den sie ausgibt — oft ein oder zwei CNAME, manchmal ein TXT mit dem öffentlichen Schlüssel, an einem präzisen Selektor (siehe der DKIM-Selektor).
Ihn veröffentlichen im eigenen DNS, ohne den Wert zu ändern (die Schlüssel sind lang; vollständig kopieren).
Die Signatur aktivieren auf Plattformseite, sobald die DNS-Propagation erfolgt ist.

Das ist der empfohlene Weg: Die Plattform verwaltet den privaten Schlüssel und oft auch seine Rotation. Es gibt kaum einen guten Grund, den Schlüssel selbst zu generieren, wenn die Plattform das anbietet — im Gegenteil, damit wandert die Verantwortung mit, ein kritisches Geheimnis sicher aufzubewahren und den Schlüssel manuell zu rotieren, ohne dafür einen echten Gegenwert zu bekommen. Die selbst betriebene Generierung ist dem Fall vorbehalten, in dem eine eigene Mail-Infrastruktur läuft und die Signatur ohnehin im Haus erfolgt.

Das `CNAME` statt des `TXT`, wenn möglich

Viele Dienstleister bieten an, ein CNAME zu veröffentlichen, das auf einen von ihnen gepflegten Eintrag zeigt, statt eines TXT, das den Schlüssel fest enthält. Das CNAME verdient den Vorzug: Es erlaubt dem Dienstleister, den Schlüssel zu rotieren, ohne dass das eigene DNS jedes Mal angefasst werden muss. Einmal veröffentlicht, wird die Schlüsselrotation transparent. Das rohe TXT bleibt gültig, zwingt aber bei jeder Erneuerung zum Eingreifen.

Einen Schlüssel selbst generieren (fortgeschrittener Fall)

Läuft eine eigene Sendeinfrastruktur (etwa ein Postfix-Server), wird das Paar selbst generiert. Konzeptuell entsteht ein RSA-Schlüssel, aus dem der öffentliche Teil extrahiert und der DNS-Eintrag gebaut wird. Der veröffentlichte Eintrag sieht so aus:

selektor._domainkey.beispiel.de.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ... (öffentlicher Schlüssel)"

Das p= enthält den kodierten öffentlichen Schlüssel. Der entsprechende private Schlüssel bleibt auf dem Server, gelesen vom Signaturtool. Zwei goldene Regeln in diesem Fall: den privaten Schlüssel schützen wie ein kritisches Geheimnis und eine angemessene Größe wählen (siehe weiter unten).

Welche Schlüsselgröße wählen

Die Frage kommt immer wieder: 1024 oder 2048 Bit? Die kurze Antwort: 2048 Bit ist heute der empfohlene Standard, robuster. Das 1024 bleibt akzeptiert, aber altert. Es gibt jedoch eine technische Feinheit (die Länge des DNS-Eintrags), die einen eigenen Leitfaden verdient — siehe 1024 oder 2048 Bit. Bei einem Start von null fällt die Wahl auf 2048.

Die Falle, die alles zunichtemacht: die Ausrichtung

Hier ist der teuerste Fehler. Ein vollkommen gültiger DKIM-Schlüssel lässt sich generieren und veröffentlichen, die Signatur „besteht" — und trägt dennoch nichts zu DMARC bei. Warum? Weil DMARC verlangt, dass die signierende Domain (d= in der Signatur) sich mit der des From: ausrichtet. Die DKIM-Standardsignatur vieler Plattformen verwendet ihre Domain (d=plattform.de), nicht die des Absenders. Ergebnis: Die Signatur ist gültig, aber für die falsche Domain.

Die Lösung ist, eine markeneigene Signatur zu konfigurieren: Die meisten Dienstleister bieten eine Option „benutzerdefinierte Signaturdomain" oder „authentifiziertes DKIM", die mit d=beispiel.de signieren lässt. Das ist genau das, was den DKIM-Schlüssel für DMARC nützlich macht. Der komplette Mechanismus steht in wie die drei Protokolle zusammenarbeiten.

Prüfen, dass der Schlüssel funktioniert

Sobald der Schlüssel veröffentlicht und die Signatur aktiviert ist, sind drei Dinge zu kontrollieren:

Der öffentliche Schlüssel ist wirklich da, vollständig und am richtigen Selektor (dig TXT selektor._domainkey.beispiel.de).
Die Signatur besteht auf einer echten Nachricht — siehe wie man eine E-Mail-Signatur verifiziert.
Die Ausrichtung stimmt mit dem From:, sichtbar in den Aggregatberichten.

All das lässt sich auf einen Schlag bestätigen, indem die Domain in unseren kostenlosen Analyzer eingegeben wird, der Präsenz, Gültigkeit und Ausrichtung der Schlüssel prüft.

DKIM auf gängigen Plattformen aktivieren

Der genaue Ablauf hängt von der Plattform ab, aber das Schema ist überall dasselbe: DKIM in der Konsole aktivieren, den Eintrag abholen, ihn veröffentlichen, warten, signieren. Ein paar konkrete Anhaltspunkte:

Microsoft 365. Im Sicherheitsportal, unter der Nachrichtenauthentifizierung, wird DKIM für die Domain aktiviert. Microsoft liefert zwei CNAME (selector1 und selector2) zum Veröffentlichen; die beiden dienen dazu, die alternierende Rotation der Schlüssel zu ermöglichen. Einmal veröffentlicht und propagiert, folgt die Aktivierung der Signatur.
Google Workspace. In der Admin-Konsole, unter der Nachrichtenauthentifizierung, wird ein Schlüssel für die Domain generiert (2048 Bit wählen). Google gibt ein TXT zum Veröffentlichen am Selektor google aus. Nach der Propagation startet die Authentifizierung.
Router und SaaS (Brevo, SendGrid, Mailchimp…). Fast alle bieten eine benutzerdefinierte Signaturdomain über ein oder mehrere CNAME an. Genau dort wird auch die Ausrichtung aktiviert (d=beispiel.de) — der Schritt, der die Signatur für DMARC nützlich macht.

In allen Fällen ist die Regel dieselbe: den Wert vollständig kopieren, die Propagation abwarten, bevor die Signatur aktiviert wird, und danach prüfen, dass das d= wirklich die eigene Domain trägt und nicht die des Dienstleisters.

Die häufigsten Generierungsfehler

Drei Fehlschläge kommen in Schleife wieder. Erstens, die Signatur vor der DNS-Propagation aktivieren: Die ersten Signaturen zeigen auf einen noch nicht sichtbaren Schlüssel und schlagen fehl — vor dem Signieren ist abzuwarten, bis dig den Schlüssel zeigt. Zweitens, den Schlüssel abschneiden beim Kopieren-Einfügen, besonders bei 2048 Bit, wo er lang ist: Ein einziges fehlendes Zeichen zerbricht die ganze Verifikation. Und schließlich, die Ausrichtung vergessen: DKIM ist aktiviert, die Signatur besteht, aber mit dem d= des Dienstleisters — der Schutz scheint zu greifen, während DMARC sich auf nichts stützt. Diese drei Punkte nach jeder Aktivierung systematisch zu prüfen erspart die überwältigende Mehrheit der DKIM-Anlauffehler.

Häufige Fragen

Muss ich den Schlüssel selbst generieren? Selten. Beim Versand über eine Plattform (Microsoft, Google, ein SaaS) generiert diese das Paar und behält den privaten Schlüssel. Selbst generiert wird nur beim Betrieb einer eigenen Signaturinfrastruktur.

Wohin geht der private Schlüssel? Er bleibt in der Umgebung, die signiert (die Plattform oder der eigene Server). Er wird niemals im DNS veröffentlicht und darf diese Umgebung nie verlassen. Das DNS enthält nur den öffentlichen Schlüssel.

Kann ich denselben Schlüssel für mehrere Domains wiederverwenden? Zu vermeiden. Jede Domain sollte ihren eigenen Schlüssel (und ihren eigenen Selektor) haben, um die Risiken zu isolieren und die Rotation zu vereinfachen.

Wie lange, bis es funktioniert? Die Zeit der DNS-Propagation (von ein paar Minuten bis ein paar Stunden). Die Signatur auf Plattformseite ist erst zu aktivieren, wenn der öffentliche Schlüssel sichtbar ist, sonst schlagen die ersten Signaturen fehl.

1024 oder 2048 Bit? 2048 für ein neues Deployment. Das 1024 funktioniert noch, ist aber weniger robust; bei der nächsten Rotation zu ersetzen.

DKIM und Zustellbarkeit: warum es wirklich zählt

Über die Sicherheit hinaus hat DKIM einen konkreten Effekt auf die Zustellbarkeit der E-Mails. Die großen Mail-Anbieter (Gmail, Outlook, Yahoo) integrieren die Präsenz und die Ausrichtung von DKIM in ihre Reputationsscores: Eine Domain, die seit langem korrekt signiert, mit einem ausgerichteten Schlüssel, baut eine Vertrauenshistorie auf, die die Spam-Filter berücksichtigen. Umgekehrt wird eine Domain ohne DKIM (oder mit einer nicht ausgerichteten Signatur) mit mehr Misstrauen behandelt, besonders wenn ihre Reputation noch jung ist. DKIM verhindert Spam nicht — ein Spammer kann seine Nachrichten durchaus signieren — aber es sagt dem Empfänger „diese Nachricht kommt wirklich von dem, von dem sie vorgibt zu kommen", was ein wichtiges Legitimitätssignal ist. Kombiniert mit SPF und DMARC bildet es das Basistrio, das jeder seriöse Absender haben muss, bevor er irgendetwas anderes zu optimieren versucht. Einmal gut konfiguriert, arbeitet DKIM unsichtbar im Hintergrund und häuft Reputation an mit jeder legitimen E-Mail, die die Domain verlässt.

Thomas generiert den richtigen Eintrag

Zwischen der Schlüsselgröße, dem CNAME vs. TXT und vor allem der Ausrichtung bleibt ein schlecht gesetzter DKIM-Schlüssel unbemerkt bis zu dem Tag, an dem DMARC fehlschlägt. Thomas, der virtuelle CISO, nennt für jede Plattform den exakten zu veröffentlichenden Eintrag, prüft, dass die Signatur sich mit der Domain ausrichtet, und führt bis zu einem DKIM, das wirklich für DMARC zählt.

Kostenlose DMARC-Analyse einer Domain oder ein Konto erstellen für ein DKIM, das auf Anhieb korrekt ist.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos