Wichtigste Erkenntnisse
- Die DKIM-Schlüssellänge entspricht der Bitgröße Ihres RSA-Signaturschlüssels. Längere Schlüssel sind widerstandsfähiger gegen Fälschungen, führen jedoch zu größeren DNS-Einträgen, die veröffentlicht werden müssen.
- 1024-Bit-RSA wird gemäß RFC 8301 nicht mehr empfohlen und unterschreitet die NIST-Mindestanforderungen, dennoch generieren Hosting-Panels wie cPanel es weiterhin standardmäßig.
- 2048-Bit-RSA ist die richtige Standardeinstellung für das Jahr 2026 und entspricht damit den Vorgaben von RFC 8301, NIST sowie den Anforderungen von Google und Yahoo für Massenversender.
- Ein 2048-Bit-öffentlicher Schlüssel überschreitet das DNS-TXT-Limit von 255 Byte, daher müssen Sie ihn in mehrere Teilzeichenfolgen aufteilen, da die Überprüfung sonst ohne Fehlermeldung fehlschlägt.
- Ein übersprungener Chunking-Schritt führt zu einem stillen DKIM-Fehler: Ihre E-Mail wird zwar weiterhin versendet, die Protokolle bleiben fehlerfrei, aber die Empfänger lehnen die Signatur ab.
- Wechseln Sie die Schlüssel alle 6 bis 12 Monate mithilfe eines Parallel-Selektors aus und setzen Sie Ed25519 ausschließlich in Kombination mit RSA-2048 ein, niemals allein.
Eine Aktualisierung Ihres DKIM-Schlüssels sollte die E-Mail-Sicherheit verbessern. In der Praxis führt dies jedoch häufig zu Authentifizierungsfehlern, die durch eine fehlerhafte DNS-Konfiguration verursacht werden.
Viele Unternehmen verwenden nach wie vor 1024-Bit-DKIM-Schlüssel, ohne sich dessen bewusst zu sein. Andere stellen auf 2048-Bit um, um den aktuellen Sicherheitsempfehlungen gerecht zu werden, müssen dann jedoch feststellen, dass größere Schlüssel neue Anforderungen an die Veröffentlichung mit sich bringen. Ein einziger Fehler beim Hinzufügen des öffentlichen Schlüssels zum DNS kann dazu führen, dass die DKIM-Überprüfung fehlschlägt, auch wenn E-Mails weiterhin normal versendet werden.
Die Herausforderung besteht darin, die richtige Schlüssellänge zu wählen, diese korrekt zu veröffentlichen und sie langfristig zu pflegen, ohne dabei die E-Mail-Authentifizierung zu beeinträchtigen.
In diesem Leitfaden wird erläutert, wie sich die Länge von DKIM-Schlüsseln im Jahr 2026 auf Sicherheit, Zustellbarkeit und Compliance auswirkt. Sie erfahren, worin die Unterschiede zwischen 1024-Bit-, 2048-Bit-, 4096-Bit- und Ed25519-Schlüsseln bestehen, wie Sie Ihre aktuelle Konfiguration überprüfen, häufige Fehler bei der DNS-Veröffentlichung vermeiden und Schlüssel sicher rotieren können.
Was ist die DKIM-Schlüssellänge?
Die DKIM-Schlüssellänge ist die Größe des RSA-Schlüsselpaars in Bit, mit dem E-Mails gemäß dem DKIM-Standard (RFC 6376) signiert und verifiziert. Der private Schlüssel signiert jede ausgehende Nachricht auf dem Mailserver, und der dazugehörige öffentliche Schlüssel ist in einem DNS-TXT-Eintrag hinterlegt, damit empfangende Server die Signatur überprüfen können.
Längere Schlüssel sind schwerer zu knacken. Ein 2048-Bit-Schlüssel ist weitaus widerstandsfähiger gegen Fälschungen als ein 1024-Bit-Schlüssel. Die Schlüssellänge ist jedoch ein Kompromiss, der sich gleichzeitig auf die kryptografische Stärke, die Größe der DNS-Einträge und die Kompatibilität mit Empfängern auswirkt.
Der öffentliche Schlüssel wird unter einem Selektor, dem Label (z. B. selector1._domainkey.example.com), der dem Empfänger mitteilt, welchen Schlüssel er verwenden soll, da eine Domain mehrere Schlüssel gleichzeitig betreiben kann.
Vergleich der Optionen für die DKIM-Schlüssellänge
Nicht alle DKIM-Schlüssel sind gleich. Manche sind veraltet, manche entsprechen dem aktuellen Standard, und manche lösen zwar ein Problem, verursachen aber gleichzeitig ein neues. Hier sehen Sie, wie sich 1024-Bit-, 2048-Bit-, 4096-Bit- und Ed25519-Schlüssel in der Praxis im Vergleich schlagen.
1024-Bit-RSA
1024-Bit-RSA war der ursprüngliche DKIM-Standard und ist heute die schwächste Option, die noch zulässig ist. Die Standards sind mittlerweile darüber hinausgegangen. RFC 8301 (2018) legt 1024 Bit als akzeptable Mindestschlüsselgröße fest, empfiehlt jedoch mindestens 2048 Bit für die Signatur. Außerdem schreibt er vor, dass Prüfer Schlüssel unter 1024 Bit als ungültig behandeln müssen.
NIST SP 800-131A Rev. 2 geht noch einen Schritt weiter, indem es RSA-Schlüssel unter 2048 Bit für die Erstellung digitaler Signaturen verbietet und 1024-Bit-RSA als Kryptografie für den Einsatz in älteren Systemen einstuft. Die Absenderrichtlinien von Google akzeptieren zwar weiterhin 1024-Bit-DKIM-Schlüssel als Mindestanforderung für die Zustellung über Gmail, empfehlen jedoch 2048-Bit-Schlüssel für eine höhere Sicherheit.
Trotz aller Empfehlungen sind 1024-Bit-Schlüssel nach wie vor weit verbreitet. Viele Hosting-Panels und ältere E-Mail-Plattformen generieren sie nach wie vor standardmäßig, sodass Unternehmen weiterhin 1024-Bit-RSA verwenden, ohne sich dessen bewusst zu sein.
Ein 1024-Bit-RSA-Schlüssel entspricht nicht den aktuellen kryptografischen Empfehlungen, weshalb Normungsgremien und E-Mail-Anbieter mittlerweile auf 2048-Bit-Lösungen umgestellt haben. Für Unternehmen, die weiterhin 1024-Bit-DKIM einsetzen, ist es jedoch in der Regel sinnvoller, eine kontrollierte Umstellung zu planen und zu validieren, als übereilte Änderungen vorzunehmen, die zu Authentifizierungsfehlern führen könnten.
2048-Bit-RSA
2048-Bit-RSA ist der aktuelle DKIM-Standard. RFC 8301 empfiehlt RSA-Schlüssel mit mindestens 2048 Bit für die Signierung, NIST SP 800-131A Rev. 2 stuft RSA-Schlüssel mit 2048 Bit oder mehr als für die Erstellung digitaler Signaturen akzeptabel ein, und die Absenderrichtlinien von Google empfehlen aus Sicherheitsgründen 2048-Bit-Schlüssel. Ein 2048-Bit-Schlüssel erfüllt die aktuellen Anforderungen der Branche, der Anbieter und der Compliance-Vorgaben.
Die meisten DKIM-Fehler im Zusammenhang mit 2048-Bit-Schlüsseln sind keine kryptografischen Fehler. Es handelt sich vielmehr um Fehler bei der DNS-Veröffentlichung. Ein öffentlicher 2048-Bit-Schlüssel ist etwa 392 Base64-Zeichen lang, während eine einzelne DNS-TXT-Zeichenkette auf 255 Byte begrenzt ist. Der Schlüssel kann nicht als einzelne Zeichenkette veröffentlicht werden. Er muss in mehrere durch Anführungszeichen getrennte Zeichenfolgen innerhalb desselben TXT-Eintrags aufgeteilt werdenaufgeteilt werden, die das DNS bei der Abfrage automatisch wieder zusammensetzt.
Wenn der Schlüssel falsch veröffentlicht wird, schlägt die DKIM-Überprüfung fehl , obwohl der Eintrag offenbar vorhanden ist und der Mailserver die Nachrichten weiterhin wie gewohnt signiert.
4096-Bit-RSA
4096-Bit-RSA ist die größte Schlüssellänge, die die meisten Empfänger überprüfen. RFC 8301 schreibt vor, dass Prüfer Schlüssel mit einer Länge von 1024 bis 4096 Bit validieren müssen, darüber hinaus jedoch nur optional. Daher besteht bei einem Schlüssel, der länger als 4096 Bit ist, das Risiko, dass er überhaupt nicht überprüft wird. PowerDMARC Hosted DKIM unterstützt Schlüssellängen von bis zu 4096 Bit.
Für die meisten Organisationen ist eine 4096-Bit-Verschlüsselung unnötig. Sie bietet keinen nennenswerten Sicherheitsgewinn gegenüber einer 2048-Bit-Verschlüsselung, die bereits die Mindestanforderungen gemäß NIST SP 800-131A Rev. 2 und die Absenderrichtlinien von Google erfüllt, führt jedoch zu einem größeren DNS-Eintrag und verursacht einen geringen Mehraufwand bei der Signaturprüfung.
Verwenden Sie 4096-Bit nur in Hochsicherheitsumgebungen oder stark regulierten Umgebungen, in denen dies durch interne Richtlinien oder von einem Prüfer ausdrücklich vorgeschrieben ist.
Ed25519 (Zukünftige Ausrichtung)
Ed25519 ist ein durch RFC 8463 (2018) standardisierter DKIM-Signaturalgorithmus. Sein größter Vorteil ist die Schlüsselgröße. Ein öffentlicher Ed25519-Schlüssel wird in eine 44-Oktett-Base64-Zeichenkette kodiert, sodass der gesamte DNS-Schlüsseldatensatz in eine einzige TXT-Zeichenkette passt. Im Gegensatz zu RSA-2048 und RSA-4096 erfordert er keine Aufteilung des DNS-Eintrags in mehrere Teile und funktioniert auch mit Systemen, die keine TXT-Einträge mit mehreren Zeichenfolgen veröffentlichen können. RFC 8463 beschreibt Ed25519 zudem als einen Algorithmus, der starke kryptografische Sicherheit mit deutlich kürzeren Schlüsseln als RSA bietet.
Die Herausforderung liegt in der Akzeptanz. RFC 8463 schreibt vor, dass Verifizierer Ed25519-SHA256 unterstützen müssen, empfiehlt jedoch lediglich die Unterstützung für die Signierung mit diesem Algorithmus. In der Praxis ist die Unterstützung durch E-Mail-Plattformen, MTAs und E-Mail-Anbieter nach wie vor uneinheitlich. Eine ausschließlich auf Ed25519 basierende Bereitstellung kann zu Lücken bei der DKIM-Verifizierung bei Empfängern führen, die diesen Algorithmus nicht unterstützen.
Aus diesem Grund sollte Ed25519 am besten zusammen mit RSA-2048 eingesetzt werden. RFC 8463 unterstützt ausdrücklich die doppelte Signatur, wodurch eine Nachricht sowohl eine RSA-SHA256- als auch eine Ed25519-SHA256-Signatur enthalten kann. Da ein Selektor nur einen öffentlichen Schlüssel veröffentlichen kann, muss jede Signatur einen anderen Selektor verwenden, während sie dieselbe Signaturdomäne nutzen. Empfänger verifizieren die von ihnen unterstützte Signatur, was Kompatibilität gewährleistet und es Organisationen gleichzeitig ermöglicht, Ed25519 einzuführen.
| Schlüssel-Länge | Sicherheitsstufe | Größe des DNS-Eintrags | Einhaltungsstatus (2026) | Empfohlene Verwendung |
|---|---|---|---|---|
| 1024-Bit-RSA | Schwach, veraltet | Passt in eine einzige TXT-Zeichenkette | Unterhalb des NIST-Mindestwerts; laut NIST nur für Altanwendungen; wird von Google als absolutes Minimum akzeptiert | Nur für Altbestände; planen Sie eine kontrollierte Migration auf 2048 Bit |
| 2048-Bit-RSA | Stark; aktueller Standard | ~392 Base64-Zeichen; muss in mehrere Zeichenfolgen aufgeteilt werden | Entspricht den Empfehlungen von RFC 8301, NIST und Google | Standard für fast alle Organisationen |
| 4096-Bit-RSA | Sehr stark | Größer; muss aufgeteilt werden; die meisten Empfänger werden die größte Datei überprüfen | Übertrifft die aktuellen Anforderungen | Nur für Hochsicherheitsbereiche oder regulierte Umgebungen |
| Ed25519 | Starker Algorithmus, kürzere Schlüssel als bei RSA | 44 Oktette; fasst eine TXT-Zeichenkette, keine Aufteilung in Blöcke | In RFC 8463 standardisiert; Prüfer MÜSSEN dies unterstützen, Unterzeichner SOLLTEN dies tun; die Unterstützung durch Empfänger ist noch uneinheitlich | Dual-Signatur in Verbindung mit RSA-2048 |
So überprüfen Sie die Länge Ihres aktuellen DKIM-Schlüssels
Bevor Sie eine Aktualisierung des DKIM-Schlüssels planen, überprüfen Sie die derzeit im DNS veröffentlichte Schlüsselgröße.
1. Ermitteln Sie Ihren DKIM-Selektor
Öffnen Sie die Kopfzeilen einer signierten E-Mail und suchen Sie die Feld „DKIM-Signature“ . Der Wert des Feldes s= Tag ist Ihr Selektor. Sie finden den Selektor auch in den DKIM-Konfigurationseinstellungen Ihres E-Mail-Anbieters.
2. Den DKIM-Eintrag nachschlagen
Abfrage selector._domainkey.yourdomain.com Verwenden Sie ein DKIM-Lookup-Tool oder ein DNS-Abfragetool, um den veröffentlichten TXT-Eintrag abzurufen.
3. Überprüfen Sie den öffentlichen Schlüssel
Bestimmen Sie den p= Tag im Datensatz. Dieser enthält den öffentlichen DKIM-Schlüssel. Die meisten DKIM-Abfrage-Tools ermitteln automatisch die Schlüssellänge und geben an, ob es sich um 1024 Bit, 2048 Bit oder eine andere Größe handelt.
4. Das Ergebnis auswerten
Falls die Domäne noch einen 1024-Bit-Schlüssel verwendet, planen Sie eine Umstellung auf 2048-Bit-RSA. Ist bereits ein 2048-Bit-Schlüssel im Einsatz und funktioniert dieser einwandfrei, sind in der Regel keine sofortigen Maßnahmen erforderlich.
Der PowerDMARC DKIM-Checker ruft Ihren veröffentlichten Eintrag ab und erkennt den Selektor der wichtigsten Anbieter automatisch, sodass Sie Ihre Schlüssellänge in Sekundenschnelle überprüfen können, anstatt Base64 manuell zu dekodieren. Probieren Sie es kostenlos aus
Das Problem des 2048-Bit-DNS-Chunkings (und wie man es vermeidet)
Eine der häufigsten Ursachen für DKIM-Fehler nach einer Umstellung auf einen 2048-Bit-Schlüssel ist die fehlerhafte Veröffentlichung von DNS-Einträgen.
Das Problem geht zurück auf Einschränkungen des DNS-TXT-Eintrags . Ein einzelner TXT-String kann maximal 255 Byte enthalten, während ein in Base64 kodierter 2048-Bit-RSA-öffentlicher Schlüssel in der Regel etwa 392 Zeichen lang ist. Daher kann der Schlüssel nicht als einzelner String veröffentlicht werden. Wenn ein DNS-Anbieter den Eintrag abschneidet oder ablehnt, schlägt die DKIM-Überprüfung fehl.
| Komponente | Einschränkung |
|---|---|
| Einzelner DNS-TXT-String | Maximal 255 Byte |
| Typischer öffentlicher RSA-Schlüssel mit 2048 Bit | Etwa 392 Base64-Zeichen |
| Ergebnis bei fehlerhafter Veröffentlichung | DKIM-Überprüfung fehlgeschlagen |
Um einen 2048-Bit-Schlüssel korrekt zu veröffentlichen, teilen Sie den öffentlichen Schlüssel auf mehrere in Anführungszeichen gesetzte Zeichenfolgen innerhalb desselben TXT-Eintrags auf. Das DNS fügt die Zeichenfolgen bei der Abfrage automatisch zusammen.
selector1._domainkey.example.com. IN TXT (
„v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1xN8s9k2“
„Qp7Yv3RwL0fHmZ2bKct5oXn8eW4uV1aA9dGqB6sT0pJrN3mC2hF7lYxoZ4kP1wIDAQAB“
)
Die Unterstützung für lange TXT-Einträge variiert je nach DNS-Anbieter. Bei einigen Plattformen müssen Administratoren mehrere Zeichenfolgen in Anführungszeichen manuell eingeben, während andere lange Werte automatisch aufteilen und wieder zusammensetzen. Überprüfen Sie stets die Formatierungsanforderungen Ihres Anbieters für DNS-Einträge, bevor Sie einen DKIM-Schlüssel veröffentlichen.
Beachten Sie bitte folgende Punkte:
| Anforderung | Erläuterung |
|---|---|
| Standort aufteilen | Der Schlüssel kann an beliebiger Stelle aufgeteilt werden. Das DNS setzt die Zeichenfolgen automatisch wieder zu einem einzigen Wert zusammen. |
| Zeichenkette Länge | Keine einzelne Zeichenkette sollte die DNS-Grenze von 255 Byte überschreiten. |
| Validierung | Überprüfen Sie nach der DNS-Propagierung den veröffentlichten DKIM-Eintrag und vergewissern Sie sich, dass der vollständige öffentliche Schlüssel zurückgegeben wird. |
| Fehlerbehebung | Wenn die E-Mail zwar erfolgreich signiert wird, die Empfänger jedoch Fehler bei der DKIM-Überprüfung melden, überprüfen Sie den veröffentlichten öffentlichen Schlüssel auf eventuelle Kürzungen oder Formatierungsfehler. |
Nachdem Sie einen neuen DKIM-Schlüssel veröffentlicht haben, überprüfen Sie den DNS-Eintrag und vergewissern Sie sich, dass die empfangenden Server den vollständigen öffentlichen Schlüssel fehlerfrei abrufen können.
Wann und wie DKIM-Schlüssel rotiert werden sollten
Die DKIM-Schlüsselrotation verringert das Risiko, das mit einer langfristigen Offenlegung von Schlüsseln verbunden ist, und ist eine gängige Anforderung in Sicherheits- und Compliance-Programmen. Zwar ist im DKIM-Standard kein allgemeingültiger Rotationszeitplan festgelegt, doch viele Unternehmen rotieren ihre Signaturschlüssel im Rahmen ihrer routinemäßigen Sicherheitsmaßnahmen alle 6 bis 12 Monate.
Ein sicherer DKIM-Rotationsprozess sieht vor, dass ein neuer Selektor eingeführt wird, bevor der bestehende außer Kraft gesetzt wird. Dadurch wird eine lückenlose DKIM-Validierung während des gesamten Übergangs gewährleistet.
- Schritt 1: Generieren Sie ein neues DKIM-Schlüsselpaar und weisen Sie ihm einen neuen Selektor zu. Viele Unternehmen verwenden datumsbasierte Selektornamen, um die Nachverfolgung und Überprüfung zu vereinfachen.
- Schritt 2: Veröffentlichen Sie den neuen öffentlichen Schlüssel im DNS unter dem neuen Selektor. Wenn Sie einen 2048-Bit-RSA-Schlüssel verwenden, stellen Sie sicher, dass der DNS-Eintrag korrekt veröffentlicht wird.
- Schritt 3: Warten Sie, bis die DNS-Verbreitung entsprechend der TTL des Eintrags abgeschlossen ist.
- Schritt 4: Aktualisieren Sie den Mailserver oder E-Mail-Dienstanbieter, damit Nachrichten mit dem neuen Selektor signiert werden.
- Schritt 5: Lassen Sie den bisherigen Selektor aktiv, bis die mit dem alten Schlüssel signierten Nachrichten die normalen Zustellwege durchlaufen haben und die DNS-Caches abgelaufen sind.
- Schritt 6: Entfernen Sie den alten Selektor und den dazugehörigen DNS-Eintrag, sobald dieser nicht mehr verwendet wird.
Dieser Ansatz ermöglicht es, dass beide Selektoren während der Übergangsphase nebeneinander bestehen können, wodurch Fehler bei der DKIM-Überprüfung verhindert werden, die durch Verzögerungen bei der DNS-Propagierung oder zwischengespeicherte Einträge verursacht werden.
Für Organisationen, die mehrere Domains, Selektoren oder E-Mail-Dienste verwalten, kann es schwierig sein, die manuelle Rotation konsequent aufrechtzuerhalten.
Anforderungen an die DKIM-Schlüssellänge nach Plattform und Compliance-Rahmenwerk
Die Anforderungen an die Länge von DKIM-Schlüsseln variieren je nach E-Mail-Anbieter, Sicherheitsstandard und Compliance-Rahmenwerk. Während einige Rahmenwerke explizite kryptografische Anforderungen festlegen, orientieren sich andere an allgemeineren Branchenrichtlinien und Best Practices.
Compliance- und Anbieteranforderungen
| Framework / Anbieter | Anforderungen an die Länge des DKIM-Schlüssels |
|---|---|
| Anforderungen für Massenversender bei Google | Mindestens 1024 Bit; 2048 Bit empfohlen |
| Anforderungen an Yahoo-Absender | Entspricht im Großen und Ganzen den Absenderanforderungen von Google |
| NIST SP 800-131A, Rev. 2 | RSA-Schlüssel mit einer Länge von weniger als 2048 Bit sind für die Erstellung digitaler Signaturen nicht zugelassen. |
| HIPAA-regulierte Umgebungen | Befolgen Sie in der Regel die kryptografischen Richtlinien des NIST, wonach 2048-Bit-RSA das praktische Minimum darstellt. |
| FedRAMP-Umgebungen | Einhaltung der kryptografischen NIST-Standards und der zugelassenen Schlüssellängen |
| PCI-DSS-Umgebungen | Es gibt keine spezifischen Anforderungen an die Schlüssellänge für DKIM, doch Organisationen halten sich in der Regel an die vom NIST empfohlenen kryptografischen Praktiken. |
Plattformunterstützung und Standardeinstellungen
| Plattform | Überlegungen zur DKIM-Schlüssellänge |
|---|---|
| cPanel | In einigen Konfigurationen werden standardmäßig häufig 1024-Bit-DKIM-Schlüssel verwendet. Überprüfen Sie die Länge des veröffentlichten Schlüssels, bevor Sie von einer Konformität ausgehen. |
| Microsoft Exchange 2013/2016 | Die Unterstützung für Schlüssellängen und die Standardwerte können je nach Bereitstellungsmethode und DKIM-Implementierung variieren. |
| Google Arbeitsbereich | Unterstützt 2048-Bit-DKIM-Schlüssel nativ. |
| Microsoft 365 | Unterstützt 2048-Bit-DKIM-Schlüssel nativ. |
| Moderne Cloud-E-Mail-Plattformen | Unterstützt grundsätzlich die Implementierung von 2048-Bit-DKIM ohne zusätzliche Konfigurationsanforderungen. |
Bei allen großen E-Mail-Anbietern, Sicherheitskonzepten und Unternehmensumgebungen gilt nach wie vor ein 2048-Bit-RSA-Schlüssel als empfohlene DKIM-Schlüssellänge. Er erfüllt aktuelle Sicherheitsrichtlinien, umfassende Kompatibilitätsanforderungen und Compliance-Vorgaben und vermeidet gleichzeitig die mit größeren RSA-Schlüsseln verbundenen Herausforderungen bei der Bereitstellung.
So generieren Sie einen 2048-Bit-DKIM-Schlüssel
Ein 2048-Bit-DKIM-Schlüsselpaar lässt sich mithilfe eines Tools zur DKIM-Schlüsselgenerierung oder direkt über die Befehlszeile erstellen.
Methode 1: Verwenden Sie einen DKIM-Schlüsselgenerator
Der PowerDMARC DKIM-Generator erstellt ein 2048-Bit-DKIM-Schlüsselpaar und stellt den öffentlichen Schlüssel in einem DNS-kompatiblen Format sowie den dazugehörigen privaten Schlüssel für Ihren Mailserver oder Ihre E-Mail-Plattform bereit.
Methode 2: Ein Schlüsselpaar mit OpenSSL generieren
# Einen 2048-Bit-privaten Schlüssel generieren
openssl genrsa -out dkim_private.key 2048
# Den passenden öffentlichen Schlüssel extrahieren
openssl rsa -in dkim_private.key -pubout -out dkim_public.key
Befolgen Sie nach der Erstellung des Schlüsselpaars die folgenden bewährten Vorgehensweisen:
| Empfehlung | Details |
|---|---|
| Verwenden Sie einen beschreibenden Selektor | Datumsbasierte Selektoren wie 20260101 oder jan2026 vereinfachen die Schlüsselverwaltung und die Nachverfolgung von Schlüsselrotationen. |
| Schützen Sie den privaten Schlüssel | Speichern Sie den privaten Schlüssel ausschließlich auf dem System, das für die DKIM-Signierung zuständig ist. Er darf niemals im DNS veröffentlicht oder öffentlich weitergegeben werden. |
| Den öffentlichen Schlüssel im DNS veröffentlichen | Fügen Sie den öffentlichen Schlüssel zum entsprechenden TXT-Eintrag „selector._domainkey“ hinzu. |
| DNS-Formatierung überprüfen | Wenn Sie einen 2048-Bit-RSA-Schlüssel verwenden, stellen Sie sicher, dass der öffentliche Schlüssel korrekt veröffentlicht wird und die Längenbeschränkungen für DNS-TXT-Einträge einhält. |
| Vor der Bereitstellung testen | Stellen Sie sicher, dass der DKIM-Eintrag öffentlich zugänglich ist und dass Nachrichten, die mit dem neuen Selektor signiert sind, die DKIM-Validierung bestehen. |
Nachdem der Schlüssel veröffentlicht wurde und die DNS-Verbreitung abgeschlossen ist, aktualisieren Sie Ihre E-Mail-Plattform, um Nachrichten mit dem neuen Selektor zu signieren.
Die richtige Verwaltung der DKIM-Schlüssellänge im Jahr 2026
Ein korrekt generierter, veröffentlichter und gepflegter 2048-Bit-Schlüssel bietet einen besseren Schutz vor Fälschungen, ohne dass dabei Probleme bei der Zustellbarkeit entstehen. Ein falsch veröffentlichter Schlüssel kann jedoch die DKIM-Überprüfung untergraben, unabhängig von seiner kryptografischen Stärke.
Bevor Sie Änderungen vornehmen, überprüfen Sie Ihre aktuelle DKIM-Konfiguration. Falls Sie noch einen 1024-Bit-Schlüssel verwenden, planen Sie eine kontrollierte Umstellung auf 2048-Bit-RSA. Falls Sie bereits 2048-Bit nutzen, überprüfen Sie die Konfiguration Ihrer DNS-Einträge, richten Sie einen Prozess zur Schlüsselrotation ein und überwachen Sie regelmäßig Ihre Authentifizierungsergebnisse.
Eine starke E-Mail-Authentifizierung hängt nicht nur von der Wahl der richtigen Schlüssellänge ab. Sie hängt vielmehr davon ab, dass der gesamte DKIM-Lebenszyklus korrekt verwaltet wird – von der Schlüsselgenerierung über die Veröffentlichung im DNS bis hin zur Rotation und der fortlaufenden Validierung.
FAQs
Verlangt Google im Jahr 2026 eine 2048-Bit-DKIM-Signatur?
Die Richtlinien von Google für Massenversender akzeptieren zwar mindestens 1024 Bit, empfehlen jedoch dringend 2048 Bit. Da das NIST die Verwendung von 1024-Bit-RSA zur Erstellung digitaler Signaturen untersagt, gilt 2048 Bit unabhängig von der Beschränkung durch Google als praktischer Standard.
Was passiert, wenn ich einen 1024-Bit-DKIM-Schlüssel verwende?
Ihre E-Mails werden bei Empfängern, die 1024-Bit akzeptieren – darunter auch Gmail –, weiterhin authentifiziert. Allerdings liegt die Verschlüsselungsstärke unter dem von NIST festgelegten Mindestwert von 2048 Bit, was dazu führen kann, dass Konformitätsprüfungen nicht bestanden werden, und die Verschlüsselung kann von Angreifern mit ausreichenden Ressourcen geknackt werden.
Wie teile ich einen 2048-Bit-DKIM-Schlüssel im DNS auf?
Ein 2048-Bit-öffentlicher Schlüssel (~392 Zeichen) überschreitet die Begrenzung von 255 Byte für TXT-Zeichenfolgen, daher teilen Sie ihn innerhalb desselben TXT-Eintrags in durch Anführungszeichen getrennte Zeichenfolgen auf. Das DNS fügt diese automatisch zusammen. Überprüfen Sie die Gültigkeit nach der Veröffentlichung mit einem DKIM-Prüftool.
Wird Ed25519 DKIM von Gmail und Outlook unterstützt?
Die Unterstützung verbessert sich zwar, ist aber im Jahr 2026 je nach Empfänger und ESP noch uneinheitlich. Verwenden Sie nicht ausschließlich Ed25519 zur Signierung. Führen Sie eine doppelte Signierung mit RSA-2048 und Ed25519 durch, damit Empfänger, die Ed25519 nicht unterstützen, auf RSA zurückgreifen können.
Wie oft sollten DKIM-Schlüssel ausgetauscht werden?
Alle 6 bis 12 Monate gilt als allgemein empfohlene Vorgehensweise. Verwenden Sie eine Parallel-Selector-Methode, damit der alte Schlüssel so lange gültig bleibt, bis der neue Schlüssel übernommen wurde, und die E-Mails während des Wechsels weiterhin signiert bleiben.





