Nehmen Sie 2048 Bit. Der aktuelle DKIM-Standard lässt 1024 Bit gerade noch zu, empfiehlt aber ausdrücklich 2048 Bit. Fast jeder große Mailbox-Anbieter und jedes Admin-Panel unterstützt die längeren Schlüssel heute. Spannend ist deshalb weniger die Wahl selbst als der Wechsel: Wie prüfen Sie, welche Länge Ihre Domain gerade nutzt? Wie bekommen Sie einen fast 400 Zeichen langen Schlüssel sauber ins DNS? Und wie rotieren Sie Schlüssel, ohne dass auch nur eine E-Mail mit kaputter Signatur beim Empfänger ankommt? Genau das erklären wir hier Schritt für Schritt.

Kurz gesagt

• 2048 Bit ist der Standard. Nach RFC 8301 müssen DKIM-RSA-Schlüssel mindestens 1024 Bit lang sein, empfohlen sind mindestens 2048 Bit.
• 1024 Bit ist eine Altlast. Signaturen damit werden noch akzeptiert, haben aber keinen Sicherheitspuffer mehr. Wer heute einen Schlüssel neu anlegt, sollte nicht mehr 1024 Bit wählen.
• Das Hindernis ist das DNS, nicht die Kryptografie. Lange Schlüssel passen nicht in einen einzelnen TXT-String und müssen aufgeteilt werden. Manche DNS-Server kommen damit nicht zurecht.
• Umstellen geht über einen neuen Selektor. Neuen Schlüssel veröffentlichen, abwarten, Signatur umschalten, den alten Schlüssel erst später zurückziehen.
• Rotieren Sie regelmäßig. Die M3AAWG empfiehlt professionellen Absendern, DKIM-Schlüssel mindestens zweimal im Jahr zu wechseln.

Inhaltsverzeichnis

• Was die Schlüssellänge bei DKIM bedeutet
• 1024 und 2048 Bit im direkten Vergleich
• Sicherheit: warum 1024 Bit nicht mehr reicht
• Zustellbarkeit: was ein längerer Schlüssel bewirkt und was nicht
• Die DNS-Hürde: lange Schlüssel im TXT-Eintrag
• So prüfen Sie Ihre aktuelle Schlüssellänge
• Umstellung von 1024 auf 2048 Bit ohne Ausfall
• DKIM-Rotation: wie oft und wie sicher
• Ausblick: Ed25519 statt RSA
• Unsere Sicht: Schlüssellänge ist Teil der Infrastruktur
• Domains sauber aufsetzen mit PlusVibe
• Häufige Fragen
• Quellen

Was die Schlüssellänge bei DKIM bedeutet

DKIM (DomainKeys Identified Mail) signiert jede ausgehende E-Mail mit einem privaten Schlüssel, den nur Ihr Mailserver oder Ihr Versanddienst kennt. Den passenden öffentlichen Schlüssel veröffentlichen Sie als TXT-Eintrag im DNS, unter einem Namen wie selector1._domainkey.ihre-domain.de. Der empfangende Server liest den Selektor aus der Signatur (s=), ruft den öffentlichen Schlüssel ab und prüft damit, ob Header und Text unterwegs unverändert geblieben sind und ob die Mail wirklich von Ihrer Domain autorisiert wurde.

Die Schlüssellänge in Bit gibt die Größe des RSA-Moduls an, also der Zahl, auf der das Verfahren beruht. Je größer sie ist, desto aufwendiger wird es, aus dem öffentlichen Schlüssel den privaten zu errechnen. Wer das schafft, kann E-Mails im Namen Ihrer Domain signieren, und diese bestehen DKIM einwandfrei. Für Phishing ist das ein Geschenk, denn eine gültige Signatur ist genau der Nachweis, auf den Empfänger und DMARC vertrauen.

