DKIM-Schlüssel: Länge, DNS und planbare Rotation

Ihr DKIM-Schlüssel ist Teil der DNS-Konfiguration, die erfolgreiche Authentifizierung ermöglicht. Ein zu schwacher, ungültiger oder veralteter Schlüssel kann die Prüfung und Zustellung beeinträchtigen. Der Artikel beschreibt Gmail-Anforderungen seit Februar 2024 und eine weitere Verschärfung ab November 2025; maßgeblich sind die aktuellen Absendervorgaben. Wenn Sie zunächst DNS-Grundlagen bereinigen, beginnen Sie mit Geschäftsmail und kehren anschließend hierher zurück.

Die Kurzfassung: Verwenden Sie nach Möglichkeit einen 2048-Bit-RSA-Schlüssel. Veröffentlichen Sie ihn korrekt im DNS; lange TXT-Werte bestehen häufig aus mehreren Zeichenketten in Anführungszeichen. Rotieren Sie planmäßig mit Selektoren und behalten Sie den alten Eintrag für eine passende Übergangszeit. Das reduziert vermeidbare Risiken.

Für eine neue Domain ergänzen Sie dies durch E-Mail mit eigener Domain erstellen und TrekMails Prüfliste zu erforderlichen DNS-Einträgen, um DKIM, SPF und DMARC gemeinsam einzurichten.

Was ist ein DKIM-Schlüssel?

Gemeint ist hier der öffentliche Teil der DKIM-Signierkonfiguration. Ihr Mailserver signiert mit einem privaten Schlüssel; Empfangsserver laden den öffentlichen Schlüssel aus dem DNS und prüfen die Integrität der signierten Teile sowie die Verantwortung der Signaturdomain. Das bestätigt nicht automatisch die Vertrauenswürdigkeit des sichtbaren From-Absenders.

DKIM steht für DomainKeys Identified Mail. Der private Schlüssel liegt im sendenden System, der öffentliche im DNS unter einem Selektor, etwa s1._domainkey.example.com.

Der Empfangsserver liest die DKIM-Signatur, fragt den Schlüssel ab und prüft sie nach der angegebenen Kanonisierung. Bei Erfolg lässt sich Folgendes feststellen:

• Die erfassten Nachrichtenteile und signierten Header wurden nicht in einer die Prüfung beeinträchtigenden Weise verändert.
• Der Signierer verfügte über den privaten Schlüssel für diese Domain und diesen Selektor.

Das garantiert keine Posteingangsplatzierung. Es liefert ein kryptografisch prüfbares Signal, das moderne Filtersysteme berücksichtigen können.

Welche Schlüssellänge sollten Sie wählen?

Ein 2048-Bit-RSA-Schlüssel empfiehlt sich nach Möglichkeit für Konfigurationen der Jahre 2025 und 2026. Der Standard erlaubt weiterhin 1024-Bit-RSA, empfiehlt aber 2048 Bit als stärkere Basis. 4096-Bit-Schlüssel vergrößern DNS-Antworten und können zusätzliche Kompatibilitäts- und Betriebsprobleme verursachen.

Die formale Grundlage ist RFC 8301: Signierer müssen mindestens 1024-Bit-RSA verwenden und sollten mindestens 2048-Bit-RSA nutzen. Die Empfehlung ist für die Planung einer zeitgemäßen Konfiguration wichtig.

Übernehmen Sie eine ältere Mailplattform, prüfen Sie den Schlüssel ausdrücklich. Ältere Panels erzeugten häufig standardmäßig 1024-Bit-Schlüssel. Eine damals zulässige Einstellung ist nicht automatisch die heutige Empfehlung.

Google verlangt DKIM für Massenversender und beschreibt mögliche Drosselung bei fehlgeschlagener Authentifizierung. Siehe Googles FAQ zu den Absenderrichtlinien für die aktuellen Anforderungen.

Warum 2048-Bit-DKIM-Schlüssel im DNS Probleme machen

Ein 2048-Bit-Schlüssel ist länger als eine einzelne TXT-Zeichenkette mit höchstens 255 Oktetten. Erwartet das DNS-Panel eine ungeteilte lange Eingabe, kann es diese ablehnen, kürzen oder falsch speichern.

Häufig liegt das Problem also nicht an der Kryptografie, sondern an der DNS-Oberfläche.

Der öffentliche Wert im Tag p= eines 2048-Bit-RSA-Schlüssels muss meist auf mehrere Zeichenketten innerhalb eines TXT-Eintrags verteilt werden. Der DKIM-Prüfer beziehungsweise die Anwendung setzt diese zusammen, nicht grundsätzlich der DNS-Resolver. Eine fehlerhafte Veröffentlichung kann die Prüfung verhindern.

