Ein 1024-Bit-DKIM-Schlüssel passt in eine einzige DNS-TXT-Zeichenkette. Ein 2048-Bit-Schlüssel nicht, und diese eine Tatsache erklärt fast alles, was beim Aufrüsten einer Domain schiefgeht: Der Record muss als mehrere Zeichenketten in Anführungszeichen veröffentlicht werden, die ein Prüfer wieder zusammensetzt, und die Werkzeuge dazwischen spielen nicht immer mit. Der Schlüssel, der am anderen Ende herauskommt, ist kürzer als der, den Sie erzeugt haben, und nichts in Ihrem Mailfluss sagt es Ihnen.
RFC 8301 hat das 2018 ausdrücklich benannt. Er verlangt von Signierern mindestens 1024 Bit und empfiehlt mindestens 2048, und er erklärt im selben Dokument, warum die stärkeren Schlüssel selten blieben: DNS-Provisionierungssoftware, die nur eine 255-Byte-Zeichenkette in einem TXT-Record verarbeitet, kann sie nicht aufnehmen.
Die Schlüssellänge ist der p=-Wert, und nur der p=-Wert
Ein DKIM-Record ist ein TXT-Record unter <selector>._domainkey.<domain>, der einen öffentlichen Schlüssel enthält. Das Tag p= trägt ihn, base64-kodiert, und seine Länge ist die Länge des Schlüssels. Nichts sonst im Record nennt die Stärke: kein Bit-Tag, keine Algorithmusgröße, kein Feld, das ein DNS-Panel Ihnen zeigen könnte.
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
Bei einem RSA-Schlüssel enthält p= eine SubjectPublicKeyInfo-Struktur: einen verschachtelten Container mit der Algorithmuskennung und danach dem Modulus und dem Exponenten. Die Bitlänge ist die Breite dieses Modulus, und deshalb heißt sie zu lesen, die Struktur zu parsen statt die Zeichenkette zu messen.
Das zählt mehr, als es klingt, denn die Länge der Zeichenkette und die Länge des Schlüssels gehen in dem Moment auseinander, in dem irgendetwas den Wert abschneidet.
2048 Bit passen nicht in eine DNS-Zeichenkette
Ein DNS-TXT-Record besteht aus Zeichenketten von je höchstens 255 Byte. Längere Werte werden als mehrere Zeichenketten in Anführungszeichen veröffentlicht, die ein Empfänger ohne Trennzeichen aneinanderfügt. An frisch erzeugten Schlüsseln gemessen, kostet jede Größe Folgendes.
| Schlüssel | base64-p=-Wert | Ganzer Record | Nötige DNS-Zeichenketten |
|---|---|---|---|
| RSA 1024 | 216 Zeichen | 234 | 1 |
| RSA 2048 | 392 Zeichen | 410 | 2 |
| RSA 4096 | 736 Zeichen | 754 | 3 |
| Ed25519 | 44 Zeichen | 66 | 1 |
Der Beispiel-Record in RFC 8463 selbst veröffentlicht einen RSA-Schlüssel in vier Zeichenketten in Anführungszeichen, und ein Prüfer fügt sie ohne irgendetwas dazwischen zusammen. Das ist korrektes DNS, und ein Prüfer kommt damit mühelos zurecht.
Der Fehler sitzt vor dem Prüfer. Ein Provisionierungspanel, das nur eine Zeichenkette annimmt, behält still die ersten 255 Zeichen. Ein Panel, das den ganzen Wert annimmt, aber dort ein Leerzeichen oder einen Zeilenumbruch einfügt, wo die Anführungszeichen standen, erzeugt ein base64 mit einem Zeichen, das nicht zum Alphabet gehört. Ein Export und Reimport über eine Zonendatei kann die Anführungszeichen ganz verlieren. Jeder dieser Fälle erzeugt einen Record, der weiterhin mit v=DKIM1; k=rsa; p= beginnt und im Browser weiterhin richtig aussieht.
Ein abgeschnittener Schlüssel liest sich als selbstsicheres 2048, wenn man dem Record glaubt
Das ist der Teil, bei dem Sorgfalt zählt, denn er entscheidet, ob ein Prüfwerkzeug etwas taugt.
Die Länge eines RSA-Modulus wird innerhalb der Schlüsselstruktur deklariert. Ein Leser, der der deklarierten Länge glaubt, findet den Modulus-Header, liest die Zahl der Bytes, die er zu haben behauptet, und meldet die Größe, die diese Bytes darstellen würden. Wurde der Wert nach diesem Header abgeschnitten, ist die deklarierte Länge weiterhin 2048 Bit wert, obwohl die Bytes fehlen, und der Leser antwortet ohne Zögern "2048". Schneidet man einen echten Schlüssel an jedem Byte-Offset ab, wird die überwiegende Mehrheit dieser Schnitte als intakter Schlüssel der beabsichtigten Größe gemeldet.
Unser eigener DKIM-Checker verlangt, dass jede verschachtelte Länge in der Struktur genau dort endet, wo ihr Container endet. Ein irgendwo abgeschnittener Schlüssel oder einer mit angehängtem Müll lässt sich nicht parsen, statt eine kürzere oder die beabsichtigte Größe zu melden, und ein nicht parsebarer Schlüssel wird als Fehler gemeldet und nicht als fehlender. Ein Schlüssel, der nichts verifiziert, und ein Schlüssel, der nicht veröffentlicht ist, sind verschiedene Probleme mit verschiedenen Lösungen, und ein Prüfwerkzeug, das sie gleich meldet, schickt Sie an die falsche Stelle.
Über die Domains, die wir für den Unspam 2026 Email Deliverability Benchmark testen, signieren 90 % mit einem funktionierenden DKIM-Schlüssel, das ist also keine Lücke in der Verbreitung. Es ist eine Art stiller Defekt innerhalb dieser 90 %.
Ein leeres p= ist ein Widerruf, kein fehlender Schlüssel
v=DKIM1; k=rsa; p= ohne irgendetwas hinter dem Gleichheitszeichen ist ein gültiger Record, und er bedeutet, dass der Schlüssel widerrufen wurde. RFC 6376 definiert das absichtlich so, damit ein kompromittierter Schlüssel zurückgezogen werden kann, ohne den Record zu löschen und Prüfer raten zu lassen, ob der Name einfach nicht aufgelöst hat.
Behandeln Sie den Unterschied als echt. Ein widerrufener Selektor ist eine Entscheidung, die jemand getroffen hat; ein fehlender Selektor ist eine Einführung, die nicht fertig wurde. In einer DNS-Abfrage sehen sie sich fast gleich, und sie verlangen entgegengesetzte Reaktionen.
Dasselbe gilt für eine Rotation. Selektoren gibt es, damit eine Domain mehrere Schlüssel gleichzeitig führen kann, und dass s1._domainkey und s2._domainkey zusammen live sind, ist der Weg zu einer Rotation ohne Lücke. Die Signatur nennt den verwendeten Selektor, und ein Prüfer schlägt nur diesen nach, also ist den neuen Schlüssel vor dem Umstellen des Signierers zu veröffentlichen die sichere Reihenfolge, und den alten zu entfernen, bevor die letzte damit signierte Nachricht zugestellt ist, die unsichere.
Ed25519-Schlüssel sind 32 rohe Bytes, keine Schlüsselstruktur
RFC 8463 hat die Ed25519-Signatur hinzugefügt, und der Record dafür hat nicht die Form des RSA-Records. Mit k=ed25519 ist der p=-Wert der rohe 32-Byte-Schlüssel und keine SubjectPublicKeyInfo, weshalb er zu 44 base64-Zeichen wird und immer in eine DNS-Zeichenkette passt.
Die praktische Folge ist, dass jede andere Länge kein Schlüssel ist. Ein 30-Byte-Fragment, ein abgeschnittener Wert oder ein ganzer RSA-Schlüssel, der unter einem ed25519-Tag zurückgeblieben ist, sind alle unbrauchbar, und ein Prüfwerkzeug, das bei jedem nicht leeren Wert "Ed25519, vorhanden" meldet, sagt Ihnen nichts. Prüfen Sie die Länge, nicht das Vorhandensein.
Die Verbreitung ist noch dünn genug, dass Ed25519 üblicherweise neben RSA veröffentlicht wird statt an dessen Stelle, denn ein Prüfer ohne Unterstützung behandelt die Signatur als nicht verifizierbar, statt auf die andere zurückzufallen.
t=y lässt die Signatur für nichts zählen, egal welcher Schlüssel
Das Tag t trägt Flags, und t=y bedeutet, dass die Domain im Testbetrieb ist. RFC 6376 sagt einem Prüfer, er "MUST NOT treat messages from Signers in testing mode differently from unsigned email", was stärker ist als Fehler zu ignorieren: Die Signatur trägt überhaupt nichts bei, DKIM kann sich also nicht ausrichten, und eine Domain, die auf DKIM-Ausrichtung angewiesen ist, bekommt kein DKIM-Bestehen, solange das Flag gesetzt ist.
Test-Flags sollen am Ende einer Einführung verschwinden und verschwinden oft nicht. Wenn eine Domain einen perfekten 2048-Bit-Schlüssel veröffentlicht, jede Nachricht signiert und trotzdem DMARC-Fehlschläge sammelt, die sie sich nicht erklären kann, prüfen Sie dieses Tag vor allem anderen.
Das andere Flag im selben Tag ist leiser. t=s verbietet der signierenden Identität, eine Subdomain von d= zu sein, was eine bewusste Verschärfung und kein Fehler ist, und zugleich der Unterschied zwischen einem Signierer, der funktioniert, und einem, der an dem Tag aufhört, an dem jemand eine Subdomain auf denselben Schlüssel zeigen lässt.
Was an einem bereits veröffentlichten Schlüssel zu prüfen ist
Sechs Prüfungen, in der Reihenfolge, die Probleme am schnellsten findet.
- Dass sich der Schlüssel überhaupt parsen lässt. Nicht dass am Selektor ein Record existiert, sondern dass der Wert darin ein vollständiger Schlüssel ist. Diese Prüfung fängt eine abgeschnittene Aufrüstung ab.
- Dass die Stärke mindestens 1024 und besser 2048 beträgt. Unter 1024 darf ein Prüfer die Signatur nicht als gültig behandeln; zwischen 1024 und 2048 ist sie gültig und unter dem, was RFC 8301 empfiehlt.
- Dass
p=nicht leer ist, sofern Sie ihn nicht absichtlich widerrufen haben. - Kein
t=y. Ist die Einführung abgeschlossen, sollte das Test-Flag weg sein. - Dass jede Plattform, die als Sie sendet, einen eigenen aktiven Selektor hat. Ihr ESP, Ihr CRM, Ihr Helpdesk und Ihr Rechnungswerkzeug veröffentlichen je einen, und sie werden zu verschiedenen Zeiten von verschiedenen Leuten hinzugefügt.
- Dass der Selektor aus der Signatur auflöst. Ein Schlüssel unter einem Namen, den der Signierer nicht verwendet, ist unsichtbar.
Dass DKIM besteht, ist notwendig und nicht hinreichend, denn DMARC verlangt, dass die signierende Domain mit der Adresse in Ihrem From-Header übereinstimmt, und eine Nachricht kann von der eigenen Domain einer Plattform perfekt signiert sein und trotzdem scheitern. Unser Leitfaden zu DKIM-Signaturen behandelt das Record-Format, unser Leitfaden zur E-Mail-Authentifizierung behandelt, wie die drei Records voneinander abhängen, und dieselbe Art stillen Fehlers auf der SPF-Seite ist das Thema unseres Leitfadens zum SPF-Mechanismus include.
Um den Schlüssel zu sehen, den ein Empfänger wirklich liest, neben dem Signaturergebnis an einer echten Nachricht, machen Sie einen kostenlosen Spam-Test.
