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

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 du 2048 anpeilen solltest, wie du die 255-Zeichen-Falle vermeidest, und wie du einen alten 1024-Schlüssel migrierst, ohne etwas kaputtzumachen.

Die kurze Antwort: 2048 Bit

Für ein neues Deployment wähle 2048 Bit. 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. Wenn du bei null anfängst, ist die Frage entschieden: 2048.

Warum 1024 auf Abruf lebt

1024 Bit ist nicht in dem Sinne „geknackt", dass jeder morgen früh deine 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.deine-domain.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: Wenn du einen 2048-Schlüssel am Stück in eine Oberfläche einfügst, die nur eine Zeichenkette akzeptiert, bekommst du entweder einen Fehler oder einen abgeschnittenen Schlüssel — und die Signatur schlägt fehl. Die meisten DNS-Hoster verwalten diese Aufteilung automatisch, aber manche Oberflächen verlangen, dass du sie von Hand machst.

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. Reserviere 4096 für sehr besondere Fälle, mit Sachkenntnis.

Wie du die Länge deines aktuellen Schlüssels erfährst

Bevor du migrierst, wisse, wovon du ausgehst. Du kannst deinen öffentlichen Schlüssel im DNS abrufen (dig TXT selektor._domainkey.deine-domain.de) und daraus die Länge ableiten, oder — einfacher — deine Domain durch unseren kostenlosen Analyzer geben, der deinen aktuellen DKIM-Schlüssel liest und dir sagt, ob er 1024 oder 2048 ist. Wenn du einen alten 1024-Schlüssel entdeckst, ist das kein brennender Notfall, aber ein guter Kandidat für deine 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:

1. Erzeuge einen neuen 2048-Schlüssel unter einem neuen Selektor und veröffentliche seinen öffentlichen Schlüssel (mit Verwaltung der Aufteilung in Zeichenketten, falls nötig).
2. Prüfe, dass der neue öffentliche Schlüssel vollständig und im DNS sichtbar ist.
3. Schalte die Signatur auf Plattformseite auf den neuen Selektor um.
4. Überwache deine aggregierten Berichte: Die neuen 2048-Signaturen müssen durchgehen und aligned sein.
5. Entferne den alten 1024-Selektor 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. So kommst du je nach deinem DNS-Hoster klar. Wenn deine Oberfläche einen langen Wert akzeptiert und die Aufteilung allein verwaltet (Fall der meisten modernen Hoster), füge den Schlüssel einfach so ein, wie er ist: Die Oberfläche setzt die Trennanführungszeichen für dich ein. Wenn sie Zeichenketten von maximal 255 Zeichen verlangt, teile den Schlüssel selbst in Segmente und umschließe jedes mit Anführungszeichen, der Resolver wird sie wieder zusammenkleben. Im Zweifel veröffentliche und prüfe sofort mit dig TXT selektor._domainkey.deine-domain.de: Du musst den gesamten Schlüssel wiederfinden, rekonstruiert, ohne Schnitt oder störendes Zeichen. Verlass dich nie auf die Vorschau der Oberfläche; verlass dich auf das, 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. Merke dir die praktische Regel: 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 prüfst du das Ergebnis mit dig, nicht mit dem Auge in der Oberfläche. Die Oberfläche zeigt dir, was du eingegeben hast; dig zeigt dir, was das DNS tatsächlich ausliefert — und nur Letzteres zählt.

Ein verwandter Fallstrick betrifft die Anführungszeichen. Manche Oberflächen erwarten, dass du selbst die Zeichenketten in Anführungszeichen setzt und mit Leerzeichen trennst; 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 deines 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. Betrachte es als Schuld, die bei deiner nächsten Rotation abzubauen ist, nicht als 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, dass du selbst die Trennanführungszeichen einfügst.

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. Prüf es 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? Ruf ihn mit dig TXT selektor._domainkey.deine-domain.de ab und schau dir den Wert p= an: Ein 1024-Bit-Schlüssel kodiert sich in etwa 216 Zeichen in Base64; ein 2048-Bit-Schlüssel in etwa 392 Zeichen. Unser Analyzer sagt es dir 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 deine 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 dir anzeigt. 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 deiner 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.

Lass Thomas deine Schlüssel prüfen

Die Länge jedes deiner DKIM-Schlüssel kennen, einen vergessenen alten 1024 aufspüren, einen 2048 veröffentlichen, ohne ihn abzuschneiden: lauter Details, die leicht zu übersehen sind. Thomas, dein virtueller CISO, liest die Länge deiner aktuellen Schlüssel, meldet die zu modernisierenden und leitet dich an, einen korrekten 2048-Schlüssel zu veröffentlichen, DNS-Aufteilung inklusive.

Analysiere deine Domain kostenlos → oder leg ein Konto an für DKIM-Schlüssel mit der richtigen Länge.