Typische Fehler:

• Das Panel kürzt den Eintrag bei 255 Zeichen.
• Es fügt Leerzeichen oder Zeilenumbrüche in die Schlüsseldaten ein.
• Sie veröffentlichen mehrere TXT-Einträge statt mehrerer Zeichenketten in einem Eintrag.
• Beim Kürzen geht ein Teil des Präfixes v=DKIM1; k=rsa; p= verloren.

Das Ergebnis ist dann kein schwächerer, sondern ein ungültiger DKIM-Schlüssel.

2048-Bit-DKIM-Schlüssel korrekt veröffentlichen

Veröffentlichen Sie pro Selektor einen eindeutigen TXT-Eintrag und teilen Sie den langen Wert nur in dessen Zeichenketten auf. Der Prüfer setzt sie zusammen. Kontrollieren Sie Syntax und tatsächliche DNS-Antwort per Kommandozeile.

In einer Zonendatei sieht das so aus:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

Viele Weboberflächen erwarten denselben Eintrag in einer Zeile:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

Prüfen Sie anschließend von außen, statt nur der Vorschau zu vertrauen:

dig txt s1._domainkey.example.com +short

Die TXT-Antwort muss vollständig sein. Zwei Zeichenketten in Anführungszeichen sind normal. Fehlende Teile, ungewöhnliche Maskierung oder unvollständige Ausgabe sollten Sie mit der tatsächlichen Veröffentlichung und dem verwendeten Tool abgleichen.

Bei TrekMail können Sie verwaltetes TrekMail-SMTP und den DNS-Assistenten verwenden. Das beschriebene Angebot sieht verwaltetes SMTP in kostenpflichtigen Tarifen und den domainspezifischen DKIM-Eintrag im Dashboard vor. Starter wird ab $3.50 pro Monat beschrieben, kostenpflichtige Tarife mit einer 14-tägigen kostenlosen Testphase und erforderlicher Kreditkarte. Nano wird als kostenlos mit eigenem SMTP angeboten. Prüfen Sie aktuelle Leistungen und Bedingungen.

Beispiel: Sie erzeugen einen 2048-Bit-Schlüssel, doch der Registrar kürzt den TXT-Wert ohne Hinweis. Nachrichten werden weiterhin gesendet; erst die fehlgeschlagene Authentifizierung zeigt den Fehler. Deshalb ist die externe Prüfung wichtig.

DKIM-Schlüssel mit geringerem Versandrisiko rotieren

Veröffentlichen Sie einen neuen Schlüssel unter einem neuen Selektor, stellen Sie die Signierung um und behalten Sie den alten Eintrag während einer geeigneten Übergangszeit. Vermeiden Sie direktes Überschreiben aktiver Schlüssel. Neue Selektoren helfen, verzögerte oder erneut zugestellte Nachrichten weiterhin zu prüfen.

Ein vorsichtiger Ablauf:

1. Ein neues 2048-Bit-Schlüsselpaar erzeugen.
2. Einen neuen Selektor wie s2 zuweisen.
3. s2._domainkey.example.com im DNS veröffentlichen.
4. Die ausgehende Signierung auf s2 umstellen.
5. s1 für eine passende Zeit von mehreren Tagen beibehalten.
6. s1 erst entfernen, wenn alte signierte Nachrichten den Schlüssel nicht mehr benötigen.

Eine Übergangszeit von 7 Tagen ist ein mögliches Beispiel, keine allgemeine Zusage. Sie muss zu Warteschlangen, Wiederholungsversuchen und DNS-Caches passen. Bei kompromittiertem Schlüssel kann ein sofortiger Widerruf wichtiger sein als die Prüfung alter Nachrichten.

Ersetzen Sie den Schlüssel am selben Selektor nur, wenn Sie die Folgen für Signierung, Caches und verzögerte Nachrichten kontrollieren. Dafür sind Selektoren gedacht.

Dokumentieren Sie bei mehreren Versandsystemen deren Selektorzuordnung. Das hilft bei Fehlern aus CRM, Ticketsystem, Webanwendung und Postfachanbieter derselben Domain.

Wann sollten Sie einen DKIM-Schlüssel rotieren?

Planen Sie regelmäßige Rotation und zusätzliche Wechsel nach möglicher Offenlegung, Anbieteränderung oder Migration. Ein halbjährlicher Rhythmus ist ein möglicher Ausgangspunkt; risikoreiche Umgebungen benötigen gegebenenfalls kürzere Intervalle. Wichtiger als spontane Einzelaktionen ist eine nachvollziehbare Richtlinie.

Bei möglichem Schlüsselverlust handeln Sie sofort. Ansonsten rotieren Sie planmäßig und prüfen das Ergebnis.

