DKIM steht für „DomainKeys Identified Mail“ und ist ein Verfahren, mit dem eine Domain die Verantwortung für eine E-Mail übernimmt, indem sie die Nachricht kryptografisch signiert. Maßgeblich ist RFC 6376 vom September 2011, den RFC 8301 im Januar 2018 um aktuelle Vorgaben zu Algorithmen und Schlüssellängen ergänzt hat. Der versendende Server erzeugt die Signatur mit einem privaten Schlüssel, während der zugehörige öffentliche Schlüssel im DNS der Domain für jeden Empfänger abrufbar bereitsteht.
Gespeichert wird die Signatur im Kopfbereich der Nachricht im Feld „DKIM-Signature“, sodass sie im E-Mail-Programm neben dem eigentlichen Text unsichtbar bleibt. Nach der Beschreibung von Google ruft der empfangende Server den öffentlichen Schlüssel aus dem DKIM-Eintrag ab und prüft damit, ob die Nachricht tatsächlich vom Inhaber der Domain stammt. Gemeinsam mit SPF und DMARC stärkt das Verfahren nach Einschätzung des BSI den Schutz vor Angriffen, bei denen Täter die Identität einer vertrauenswürdigen Absenderdomain vortäuschen, etwa beim Phishing.
Wie eine DKIM-Signatur entsteht und geprüft wird
Vor dem Versand berechnet der Server einen Prüfwert über den Text der Nachricht und über ausgewählte Kopfzeilen, deren Namen er im Tag h= der Signatur auflistet. Die Kopfzeile „From“ mit der sichtbaren Absenderadresse muss nach RFC 6376 stets zu den signierten Feldern gehören, während Felder, die beim Transport berechtigterweise verändert werden, ausgespart bleiben sollen. Im Tag d= steht die signierende Domain und im Tag s= der Selektor, aus denen der Empfänger die Adresse des Schlüssels im DNS bildet. Bei der Domain example.com und dem Selektor „foo.bar“ fragt der Prüfer nach dem Beispiel aus RFC 6376 den Eintrag foo.bar._domainkey.example.com ab.
Eine gültige Signatur bestätigt nach RFC 6376 lediglich, dass sich der signierte Inhalt seit dem Signieren nicht verändert hat, und sagt nichts darüber aus, ob der Inhalt zutrifft. Für die Aufbereitung vor der Berechnung sieht der Standard die Verfahren „simple“ und „relaxed“ vor, wobei „relaxed“ geringfügige Änderungen an Leerzeichen und Zeilenumbrüchen während des Transports toleriert. Zwischenstationen der Zustellung verändern den Inhalt nach RFC 6376 in der Regel nicht wesentlich, sodass die Signatur dabei erhalten bleibt. Fügt dagegen ein Filter beim Empfänger einen Hinweis wie „[EXTERNAL]“ in den Betreff ein, wird die Signatur nach Darstellung der TR-03182 des BSI ungültig.
DKIM-Schlüssel: Längen und Algorithmen
Seit RFC 8301 aus dem Jahr 2018 ist das Verfahren rsa-sha1 weder zum Signieren noch zum Prüfen zulässig, sodass Signaturen mit rsa-sha256 entstehen. Die RSA-Schlüssel müssen mindestens 1024 Bit lang sein und sollen nach dem Standard 2048 Bit erreichen, während Prüfprogramme Schlüssel von 1024 bis 4096 Bit verarbeiten können müssen. Google setzt für den Versand an private Gmail-Konten ebenfalls mindestens 1024 Bit voraus und empfiehlt 2048 Bit, sofern der Domainanbieter Einträge dieser Länge unterstützt. In Microsoft 365 lässt sich die Schlüssellänge zwischen 1024 und 2048 Bit wählen, wobei laut Dokumentation 1024 Bit voreingestellt ist.
Die TR-03182 geht darüber hinaus und verlangt neben rsa-sha256 eine zweite Signatur mit Ed25519-SHA256, einem Verfahren, das RFC 8463 im Jahr 2018 eingeführt hat. Als Gründe nennt die Richtlinie die höhere kryptografische Sicherheit und einen öffentlichen Schlüssel von höchstens 256 Zeichen, der in einen einzelnen TXT-Eintrag passt. RSA-Schlüssel sollen nach der TR aus Gründen der Kompatibilität zwischen 1024 und 2048 Bit liegen. Da Google bei längeren Schlüsseln auf Zeichenbeschränkungen mancher Domainanbieter für TXT-Einträge hinweist, klären Sie die unterstützte Länge am besten vorab mit Ihrem Anbieter.
Selektoren und Schlüsselwechsel
Über Selektoren kann eine Domain nach RFC 6376 mehrere öffentliche Schlüssel gleichzeitig bereithalten, die sich etwa nach Standort, Zeitraum oder Nutzer unterscheiden lassen. Als Anwendungsfall nennt der Standard unter anderem Domains, die einem Partner wie einem Werbedienstleister für eine bestimmte Zeit das Signieren gestatten möchten. Microsoft 365 legt für jede eigene Domain zwei Selektoren an, von denen jeweils einer aktiv ist, und verweist im DNS über CNAME-Einträge auf die öffentlichen Schlüssel, die Microsoft selbst verwaltet.
Für den Austausch der Schlüssel, die sogenannte Schlüsselrotation, verlangt die TR-03182 eine Erneuerung spätestens alle sechs Monate oder eine dokumentierte Begründung. In ihren Erläuterungen rät die Richtlinie zu einem Wechsel alle drei Monate. Jeder neue Schlüssel erhält dabei am besten einen eigenen Selektor, weil DNS-Resolver unter einem bereits bekannten Namen bis zum Ablauf der Gültigkeitsdauer den alten Schlüssel aus ihrem Zwischenspeicher liefern. Bei Microsoft 365 beginnt das Signieren mit dem neuen Schlüssel vier Tage nach dem Auslösen der Rotation, und Google nennt bis zu 48 Stunden, bis ein neu eingetragener Schlüssel wirkt. Schlüssel, die nicht mehr im Einsatz sind, sollen nach der TR aus dem DNS entfernt werden.
Fehlerquellen und das Zusammenspiel mit DMARC
Ein DKIM-Eintrag beginnt nach den Angaben von Google und des BSI mit v=DKIM1, und die einzelnen Angaben werden durch Semikolons voneinander getrennt. In der Empfehlung „Upgrade für die E-Mail-Sicherheit“ (BSI-CS 155) nennt das BSI fehlende Trennzeichen, Anführungszeichen um den gesamten Eintrag und abweichende Versionsangaben wie „DKIMv=1“ als Fehler, die Empfänger je nach Fehlertoleranz übergehen oder falsch auslegen. Die TR-03182 verlangt außerdem, dass sämtliche Nachrichten einer Domain signiert werden, ausdrücklich auch solche, die ein Kontaktformular auf der Webseite erzeugt.
Die signierende Domain muss nach Angaben von Microsoft nicht mit der sichtbaren Absenderadresse übereinstimmen. Viele gehostete Dienste signieren laut Microsoft zunächst mit ihrer eigenen Domain und nach der Einrichtung zusätzlich mit der Domain des Kunden. Diese Übereinstimmung fordert erst DMARC, denn laut Google muss die authentifizierende Domain zur Domain im Feld „From“ passen, damit eine Nachricht die DMARC-Prüfung besteht. Seit dem 1. Februar 2024 verlangt Google von allen Absendern an Gmail-Konten SPF oder DKIM und von Absendern mit mehr als 5.000 Nachrichten am Tag beide Verfahren samt DMARC. Das Aktivieren beim Postfachanbieter, das Eintragen des Schlüssels und die Kontrolle über „Original anzeigen“ in Gmail beschreibt der Ratgeber SPF, DKIM und DMARC einrichten.