DKIM - DomainKeys Identified Mail

Bei DomainKeys Identified Mail (DKIM) handelt es sich um ein Verfahren zur Absicherung von E-Mails. Dabei fügt der Absender-Server eine digitale Signatur in den E-Mail-Header ein. Mithilfe dieser Signatur kann der empfangende Server prüfen, ob die Nachricht während der Übertragung verändert wurde und tatsächlich von der angegebenen Domain stammt. Im Vergleich zu SPF, das lediglich überprüft, ob ein Server berechtigt ist, im Namen einer Domain E-Mails zu versenden, bietet DKIM einen höheren Schutz der Integrität, da auch der Inhalt der Nachricht geschützt wird. Während SPF recht einfach zu implementieren ist, aber bei Weiterleitungen an seine Grenzen stößt, kann DKIM auch komplexere Szenarien abdecken, ist in der Konfiguration jedoch fehleranfälliger.

DKIM basiert auf einem asymmetrisch-kryptografischen Verfahren: Bestimmte Bestandteile der E-Mail – typischerweise Felder aus dem Header wie From, Subject und Date sowie Teile des Nachrichtentextes – werden in Form von Hashwerten zusammengefasst und mit dem privaten Schlüssel der absendenden Domain signiert. Diese digitale Signatur wird anschließend als eigener Header in die E-Mail eingebettet. Der öffentliche Schlüssel zur Verifikation wird über das DNS der absendenden Domain bereitgestellt. Dadurch kann der empfangende Server später prüfen, ob die E-Mail unverändert übertragen wurde und ob sie tatsächlich von einem autorisierten System der absendenden Domain stammt.

Hinweis: Dieser Artikel richtet sich an Nutzer, die ihre Domain bei einem externen Anbieter registriert haben, aber einen E-Mail-Dienst wie z.B. Mailbox.org nutzen. Er behandelt die aus Sicht des Domaininhabers notwendigen Schritte zur Absicherung des E-Mail-Verkehrs – nicht die technische Implementierung auf Seiten des E-Mail-Providers.

DKIM für die eigene Domain einrichten

DKIM erfordert einen Eintrag im DNS der eigenen Domain. Über diesen können empfangende Mailserver den öffentlichen Schlüssel zur Verifikation der Signatur abrufen. Dafür ist ein administrativer Zugriff auf das Verwaltungsinterface des Domain-Providers erforderlich. Dieser Eintrag kann auf zwei Arten erfolgen: Entweder wird direkt ein TXT-Record angelegt, der den Schlüssel enthält, oder es wird indirekt ein CNAME-Record angelegt, der auf einen vom E-Mail-Provider bereitgestellten Schlüssel verweist. Beide Varianten erfüllen denselben Zweck, unterscheiden sich jedoch in Verwaltung und Flexibilität.

Der Name dieses Eintrags setzt sich stets aus einem vom E-Mail-Provider vergebenen Selector und der festen Subdomain _domainkey zusammen:

<selector>._domainkey.<meinedomain.de>

TXT-Record

Bei der Verwendung eines TXT-Records wird der öffentliche DKIM-Schlüssel direkt im DNS der eigenen Domain hinterlegt. Der Wert des TXT-Eintrags enthält den vom E-Mail-Provider bereitgestellten öffentlichen Schlüssel sowie Metainformationen, beispielsweise zur verwendeten Verschlüsselungsmethode. Diese Variante bietet volle Kontrolle über die veröffentlichten Schlüssel, erfordert jedoch auch, dass Schlüsselwechsel oder -aktualisierungen manuell im DNS vorgenommen werden.

Eine DNS-Abfrage auf einen FQDN des TXT-Records für mbo0001._domainkey.prontosystems.de liefert in der ANSWER SECTION beispielsweise folgende Ausgabe:

$ dig mbo0001._domainkey.prontosystems.de TXT
---snip---
;; ANSWER SECTION:
mbo0001._domainkey.prontosystems.de	300 IN	TXT	"v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u61" "LIQlOHS8f5sWsCK5b+HMOfo0M+aNHwfqlVdzi/IwmYnuDKuXYuCllrgnxZ4fG4yV"
---snap---

Da der öffentliche Schlüssel vom E-Mail-Provider bereitgestellt wird, müssen Sie bei einer Schlüsselrotation bzw. Änderung des Schlüssels Ihren Eintrag im DNS des Domain-Providers selbst ändern. Andernfalls schlägt die DKIM Verifikation Ihrer E-Mails fehl. Dieses Verfahren wird daher nur bedingt empfohlen und Sie sollten stattdessen einen CNAME-Record verwenden, falls ihr Domain-Provider das entsprechend unterstützt.

CNAME-Record

Statt den Schlüssel direkt zu hinterlegen, kann auch ein CNAME-Record verwendet werden, der auf eine vom E-Mail-Provider bereitgestellte Adresse verweist. Der CNAME-Record ist damit faktisch eine Weiterleitung auf den TXT-Record des E-Mail-Providers, welcher dann den öffentlichen Schlüssel enthält. Diese Methode reduziert den Verwaltungsaufwand für den Domaininhaber und ermöglicht dem E-Mail-Provider, Schlüssel zentral zu pflegen. Voraussetzung ist allerdings, dass der DNS-Anbieter CNAME-Einträge an dieser Stelle unterstützt.