Die Länge hat aber auch eine praktische Seite: Der öffentliche Schlüssel steht Base64-kodiert im DNS. Ein 1024-Bit-Schlüssel ergibt dort einen p=-Wert von gut 200 Zeichen, ein 2048-Bit-Schlüssel fast doppelt so viel. Genau daran scheitern die meisten Umstellungen.

1024 und 2048 Bit im direkten Vergleich

Die Zeichenzahlen beziehen sich auf einen üblichen RSA-Schlüssel im Format, das DKIM-Generatoren ausgeben. Sie dienen beim Prüfen als gute Faustregel, wie wir weiter unten zeigen.

Sicherheit: warum 1024 Bit nicht mehr reicht

Die Regeln für DKIM-Kryptografie wurden 2018 mit RFC 8301 verschärft. Das Dokument schaffte SHA-1 als Hash-Verfahren für Signaturen ab und legte fest: Signierende Systeme müssen RSA-Schlüssel mit mindestens 1024 Bit verwenden und sollten mindestens 2048 Bit nutzen. Prüfende Systeme dürfen Signaturen mit kürzeren Schlüsseln nicht mehr als gültig anerkennen. Ein 512-Bit-Schlüssel, wie er in alten Anleitungen noch auftaucht, führt also heute schlicht zu einem DKIM-Fehler.

1024 Bit liegen damit genau auf der Untergrenze. Ein gebrochener 1024-Bit-DKIM-Schlüssel ist öffentlich nicht bekannt, die Kryptografie-Gemeinschaft betrachtet die Länge aber seit Jahren als Auslaufmodell. Rechenleistung wird günstiger, Verfahren werden besser, und ein Angreifer braucht nur einen einzigen Schlüssel, der lange genug unverändert im DNS steht. Ein 1024-Bit-Schlüssel, der seit Jahren nicht rotiert wurde, ist deshalb das eigentliche Risiko: wenig Sicherheitspuffer, viel Zeit für einen Angriff.

2048 Bit bieten einen großen Abstand zu allem, was heute realistisch angreifbar ist. Längere Schlüssel, etwa 4096 Bit, bringen für DKIM kaum zusätzlichen Nutzen. Sie verschärfen aber das DNS-Problem, und nicht jeder Empfänger verarbeitet sie zuverlässig. 2048 Bit sind deshalb nicht der Kompromiss, sondern die vernünftige Wahl.

Zustellbarkeit: was ein längerer Schlüssel bewirkt und was nicht

Ein verbreitetes Missverständnis: Mit 2048 Bit landen Ihre Mails automatisch öfter im Posteingang. So direkt funktioniert es nicht. Mailbox-Anbieter bewerten in erster Linie, ob DKIM besteht, ob die signierende Domain zur Absenderdomain passt (Alignment) und wie sich Ihre Domain und Ihre IPs bisher verhalten haben. Eine gültige 1024-Bit-Signatur besteht die DKIM-Prüfung genauso wie eine 2048-Bit-Signatur.

Trotzdem hängt Zustellbarkeit an der Schlüssellänge, nur indirekt:

• Authentifizierung ist Pflicht. Google verlangt von Absendern, die mehr als 5.000 Nachrichten pro Tag an Gmail-Konten schicken, SPF, DKIM und DMARC. Ohne funktionierendes DKIM ist hohes Volumen kaum möglich.
• Fehlgeschlagene Signaturen kosten mehr als kurze Schlüssel. Ein falsch eingetragener 2048-Bit-Schlüssel, etwa mit einem zerschnittenen String, liefert dkim=fail. Das schadet sofort. Ein sauber laufender 1024-Bit-Schlüssel ist besser als ein kaputter 2048-Bit-Schlüssel.
• Ein kompromittierter Schlüssel ruiniert die Reputation. Wenn Dritte mit Ihrer Signatur Spam verschicken, trifft das Ihre Domain.

Das Ziel ist also: 2048 Bit, korrekt veröffentlicht und sauber ausgerichtet. Wie das Alignment mit DMARC zusammenhängt und warum es so oft unbemerkt bricht, zeigen wir im Beitrag über DKIM-Alignment als stillen Zustellbarkeitskiller.

