DKIM 1024 oder 2048 Bit: welche Schlüssellänge wählen

Von Thomas · virtueller CISO · 2026-07-12

Beim Erzeugen eines DKIM-Schlüssels stellt sich immer wieder eine Frage: 1024 oder 2048 Bit? Die grundsätzliche Antwort ist einfach — 2048 ist heute die richtige Wahl — doch sie geht mit einer technischen Falle einher, die viele im schlechtesten Moment entdecken: Ein 2048-Bit-Schlüssel ist länger, und seine Veröffentlichung im DNS kann an ein wenig bekanntes Limit stoßen. Dieser Leitfaden erklärt, warum 2048 das Ziel sein sollte, wie sich die 255-Zeichen-Falle vermeiden lässt, und wie ein alter 1024-Schlüssel migriert, ohne dass etwas kaputtgeht.

Die kurze Antwort: 2048 Bit

Für ein neues Deployment sind 2048 Bit die richtige Wahl. Das ist heute der empfohlene Standard: Ein 2048-Schlüssel ist deutlich widerstandsfähiger gegen Brute Force als ein 1024-Schlüssel, der für moderne Zwecke als zu schwach gilt. Die großen Mailanbieter und die bewährten Sicherheitspraktiken konvergieren auf 2048 als Basis. Beim Start bei null ist die Frage entschieden: 2048.

Warum 1024 auf Abruf lebt

1024 Bit ist nicht in dem Sinne „geknackt", dass jeder morgen früh die Signaturen fälschen könnte. Aber seine Sicherheitsmarge ist mit der verfügbaren Rechenleistung erodiert, bis zu dem Punkt, dass es heute als unzureichend gilt für ein Geheimnis, das dauern soll. Es zu behalten heißt, einen Schlüssel zu akzeptieren, dessen Robustheit nur abnimmt. Viele Domains laufen noch aus Erbschaft auf 1024 — ein vor Jahren gesetzter und nie erneuerter Schlüssel. Genau die Art von Schuld, die eine gut durchgeführte Schlüsselrotation abbaut.

Die Falle bei 2048: das DNS-Limit von 255 Zeichen

Hier ist, was beim Wechsel auf 2048 überrascht. Ein 2048-Bit-öffentlicher-Schlüssel ist kodiert lang — oft mehr als 255 Zeichen. Ein DNS-TXT-Eintrag besteht jedoch aus Zeichenketten, von denen jede auf 255 Zeichen begrenzt ist. Ein 2048-Schlüssel passt also nicht in eine einzige Zeichenkette: Man muss ihn in mehrere Zeichenketten aufteilen innerhalb desselben TXT-Eintrags.

Konkret sieht der Eintrag statt eines einzigen langen Werts so aus:

selektor._domainkey.beispiel.de.  IN TXT
  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
    "...der Rest des Schlüssels auf einer zweiten Zeichenkette in Anführungszeichen..." )

Die beiden Zeichenketten in Anführungszeichen werden vom Resolver verkettet, um den Schlüssel wiederherzustellen. Das ist eine Besonderheit der DNS-Syntax, keine Option: Wird ein 2048-Schlüssel am Stück in eine Oberfläche eingefügt, die nur eine Zeichenkette akzeptiert, folgt entweder ein Fehler oder ein abgeschnittener Schlüssel — und die Signatur schlägt fehl. Die meisten DNS-Hoster verwalten diese Aufteilung automatisch, aber manche Oberflächen verlangen sie von Hand.

Und 4096 Bit?

Wenn 2048 gut ist, warum nicht 4096, um „noch sicherer" zu sein? In der Praxis wird 4096 für DKIM selten empfohlen: Der Schlüssel wird sehr lang (mehrere Zeichenketten, umfangreiche DNS-Einträge), manche Implementierungen kommen schlecht damit zurecht, und der reale Sicherheitsgewinn gegenüber 2048 rechtfertigt es für die E-Mail-Signatur nicht. Der Konsens bleibt 2048 Bit: der beste Kompromiss zwischen Robustheit und Kompatibilität. 4096 bleibt sehr besonderen Fällen vorbehalten, mit Sachkenntnis.

Die Länge des aktuellen Schlüssels ermitteln

Vor der Migration gilt es, den Ausgangspunkt zu kennen. Der öffentliche Schlüssel lässt sich im DNS abrufen (dig TXT selektor._domainkey.beispiel.de) und daraus die Länge ableiten, oder — einfacher — die Domain läuft durch unseren kostenlosen Analyzer, der den aktuellen DKIM-Schlüssel liest und nennt, ob er 1024 oder 2048 ist. Taucht ein alter 1024-Schlüssel auf, ist das kein brennender Notfall, aber ein guter Kandidat für die nächste Rotation.