Hinweis: Achten Sie bei der Angabe der Zieladresse auf den abschließenden Punkt. Er signalisiert dem DNS-System, dass es sich um einen vollständig qualifizierten Domainnamen (FQDN) handelt und verhindert, dass Ihre eigene Domain automatisch angehängt wird. Prüfen Sie in der Dokumentation Ihres Domain-Providers, ob der Punkt erforderlich oder eventuell automatisch ergänzt wird.

Eine DNS-Abfrage auf einen FQDN des CNAME-Records für mbo0001._domainkey.prontosystems.de liefert in der ANSWER SECTION beispielsweise folgende Ausgabe:

% dig mbo0001._domainkey.prontosystems.de CNAME
.
.
.
;; ANSWER SECTION:
mbo0001._domainkey.prontosystems.de. 3600 IN CNAME mbo0001._domainkey.mailbox.org.

Damit ist die Weiterleitung (CNAME) in Ihrem DNS veröffentlicht worden. Der empfangende Mailserver wird bei der Auflösung Ihrer DNS-Einträge eine weitere Abfrage bei der Zieladresse durchführen, um den oben bereits gezeigten öffentlichen Schlüssel zu erhalten.

Aufbau einer DKIM-signierten E-Mail

Um zu verstehen, wie DKIM in der Praxis funktioniert, lohnt sich ein Blick auf den technischen Aufbau einer signierten E-Mail. Besonders anschaulich wird dieser im E-Mail-Header, der für den Empfänger meist unsichtbar bleibt, aber zahlreiche Informationen über den Versandweg, Authentifizierungsmechanismen und Sicherheitsmerkmale enthält. Ein hilfreiches Werkzeug zur Analyse solcher E-Mails ist der Online-Dienst mail-tester.com. Er wertet nicht nur DKIM-Signaturen aus, sondern stellt auch eine detaillierte Header-Analyse bereit. Anhand eines Beispiels aus einem solchen Test lässt sich nachvollziehen, wie und wo DKIM in einer E-Mail zum Einsatz kommt.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prontosystems.de;
	s=MBO0001; t=1748553144;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=WHv4FsHowUhT1rqjOvfvPSJ7p+DL3MVjmPuldqkkXSM=;
	b=gQvgNNNBRLtnars9IFUXz9+oNEchTUeSp5X7GdLGIPTeYToMURmp7NVayQ6QmXRuUt8F4e
	c0ZcM6T18YL+9Mpgq0WzVULyZ7ur69eHBDlmJXvLPEAhaprphAtwjp2DIlQPxRCz9HXyl7
	5m7cM+sR0u6szjXm1v91fF82IbcOL5F/E1xPHOkhi2RPNYBIhvYXKnuPsujcdcowWL6j9O
	AzmSlv2uKSuRbChsvkSih+FURdjppkBVKJl0ZR99NarLZEoZ24cRgvgB+m4fxnu4hD/x7L
	rZ6bjdHMjZ2CgjXhgMh1CofBqY7i1K8frbJsZav2A/JSSqGv53mULTiOhHxbuw==

Erklärung der Parameter:

• v=1: Version des DKIM-Protokolls. Aktuell ist nur Version 1 definiert.
• a=rsa-sha256: Signaturalgorithmus → RSA mit SHA-256-Hash.
• c=relaxed/relaxed: Canonicalization → Gibt an, wie Header und Body vor dem Hashen normalisiert werden, um kleinere Formatabweichungen tolerieren zu können.
• d=prontosystems.de: Die Domain, die die E-Mail signiert hat. Diese muss im DNS einen passenden öffentlichen DKIM-Schlüssel bereitstellen.
• s=MBO0001: Der Selector. Zusammen mit der Domain ergibt sich der FQDN für den DNS-Eintrag (hier: MBO0001._domainkey.prontosystems.de).
• t=1748553144: Unix-Zeitstempel der Signaturerstellung. Er dient unter anderem dazu, die Signatur einer E-Mail zeitlich einzuordnen und hilft, Replay-Angriffe zu erkennen, bei denen gültige Signaturen alter Nachrichten erneut verwendet werden.
• h=[...]: Die Liste der Header-Felder, die in die Signatur einbezogen wurden. In diesem Beispiel sind es unter anderem From, Subject, Date, Message-ID, To, Content-Type usw. – also jene Felder, die für Authentizität und Integrität besonders relevant sind. Mehrfachnennungen (z. B. subject:subject) entstehen, wenn mehrere gleichnamige Header berücksichtigt wurden.
• bh=[...]: Der Hashwert des E-Mail-Bodys (also des eigentlichen Inhalts). Dieser wird gehasht, nicht signiert, und dann in die Gesamt-Signatur einbezogen.
• b=[...] Die eigentliche digitale Signatur über Header-Hash + Body-Hash, erstellt mit dem privaten Schlüssel der Domain. Empfänger prüfen diese mit dem öffentlichen Schlüssel im DNS.