Die DNS-Hürde: lange Schlüssel im TXT-Eintrag

Ein einzelner Zeichenblock in einem DNS-TXT-Eintrag fasst höchstens 255 Zeichen. Der 2048-Bit-Schlüssel ist länger und muss deshalb in mehrere Strings aufgeteilt werden, die im selben Eintrag hintereinander stehen. Empfänger fügen sie ohne Leerzeichen wieder zusammen. In Zonendateien sieht das etwa so aus:

selector2._domainkey IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...erster Teil..."
                              "...zweiter Teil...IDAQAB" )

Viele DNS-Oberflächen übernehmen das Aufteilen automatisch, wenn Sie den kompletten Wert einfügen. Probleme entstehen in drei typischen Situationen:

1. Das Eingabefeld schneidet ab. Manche Panels speichern nur die ersten 255 Zeichen, ohne zu warnen. Der Eintrag sieht korrekt aus, der Schlüssel ist aber unvollständig.
2. Der Server liefert lange Einträge nicht aus. Einige DNS-Server akzeptieren oder beantworten lange TXT-Einträge für 1536- oder 2048-Bit-Schlüssel nicht zuverlässig. Laut Broadcom betraf das etwa Windows-DNS-Server 2003 und 2008, bei denen sich lange Schlüssel im DNS-Verwaltungstool auf mehrere Zeilen verteilen lassen.
3. Beim Kopieren entstehen Fehler. Zusätzliche Anführungszeichen, Zeilenumbrüche oder Leerzeichen mitten im p=-Wert machen den Schlüssel unbrauchbar.

Die Voraussetzung ist deshalb einfach: Ihr DNS-Anbieter muss 2048-Bit-Schlüssel unterstützen. Wenn er das nicht tut, bieten manche Versanddienste den Rückweg auf 1024 Bit an. Das ist eine Notlösung. Auf Dauer ist der Wechsel zu einem DNS-Anbieter, der lange TXT-Einträge beherrscht, fast immer die bessere Lösung, denn auch DMARC- und SPF-Einträge wachsen mit der Zeit.

So prüfen Sie Ihre aktuelle Schlüssellänge

Sie brauchen dafür keine Spezialsoftware, nur eine E-Mail von Ihrer Domain und ein Terminal.

1. Selektor finden. Schicken Sie sich selbst eine Mail an ein externes Postfach und öffnen Sie den Quelltext (in Gmail: „Original anzeigen“). Suchen Sie den Header DKIM-Signature und darin die Werte d= (signierende Domain) und s= (Selektor).
2. Eintrag abfragen. Unter macOS oder Linux: dig TXT selektor._domainkey.ihre-domain.de +short. Unter Windows: nslookup -type=TXT selektor._domainkey.ihre-domain.de. Bei Microsoft 365 zeigt der Eintrag oft per CNAME auf eine Microsoft-Adresse, die Abfrage folgt ihm automatisch.
3. Länge abschätzen. Zählen Sie die Zeichen des p=-Werts, nachdem Sie die einzelnen Strings zusammengefügt haben. Rund 216 Zeichen bedeuten 1024 Bit, rund 392 Zeichen bedeuten 2048 Bit.
4. Exakt prüfen (optional). Speichern Sie den p=-Wert zwischen -----BEGIN PUBLIC KEY----- und -----END PUBLIC KEY----- in einer Datei und führen Sie openssl rsa -pubin -in key.pem -noout -text aus. Die erste Zeile nennt die Länge, etwa „Public-Key: (2048 bit)“.
5. Alle Absender prüfen. Ihre Domain signiert womöglich über mehrere Dienste: Postfach-Anbieter, CRM, Newsletter-Tool, Ticketsystem, Cold-Email-Plattform. Jeder nutzt einen eigenen Selektor, und jeder kann eine andere Länge haben.

