DKIM (DomainKeys Identified Mail) ist eine digitale Signatur, die die Absenderdomain jeder E-Mail hinzufügt. Der empfangende Server kann damit prüfen, dass die Nachricht tatsächlich von dieser Domain stammt und unterwegs nicht verändert wurde. Das erschwert Spoofing (Identitätsfälschung) und beeinflusst die Zustellbarkeit. Die IETF hat DKIM 2007 standardisiert (RFC 4871) und 2011 überarbeitet (RFC 6376).
Was prüft ein Server genau, wenn er dkim=pass in den Header einer Nachricht schreibt? Er stellt fest, dass eine Signatur der Absenderdomain zu einem öffentlichen Schlüssel passt, der im DNS dieser Domain veröffentlicht ist. Außerdem hat sich der Nachrichtentext unterwegs nicht geändert. Mehr nicht. Ein Dashboard Ihres Mailingtools, das „DKIM OK“ anzeigt, sagt deshalb nichts über die Qualität der Empfängerliste oder die Reputation der IP-Adresse.
Seit dem 1. Februar 2024 verlangt Google von Absendern, die mehr als 5.000 Nachrichten pro Tag an Gmail schicken, SPF, DKIM und DMARC. Dieser Leitfaden liest eine Signatur Feld für Feld, zeigt den zu veröffentlichenden DNS-Eintrag und erklärt dann den Test und die häufigsten Fehlerursachen.
Der DKIM-Signature-Header, Feld für Feld
Öffnen Sie das Original einer empfangenen E-Mail. Der Header sieht so aus (Beispielwerte, Signatur gekürzt, Zeitstempel vom 9. Oktober 2025).
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beispiel.de; s=s1; t=1760000000; h=from:to:subject:date:message-id; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Zm9ybWF0IGQnaWxsdXN0cmF0aW9u...
Jedes Tag folgt einer Definition der RFC 6376, die die IETF im September 2011 veröffentlicht hat.
| Tag | Beispielwert | Bedeutung |
|---|---|---|
| v | 1 | Version der DKIM-Spezifikation |
| a | rsa-sha256 | Signaturalgorithmus: RSA mit SHA-256-Hash |
| c | relaxed/relaxed | Kanonisierung von Header und Body (Toleranz gegenüber Leerzeichen und Zeilenumbrüchen) |
| d | beispiel.de | Signierende Domain, für das DMARC-Alignment mit der Domain im From verglichen |
| s | s1 | Selektor, der den im DNS abzurufenden Schlüssel bezeichnet |
| t | 1760000000 | Unix-Zeitstempel der Signatur (9. Oktober 2025, 08:53 UTC) |
| h | from:to:subject:date:message-id | Liste der Header, die die Signatur abdeckt |
| bh | 47DEQpj8… | Hash des Nachrichtentexts (Body-Hash) |
| b | Zm9ybWF0… | Signatur, berechnet über die in h aufgelisteten Header |
Zwei Tags werden oft verwechselt. bh enthält den Hash des Bodys, b die Signatur selbst, berechnet über die Header aus h und über den DKIM-Signature-Header (mit leerem b). Ein SHA-256-Hash umfasst 32 Bytes, in Base64 sind das 44 Zeichen in bh. Ein um ein einziges Byte veränderter Body macht bh ungültig, ein verändertes signiertes Header-Feld macht b ungültig. Der Algorithmus rsa-sha1 ist seit der RFC 8301 (Januar 2018) verboten: Eine moderne Signatur zeigt rsa-sha256. Das optionale Tag l begrenzt den signierten Teil auf eine Anzahl Bytes des Bodys und erlaubt damit, nach dem abgedeckten Teil Inhalt anzuhängen. Die RFC 6376 beschreibt diesen Missbrauch in Abschnitt 8.2.
Von der Signatur zur Prüfung: wer macht was
Die gängige Formulierung („den Hash mit dem privaten Schlüssel verschlüsseln“) verwischt die Rollen. In der Praxis läuft es in vier Schritten ab.
- Der sendende Server (MTA) kanonisiert den Body, berechnet den SHA-256-Hash und trägt ihn in bh ein.
- Er berechnet den Hash der in h gelisteten Header sowie des DKIM-Signature-Headers selbst und signiert das Ergebnis mit seinem privaten Schlüssel. Diese Signatur wird zu b. Der private Schlüssel verlässt den sendenden Server nie.
- Der empfangende Server liest d und s, fragt das DNS nach s._domainkey.d ab und erhält den öffentlichen Schlüssel. Der Absender ist an dieser Stelle nicht mehr beteiligt.
- Der Empfänger berechnet den Body-Hash neu, vergleicht ihn mit bh und prüft dann b mit dem öffentlichen Schlüssel. Stimmen beide Prüfungen überein, lautet das Ergebnis dkim=pass.
Selektor und TXT-Eintrag: wo der Schlüssel veröffentlicht wird
Der Selektor, der Wert des Tags s, bildet den DNS-Namen, den der Empfänger abfragt: s._domainkey.d. Für s=s1 und d=beispiel.de lautet die Abfrage s1._domainkey.beispiel.de, wo ein TXT-Eintrag erwartet wird.
s1._domainkey.beispiel.de. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
Das Tag v nennt die Version, k den Schlüsseltyp, p den öffentlichen Schlüssel in Base64. Ein leeres p kennzeichnet einen widerrufenen Schlüssel. Der Anfang des Werts verrät die Länge: MIIBIjANBgkq… steht für einen RSA-Schlüssel mit 2048 Bit, MIGfMA0GCSqG… für einen mit 1024 Bit.
Die RFC 8301 verlangt von Signierenden RSA-Schlüssel mit mindestens 1024 Bit und empfiehlt 2048 Bit. Ein 1024-Bit-Schlüssel umfasst rund 216 Zeichen. Ein 2048-Bit-Schlüssel hat in Base64 392 Zeichen und überschreitet damit die 255 Zeichen eines DNS-Strings. Der Eintrag muss daher in mehrere Strings in Anführungszeichen aufgeteilt werden, was manche DNS-Oberflächen automatisch erledigen und andere nicht. Jedes Versandtool (Google Workspace, ein CRM, ein ESP) erhält unter derselben Domain seinen eigenen Selektor. Deshalb enthält eine Zone oft mehrere solcher Einträge.
Eine letzte Falle: Je nach Oberfläche erwartet das Feld „Hostname“ nur s1._domainkey oder den vollständigen Namen. Wer den vollständigen Namen eingibt, obwohl die Domain automatisch angehängt wird, erzeugt s1._domainkey.beispiel.de.beispiel.de, und den findet der Empfänger nicht. Der Eintrag liegt in derselben Zone wie die übrigen DNS-Einträge des Absenders (SPF, MX, DMARC): eine Oberfläche, ein Zonenverantwortlicher.
DKIM bei Google Workspace, Microsoft 365 oder einem ESP einrichten
Bei Google Workspace führt der Weg über die Admin-Konsole: Apps > Google Workspace > Gmail > E-Mails authentifizieren. Die Schaltfläche „Neuen Eintrag generieren“ erstellt das Schlüsselpaar. Sie kopieren den TXT-Wert in die DNS-Zone und starten dann die Authentifizierung. Laut der Hilfe von Google Workspace erscheint der Schlüssel nach der Aktivierung von Gmail erst nach 24 bis 72 Stunden in der Konsole.
Microsoft 365 (in älteren Dokumentationen Office 365) geht anders vor. Das Microsoft-Defender-Portal (security.microsoft.com) liefert im Bereich „Email authentication settings“ zwei Selektoren namens selector1 und selector2. Sie werden als CNAME auf Einträge veröffentlicht, die Microsoft hostet, nach dem Muster selector1-beispiel-de._domainkey.mandant.onmicrosoft.com. Es signiert immer nur einer der beiden Selektoren, der andere wartet auf die nächste Rotation, sodass der Wechsel ohne Unterbrechung gelingt.
Bei einem ESP liefert die Plattform die TXT- oder CNAME-Einträge zum Kopieren. Solange die DNS-Zone sie nicht enthält, signiert der ESP mit seiner eigenen Domain: Der Test zeigt dkim=pass, die Domain d stimmt aber nicht mit dem From überein, sodass die Signatur für DMARC nicht zählt. Dasselbe passiert bei einem ausgehenden Gateway, das einen Footer anhängt: Der Body ändert sich nach der Signatur, ein Fall, den die Dokumentation von Google Workspace ausdrücklich nennt.
DKIM testen: Authentication-Results lesen
Senden Sie eine Testnachricht an ein Gmail-Postfach, öffnen Sie das Drei-Punkte-Menü der Nachricht und wählen Sie Original anzeigen. Gmail zeigt dort „DKIM: PASS“ mit der Domain an und führt das Ergebnis im Header Authentication-Results im Detail auf.
Authentication-Results: mx.google.com; dkim=pass header.i=@beispiel.de header.s=s1 header.b=Zm9ybWF0; spf=pass smtp.mailfrom=beispiel.de; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=beispiel.de
In der dkim-Zeile nennt header.s den verwendeten Selektor, header.i die signierende Identität und header.b die ersten Zeichen der Signatur. Das Format stammt aus der RFC 8601 von 2019. Mögliche Ergebnisse: pass, fail (ungültige Signatur), none (keine Signatur), neutral, temperror und permerror (vorübergehender oder dauerhafter DNS-Fehler).
Um ein DNS-Problem vor dem Versand einzugrenzen, liefert der Befehl dig +short TXT s1._domainkey.beispiel.de den veröffentlichten Wert. Ein Online-DKIM-Test (DKIM-Lookup, DKIM-Checker) stellt dieselbe Abfrage mit dem s-Wert aus dem Header.
Warum eine DKIM-Signatur fehlschlägt
Ein dkim=fail geht fast immer auf einen dieser Fälle zurück.
- Der Body wurde nach der Signatur verändert, etwa durch einen Footer, den ein Relay anhängt. bh stimmt dann nicht mehr.
- Der Selektor wird nicht gefunden: Tippfehler oder ein um die Domain verdoppelter Hostname.
- Der öffentliche Schlüssel ist abgeschnitten: ein 2048-Bit-TXT-Eintrag ohne Aufteilung.
- Der private Schlüssel wurde beim Anbieter neu erzeugt, ohne das DNS zu aktualisieren.
- Die Nachricht läuft über eine Mailingliste oder Weiterleitung, die den Betreff umschreibt oder einen Footer ergänzt: Die ursprüngliche Signatur deckt den empfangenen Inhalt nicht mehr ab.
- Die Signatur besteht, aber die Domain d weicht von der Domain im From ab: DMARC verwirft sie wegen fehlendem Alignment.
DMARC-Alignment und die Anforderungen von Gmail und Yahoo
Yahoo wendet seine Anforderungen seit Februar 2024 an: Laut Sender Hub muss die From-Domain mit der SPF-Domain oder der DKIM-Domain übereinstimmen (Best Practices von Yahoo). Im Modus relaxed, dem Standard, passt d=news.beispiel.de zu einem From auf beispiel.de. Der Modus strict (adkim=s) verlangt die exakt gleiche Identität, so die RFC 7489 von 2015. Eine Nachricht, die ein ESP mit d=mailer.esp-beispiel.com und einem From auf @beispiel.de versendet, besteht den DKIM-Alignment-Test daher nicht. Gehört der Return-Path ebenfalls dem ESP, scheitert auch SPF. Bei einer DMARC-Richtlinie mit p=reject wird eine Nachricht abgewiesen, wenn weder SPF noch DKIM im Alignment sind.
Die Schwellenwerte hängen vom Volumen ab. Für jeden Absender an Gmail verlangt Google seit dem 1. Februar 2024 SPF oder DKIM, ab 5.000 Nachrichten pro Tag beides. Google verlangt außerdem einen veröffentlichten DMARC-Eintrag (p=none genügt), gültige Forward- und Reverse-DNS-Einträge sowie eine TLS-Verbindung. Das Nachrichtenformat folgt der RFC 5322 von 2008. Bei der Reputation peilt die Seite eine Spamrate unter 0,10 % in den Postmaster Tools an und nennt 0,30 % als Grenze, die nie erreicht werden darf. Yahoo verlangt SPF und DKIM gemeinsam, DMARC mindestens in p=none und dieselbe Obergrenze von 0,3 %. SPF allein reicht bei hohem Volumen also nicht mehr (SPF erklärt).
Schlüsselrotation
Ein Schlüssel lässt sich ohne Unterbrechung nur mit zwei Selektoren austauschen, zum Beispiel s1 und danach s2. Sie veröffentlichen den neuen Schlüssel unter s2, während s1 noch signiert, stellen die Signatur auf s2 um und lassen s1 im DNS stehen, bis die Nachrichten in der Warteschlange geprüft sind. Wer s1 zu früh entfernt, verursacht dkim=fail bei legitimen Sendungen, die man dann fälschlich für einen DNS-Ausfall hält.
Was DKIM nicht prüft
Ein Spammer kann seine Mails mit der eigenen Domain signieren und dkim=pass erhalten: Die Signatur belegt die Herkunft der Nachricht, sie bewertet weder den Inhalt noch die Qualität der Liste. Eine einwandfrei signierende Domain, die an tote Adressen schreibt, sammelt Hard Bounces. Ihre Absenderreputation leidet trotzdem.
Schicken Sie vor der nächsten Kampagne eine Stichprobe der Liste durch eine E-Mail-Adressprüfung: Das Ergebnis zeigt, wie viele ungültige Adressen der Bestand enthält, bevor sie in den Postmaster Tools auftauchen.