Von 1024 auf 2048 migrieren, ohne etwas kaputtzumachen

Der Wechsel von 1024 auf 2048 ist kein gesonderter Vorgang: Es ist eine normale Schlüsselrotation, mit einer neuen Länge. Die Sequenz ist die des doppelten Selektors:

Einen neuen 2048-Schlüssel erzeugen unter einem neuen Selektor und seinen öffentlichen Schlüssel veröffentlichen (mit Verwaltung der Aufteilung in Zeichenketten, falls nötig).
Prüfen, dass der neue öffentliche Schlüssel vollständig und im DNS sichtbar ist.
Die Signatur umschalten auf Plattformseite auf den neuen Selektor.
Die aggregierten Berichte überwachen: Die neuen 2048-Signaturen müssen durchgehen und aligned sein.
Den alten 1024-Selektor entfernen nach ein paar Tagen.

Alles ist im Detail in der Schlüsselrotation beschrieben. Der einzige spezifische Aufmerksamkeitspunkt bei 2048 ist die korrekte DNS-Veröffentlichung des längeren Schlüssels.

Einen 2048-Schlüssel veröffentlichen, Schritt für Schritt

Die Schwierigkeit bei 2048 ist nicht kryptografisch, sie ist rein praktisch: Der Schlüssel ist zu lang für eine einzige TXT-Zeichenkette. Das Vorgehen richtet sich nach dem DNS-Hoster. Akzeptiert die Oberfläche einen langen Wert und verwaltet die Aufteilung allein (Fall der meisten modernen Hoster), lässt sich der Schlüssel einfach so einfügen, wie er ist: Die Oberfläche setzt die Trennanführungszeichen selbst ein. Verlangt sie Zeichenketten von maximal 255 Zeichen, wird der Schlüssel von Hand in Segmente geteilt und jedes mit Anführungszeichen umschlossen, der Resolver klebt sie wieder zusammen. Im Zweifel folgt auf die Veröffentlichung eine sofortige Prüfung mit dig TXT selektor._domainkey.beispiel.de: Der gesamte Schlüssel muss sich wiederfinden, rekonstruiert, ohne Schnitt oder störendes Zeichen. Die Vorschau der Oberfläche verdient kein Vertrauen; maßgeblich ist, was das DNS tatsächlich zurückgibt. Ein Signaturtest an einer echten Nachricht bestätigt dann, dass der veröffentlichte Schlüssel auch wirklich zum privaten Schlüssel passt, der signiert.

Ein wenig Kontext: warum die Länge zählt

Die Länge eines RSA-Schlüssels misst, vereinfacht, die Schwierigkeit, ihn per Berechnung zu „knacken". Ein 1024-Bit-Schlüssel bot vor fünfzehn Jahren eine komfortable Marge; die Rechenleistung ist seither so stark gestiegen, dass diese Marge geschrumpft ist, und die Normungsgremien haben die Latte für dauerhafte Geheimnisse auf 2048 gehoben. DKIM entzieht sich dieser Logik nicht: Eine Signatur soll den Ursprung einer Nachricht zuverlässig beweisen, was einen Schlüssel voraussetzt, den ein Angreifer nicht reproduzieren kann. 1024 aus Trägheit zu behalten heißt, diese Garantie erodieren zu lassen, ohne es zu merken. Umgekehrt bringt eine Überdimensionierung auf 4096 für E-Mail keine proportionale Garantie und erschwert die Veröffentlichung — daher der Konsens auf 2048, der Gleichgewichtspunkt zwischen realer Robustheit und universeller Kompatibilität. Die praktische Regel lautet: 2048 als Standard, 1024 zu ersetzen, 4096 nur, wenn eine präzise Anforderung es rechtfertigt.

Der häufigste Fehler beim Wechsel

In der Praxis scheitert die Umstellung auf 2048 fast nie an der Kryptografie und fast immer an einem Kopier-Einfüge-Problem im DNS. Das Szenario wiederholt sich: Jemand generiert einen sauberen 2048-Schlüssel, kopiert ihn in eine DNS-Oberfläche, die stillschweigend nur die ersten 255 Zeichen behält, speichert — und die Oberfläche zeigt keinen Fehler. Alles wirkt in Ordnung, doch jede Signatur schlägt fehl, weil der veröffentlichte öffentliche Schlüssel abgeschnitten ist und nicht mehr zum privaten Schlüssel passt. Der Betreiber merkt es oft erst Tage später, wenn die Zustellrate einbricht oder ein aggregierter Bericht eine Welle von dkim=fail meldet. Die Lehre daraus ist einfach und lohnt es, sich einzuprägen: Nach jeder Veröffentlichung eines 2048-Schlüssels wird das Ergebnis mit dig geprüft, nicht mit dem Auge in der Oberfläche. Die Oberfläche zeigt die Eingabe; dig zeigt, was das DNS tatsächlich ausliefert — und nur Letzteres zählt.