Gerade der letzte Punkt wird oft vergessen. Microsoft 365 arbeitet zum Beispiel mit zwei Selektoren, selector1 und selector2. Es kommt vor, dass einer bereits 2048 Bit nutzt und der andere noch 1024 Bit. Eine strukturierte Bestandsaufnahme aller sendenden Systeme finden Sie in unserer Checkliste für das Deliverability-Audit.

Umstellung von 1024 auf 2048 Bit ohne Ausfall

Das Prinzip ist bei jedem Anbieter gleich: Überschreiben Sie nie den aktiven Schlüssel. Legen Sie einen zweiten Schlüssel unter einem neuen Selektor an und schalten Sie erst um, wenn er überall abrufbar ist.

1. Neuen Schlüssel erzeugen. In Google Workspace, Microsoft 365 und den meisten Versandplattformen wählen Sie die Länge im Admin-Bereich. Auf eigenen Servern erzeugen Sie das Paar etwa mit openssl genrsa -out dkim.private 2048.
2. Unter neuem Selektor veröffentlichen. Zum Beispiel 2026a._domainkey.ihre-domain.de. Ein Datum im Selektornamen macht spätere Rotationen übersichtlich.
3. Abrufbarkeit prüfen. Fragen Sie den neuen Eintrag mit dig ab, auch über einen öffentlichen Resolver. Ist der p=-Wert vollständig? Kommen beide Strings zurück?
4. Propagation abwarten. Bei Google Workspace kann es bis zu 48 Stunden dauern, bis die DKIM-Authentifizierung nach dem Hinzufügen eines Schlüssels funktioniert. Planen Sie diesen Puffer ein.
5. Signatur umschalten. Erst jetzt aktivieren Sie den neuen Schlüssel für ausgehende Mails.
6. Ergebnis kontrollieren. Senden Sie Testmails an Gmail und Outlook und prüfen Sie im Header Authentication-Results auf dkim=pass mit dem neuen Selektor. Behalten Sie die DMARC-Berichte der folgenden Tage im Blick.
7. Alten Schlüssel stehen lassen, dann zurückziehen. Mails, die kurz vor dem Wechsel signiert wurden, liegen womöglich noch in Warteschlangen oder werden später erneut geprüft. Entfernen Sie den alten Schlüssel deshalb erst nach einigen Tagen.

Wenn Sie eine Domain für Cold Email neu einrichten, gehört 2048 Bit von Anfang an in die Grundkonfiguration, zusammen mit SPF und DMARC. Die komplette Reihenfolge beschreiben wir im Leitfaden zum technischen Setup für Cold Email.

DKIM-Rotation: wie oft und wie sicher

Rotation heißt: Sie ersetzen einen funktionierenden Schlüssel planmäßig durch einen neuen, auch wenn nichts passiert ist. Der Grund ist einfach. Ein Schlüssel, der nie gewechselt wird, ist nach einem unbemerkten Leck unbegrenzt missbrauchbar. Ein Schlüssel, der alle sechs Monate wechselt, nur für eine begrenzte Zeit.

Die Branchenorganisation M3AAWG empfiehlt professionellen Absendern in ihren Best Practices für DKIM-Schlüssel, Schlüssel mindestens zweimal jährlich zu rotieren. Für den Ablauf nennt sie zwei weitere Regeln, die in der Praxis oft fehlen:

• Die Gültigkeit der Signaturen sollte länger sein als die Rotationsperiode. Setzen Sie mit dem Tag x= eine Ablaufzeit, muss sie über den geplanten Wechsel hinausreichen, sonst laufen Signaturen ab, bevor der Schlüssel überhaupt ersetzt ist.
• Alte Schlüssel werden widerrufen, nicht einfach vergessen. Ein ausgedienter Schlüssel wird ungültig, indem Sie den Inhalt im TXT-Eintrag leeren, also p= ohne Wert stehen lassen. Empfänger erkennen dann eindeutig: Dieser Schlüssel wurde zurückgezogen.