Gründe für vorzeitige Rotation:

• Wechsel des ausgehenden Versandanbieters.
• Ausscheiden eines Anbieters mit Signierzugriff.
• Schlüsselexport über einen unsicheren Ablauf.
• Entdeckung eines unklaren alten gemeinsamen Administratorkontos.

Ungeeignete Begründungen fürs Aufschieben:

• „Später, wenn wir Zeit haben.“
• „Die Signatur besteht noch, also ist alles in Ordnung.“
• „Wir wissen nicht mehr, wo der private Schlüssel liegt.“

Bei vielen Kundendomains wird das zu einer Prozessaufgabe. Deshalb ist E-Mail-Hosting für mehrere Domains relevant. Eine Domain lässt sich manuell verwalten, fünfzig verlangen einen belastbaren Ablauf.

Sollten Sie Ed25519 für DKIM nutzen?

Ed25519 liefert deutlich kürzere Schlüssel und vermeidet viele Probleme langer RSA-2048-TXT-Werte. Die Unterstützung muss allerdings geprüft werden. Das Verfahren wurde für DKIM in RFC 8463 standardisiert; RSA-2048 ist häufig der konservativere Ausgangspunkt für breite Interoperabilität.

Der Hauptvorteil ist die Größe. Ein Ed25519-Public-Key ist wesentlich kürzer als ein RSA-Schlüssel, was die DNS-Veröffentlichung erleichtert.

Der Nachteil sind unterschiedliche Implementierungen bei Empfängern und Tools. RSA-2048 ist breit eingesetzt, garantiert aber ebenfalls keine universelle Kompatibilität. Unterstützt die Plattform doppelte Signierung, können Sie Ed25519 neben RSA entlang Ihrer tatsächlichen Versandwege testen.

Für die meisten Betreiber ist folgender Ansatz sinnvoll:

• RSA-2048 als bevorzugte Ausgangskonfiguration verwenden.
• Ed25519 einsetzen, wenn Unterstützung und aussagekräftige Tests vorhanden sind.
• Nicht allein wegen des kürzeren DNS-Eintrags ausschließlich auf Ed25519 umstellen.

Alter und neuer Ansatz: DKIM für viele Domains verwalten

Der alte Ansatz besteht aus manuellen TXT-Änderungen, langen Schlüsseln in unterschiedlichen Panels und vergessenen Rotationsterminen. Der neue Ansatz bündelt wiederholbare DNS- und Signierprozesse und behandelt den Schlüssellebenszyklus als Bestandteil der Mailplattform.

Alter Ansatz:

• Jede Domain hat eine andere DNS-Oberfläche.
• Rotation hängt an leicht übersehenen Kalendererinnerungen.
• Ein Tippfehler beim Registrar beeinträchtigt Kundenmail und fällt erst später auf.

Neuer Ansatz:

• Ein gemeinsamer Ablauf für viele Domains.
• Verwaltetes SMTP kann die Signierung vereinheitlichen.
• Weniger wiederholte Fehlersuche bei langen TXT-Werten und abweichender Authentifizierung.

TrekMail beschreibt Mehrdomain-Hosting zum Pauschalpreis statt Abrechnung pro Nutzer, gemeinsamen Speicher, IMAP-Postfächer, integrierte IMAP-Migration, Catch-all und Weiterleitung sowie BYO SMTP in Nano und verwaltetes SMTP in kostenpflichtigen Tarifen. Prüfen Sie die aktuellen Leistungen. Bei mehreren Weiterleitungsregeln sollten Sie auch Authentifizierungsänderungen untersuchen; hilfreich ist Domain-E-Mail an Gmail weiterleiten.

Für Teams und Agenturen liegt der mögliche Vorteil in einem einheitlichen Ablauf, nicht in garantiert fehlerfreiem DNS. Das beschriebene Starter-Angebot beginnt bei $3.50 pro Monat; aktuelle Konditionen prüfen.

Fazit zum DKIM-Schlüssel

Verwenden Sie nach Möglichkeit RSA-2048, veröffentlichen und prüfen Sie den Schlüssel korrekt und rotieren Sie planmäßig mit Selektoren. Bestehende 1024-Bit-Schlüssel sollten Sie auf einen sinnvollen Wechsel prüfen. Beschädigt das DNS-Panel lange TXT-Werte, ändern Sie die Veröffentlichung oder übertragen Sie die Verwaltung an einen geeigneten Dienst.

Betrachten Sie DKIM nicht isoliert. SPF, DMARC und die tatsächlichen Versandwege müssen ebenfalls korrekt konfiguriert sein. Nächste Schritte sind TrekMails erforderliche DNS-Einträge und E-Mail mit eigener Domain erstellen.