Ein verwandter Fallstrick betrifft die Anführungszeichen. Manche Oberflächen erwarten die Zeichenketten von Hand in Anführungszeichen gesetzt und mit Leerzeichen getrennt; andere fügen die Anführungszeichen automatisch ein und würden ein doppeltes Setzen als literalen Bestandteil des Schlüssels interpretieren. Ein Anführungszeichen zu viel oder zu wenig, und der rekonstruierte Schlüssel enthält Störzeichen. Auch hier ist die dig-Kontrolle das letzte Wort: Der zurückgegebene p=-Wert muss exakt der Base64-Zeichenkette des Schlüssels entsprechen, ohne eingebettete Anführungszeichen, ohne Leerzeichen, ohne Abschnitt.

Häufige Fragen

Ist 1024 heute gefährlich zu verwenden? Nicht unmittelbar gefährlich, aber geschwächt und für die lange Frist abgeraten. Es ist eine Schuld, die bei der nächsten Rotation abzubauen ist, nicht ein Notfall, der diese Nacht zu behandeln wäre.

Warum „passt" mein 2048-Schlüssel nicht in mein DNS? Weil er 255 Zeichen überschreitet und in mehrere Zeichenketten innerhalb desselben TXT-Eintrags aufgeteilt werden muss. Viele Oberflächen machen das allein; manche verlangen die Trennanführungszeichen von Hand.

Soll ich für mehr Sicherheit 4096 anpeilen? Nein, in der Regel. 2048 ist der Standard; 4096 macht den Eintrag schwerer und schafft Kompatibilitätsprobleme, ohne einen für DKIM angemessenen Nutzen.

Wählt meine Plattform die Länge für mich? Oft ja. Microsoft 365, Google Workspace und die meisten SaaS erzeugen standardmäßig 2048-Schlüssel. Eine Prüfung lohnt trotzdem, besonders bei alten Konten, die vor langer Zeit konfiguriert wurden.

Verlangsamt ein größerer Schlüssel den Versand? Die Auswirkung auf Signatur und Verifikation ist vernachlässigbar. Das einzige echte Thema bei 2048 ist die DNS-Veröffentlichung, nicht die Performance.

Wie erfahre ich, ob mein Schlüssel 1024 oder 2048 Bit ist? Ein Abruf mit dig TXT selektor._domainkey.beispiel.de und ein Blick auf den Wert p= genügen: Ein 1024-Bit-Schlüssel kodiert sich in etwa 216 Zeichen in Base64; ein 2048-Bit-Schlüssel in etwa 392 Zeichen. Unser Analyzer nennt es direkt.

Was die Schlüssellänge nicht löst

Von 1024 auf 2048 zu wechseln ist eine gute Entscheidung, aber die Schlüssellänge gleicht kein Alignment-Problem aus. Ein perfekt veröffentlichter 2048-Schlüssel, mit d=, das auf die Domain des Dienstleisters statt auf die eigene zeigt, trägt immer noch nicht zu DMARC bei. Ebenso nützt eine sorgfältige Rotation nichts, wenn der Schlüssel nach der Veröffentlichung nie geprüft wird — ein abgeschnittenes Zeichen und die Signatur schlägt still fehl, bis ein Bericht es meldet. Die Schlüssellänge ist also eines der zu pflegenden Glieder, nicht das einzige — und ganz sicher nicht das, mit dem man beginnen sollte. Die richtige Reihenfolge: 1) sicherstellen, dass der Schlüssel veröffentlicht und vollständig ist; 2) prüfen, dass die Signatur mit der eigenen Domain aligned ist; 3) 2048 Bit anpeilen (oder bei der nächsten Rotation dorthin migrieren); 4) regelmäßig rotieren. Jeder Schritt baut auf dem vorigen auf; die Länge ist der dritte, nicht der erste.

Thomas prüft die Schlüssel

Die Länge jedes DKIM-Schlüssels kennen, einen vergessenen alten 1024 aufspüren, einen 2048 veröffentlichen, ohne ihn abzuschneiden: lauter Details, die leicht zu übersehen sind. Thomas, der virtuelle CISO, liest die Länge der aktuellen Schlüssel, meldet die zu modernisierenden und führt durch die Veröffentlichung eines korrekten 2048-Schlüssels, DNS-Aufteilung inklusive.

Eine Domain kostenlos analysieren oder ein Konto anlegen für DKIM-Schlüssel mit der richtigen Länge.

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