Ein praxistauglicher Rhythmus für ein Team mit mehreren Domains sieht so aus:

Bei gehosteten Diensten läuft die Rotation über die Oberfläche des Anbieters. Microsoft 365 wechselt dabei zwischen seinen beiden Selektoren. Achten Sie darauf, dass beim Rotieren die gewünschte Länge von 2048 Bit gesetzt ist. Manche Cloud-Versanddienste begrenzen außerdem, wie oft Sie die Schlüssellänge innerhalb eines Tages ändern dürfen. Ein überhastetes Hin und Her bei der Fehlersuche kann Sie also blockieren.

Schauen Sie bei jeder Rotation auf Ihre DMARC-Richtlinie. Die M3AAWG rät, mit p=none zu beobachten, wie Empfänger Ihre DKIM-signierten Mails akzeptieren. Wer bereits mit quarantine oder reject arbeitet, sollte Rotationen besonders sorgfältig testen. Wann welche Stufe sinnvoll ist, beschreiben wir im Beitrag zur DMARC-Policy vor dem Skalieren. Falls nach dem Wechsel Fehlermeldungen auftauchen, hilft unser Leitfaden DMARC-Fehler beheben.

Ausblick: Ed25519 statt RSA

Neben RSA erlaubt DKIM inzwischen auch Signaturen mit Ed25519, einem elliptischen Kurvenverfahren. Sein großer Vorteil: Bei vergleichbarer Sicherheit ist der öffentliche Schlüssel sehr kurz, sodass das DNS-Problem gar nicht erst entsteht. Die Certified Senders Alliance hat diesen Ansatz schon in ihren DKIM-Empfehlungen von 2018 diskutiert.

Der Haken ist die Verbreitung bei den Empfängern. Nicht jeder prüfende Server versteht Ed25519. Die Empfehlung der CSA lautet deshalb: Wer Ed25519 einsetzt, signiert zusätzlich mit einem RSA-Schlüssel unter einem zweiten Selektor, damit Empfänger ohne Ed25519-Unterstützung eine gültige Signatur vorfinden. Für die meisten Teams heißt das: 2048-Bit-RSA bleibt die Pflicht, Ed25519 ist die Kür.

Unsere Sicht: Schlüssellänge ist Teil der Infrastruktur

In Gesprächen mit Vertriebsteams und Agenturen sehen wir immer wieder dasselbe Muster. Die Domain wurde vor Jahren eingerichtet, DKIM läuft irgendwie, und niemand weiß mehr, welcher Selektor welche Länge hat oder wann zuletzt rotiert wurde. Solange die Mails ankommen, fällt das nicht auf. Problematisch wird es, wenn das Volumen steigt: Mit zehn, zwanzig oder hundert sendenden Postfächern über mehrere Domains wird jede vergessene Einstellung zum Risiko für die gesamte Kampagne.

Wir behandeln DKIM deshalb nicht als einmalige Aufgabe, sondern als Teil der Versandinfrastruktur, genau wie Warm-up, Inbox-Rotation und laufende Deliverability-Überwachung. Ein 2048-Bit-Schlüssel ist schnell erzeugt. Entscheidend ist, dass er auf jeder Domain korrekt veröffentlicht ist, zur Absenderdomain passt und regelmäßig ersetzt wird. Erst dann bauen Warm-up und vorsichtiges Skalieren auf einem soliden Fundament auf. Wie das zusammenspielt, zeigen unsere Beiträge zum E-Mail-Warmup und zur Inbox-Rotation.

Unser Rat für Teams, die gerade umstellen: Fangen Sie mit einer Bestandsaufnahme an, nicht mit dem Generator. Wer jeden Absender kennt, stellt in einem Nachmittag um. Wer einen vergisst, sucht danach tagelang nach der Ursache für sinkende Öffnungsraten.

— Yaro

Domains sauber aufsetzen mit PlusVibe

