DKIM-Schlüssel — Länge, Algorithmus, signierte Header

Signatur bestanden heißt nicht Signatur gut

Der DKIM-Check beantwortet eine binäre Frage: Passt die Signatur zum Schlüssel im DNS? Diese Seite beantwortet die zweite, unbequemere: Ist die Signatur überhaupt etwas wert? Eine Signatur mit 1024-Bit-Schlüssel, die nur den Betreff abdeckt und mit einem l=-Tag versehen ist, gilt formal als pass — und schützt trotzdem fast nichts.

Die Angaben stehen alle im DKIM-Signature-Header der Nachricht und im TXT-Record unter <selector>._domainkey.<domain>. Beides liest der Report aus und stellt es nebeneinander.

Was AnalyzeMy.Email prüft

• Selector aus dem s=-Tag — der Name, unter dem der öffentliche Schlüssel im DNS steht. Er ist der Grund, warum sich DKIM nur mit einer echten Nachricht prüfen lässt und nicht aus dem DNS allein.
• Signaturalgorithmus aus a= — rsa-sha256 ist der Standard, rsa-sha1 ist überholt und wird von RFC 8301 ausdrücklich verboten. ed25519-sha256 ist die moderne Alternative mit sehr kurzem Record.
• Schlüssellänge aus dem p=-Tag des DNS-Records, berechnet aus dem tatsächlichen Schlüsselmaterial.
• Signierte Header aus h= — welche Kopfzeilen die Signatur tatsächlich abdeckt.
• Body-Length-Tag l= — falls gesetzt, deckt die Signatur nur die ersten n Byte des Nachrichtentexts ab.
• Kanonisierung aus c= — relaxed/relaxed überlebt kleinere Umformatierungen unterwegs, simple/simple nicht.

Der Record wird dabei aus mehreren TXT-Teilstrings korrekt zusammengesetzt: Ein 2048-Bit-Schlüssel passt nicht in die 255 Byte, die ein einzelner Character-String fasst, und kommt zwangsläufig zerlegt an.

Wo die Schwachstellen liegen

1024 Bit. RFC 8301 setzt 1024 als absolutes Minimum und empfiehlt 2048. Viele Systeme signieren trotzdem noch mit 1024, weil der Record dann bequem in einen einzelnen TXT-String passt. Das ist kein tragfähiger Grund — die Aufteilung auf mehrere Strings ist Standard und funktioniert überall.

Das l=-Tag. Es begrenzt die Signatur auf die ersten n Byte des Bodys. Alles danach kann ein Angreifer anhängen, ohne die Signatur zu brechen — die Nachricht bleibt pass, obwohl unten jetzt ein fremder Text steht. Es gibt keinen Anwendungsfall, der dieses Risiko rechtfertigt.

Zu wenig signierte Header. Steht From nicht in h=, ist die Signatur für DMARC wertlos, denn Alignment bezieht sich genau auf diesen Header. Sinnvoll ist außerdem, Subject, Date, To und Message-ID mitzunehmen. Ein Header, der doppelt in h= steht, ist übrigens Absicht und kein Fehler: Damit wird verhindert, dass jemand eine zweite Kopie desselben Headers ergänzt.

Empfehlungen

• 2048 Bit RSA als Standard, rsa-sha256 als Algorithmus.
• l= nicht setzen. Wenn dein Mailer es standardmäßig ergänzt, abschalten.
• h= muss from enthalten — ohne das trägt DKIM nichts zu DMARC bei.
• Ed25519 nur zusätzlich: Nicht jeder Empfänger unterstützt es. Wer es einsetzt, signiert doppelt und behält RSA als Rückfallebene.
• Schlüssel regelmäßig wechseln — über zwei Selectors, damit unterwegs befindliche Nachrichten weiter verifizieren.