Wenn Sie Cold Email in größerem Umfang verschicken, nimmt Ihnen PlusVibe einen Großteil dieser Arbeit ab. Die Plattform kombiniert privates Warm-up, isolierte Versandinfrastruktur, Inbox-Rotation und Deliverability-Monitoring. Postfächer über Google Workspace kosten 4 $ pro Monat und Postfach, über Microsoft 365 4,5 $ pro Monat und Postfach. Wer die Einrichtung von SPF, DKIM und DMARC ganz abgeben möchte, bucht das Done-for-you Email Setup für 1.500 $ pro Monat. Die Tarife beginnen beim Personal-Plan mit 37 bis 58 $ pro Monat, und eine kostenlose Testphase gibt es auch. Alle Pakete finden Sie in der Übersicht der PlusVibe-Tarife.

Häufige Fragen

Ist 1024 Bit für DKIM noch erlaubt?

Ja. RFC 8301 legt 1024 Bit als Mindestlänge fest, Signaturen damit sind also weiterhin gültig. Empfohlen sind jedoch mindestens 2048 Bit. Neue Schlüssel sollten Sie nicht mehr mit 1024 Bit anlegen, und bestehende stellen Sie am besten bei der nächsten Rotation um.

Verbessert ein 2048-Bit-Schlüssel meine Zustellbarkeit?

Nicht direkt. Mailbox-Anbieter werten vor allem aus, ob DKIM besteht und zur Absenderdomain passt, und wie Ihre Reputation aussieht. Ein 2048-Bit-Schlüssel schützt Sie aber davor, dass jemand Ihre Signatur fälscht, und erfüllt den aktuellen Standard. Wichtig ist, dass er fehlerfrei veröffentlicht ist, denn ein kaputter Schlüssel schadet sofort.

Warum funktioniert mein 2048-Bit-Schlüssel nicht?

Meist ist der TXT-Eintrag unvollständig. Das Panel hat nach 255 Zeichen abgeschnitten, die Strings wurden falsch aufgeteilt, oder Leerzeichen und Anführungszeichen sind in den p=-Wert geraten. Fragen Sie den Eintrag mit dig ab und vergleichen Sie ihn Zeichen für Zeichen mit dem Original. Unterstützt Ihr DNS-Anbieter lange Einträge nicht, ist ein Anbieterwechsel die dauerhafte Lösung.

Wie oft sollte ich DKIM-Schlüssel rotieren?

Die M3AAWG empfiehlt professionellen Absendern mindestens zwei Rotationen pro Jahr. Nutzen Sie dafür jedes Mal einen neuen Selektor und lassen Sie den alten Schlüssel einige Tage stehen. Danach widerrufen Sie ihn, indem Sie den p=-Wert leeren.

Sollte ich gleich 4096 Bit nehmen?

Für DKIM bringt das kaum zusätzlichen Nutzen. Der Eintrag wird noch länger, mehr DNS-Anbieter haben Probleme damit, und nicht jeder Empfänger verarbeitet solche Schlüssel zuverlässig. 2048 Bit ist die empfohlene und am breitesten unterstützte Länge.

Quellen

• RFC 8301: Kryptografische Algorithmen und Schlüssellängen für DKIM
• Google Workspace: DKIM einrichten
• Broadcom: DKIM-Authentifizierung schlägt bei 1536- oder 2048-Bit-Schlüsseln fehl
• Customers Mail Cloud: DKIM-Handbuch
• M3AAWG Best Practices for Implementing DKIM
• Certified Senders Alliance: DKIM Recommendations 2018

Empfehlungen

• DKIM-Ausrichtung: der stille Zustellkiller
• DMARC-Fehler beheben: Ursachen finden und sauber lösen
• Ein Leitfaden zu DKIM-Einträgen und E-Mail-Sicherheit
• SPF, DKIM & DMARC: Der ultimative Leitfaden zur E-Mail-Sicherheit