Was ist DKIM, und wie beweist es, dass eine E-Mail nicht gefälscht wurde?

Von Thomas · virtueller CISO · 2026-06-15

Beim Empfang einer E-Mail garantiert nichts im ursprünglichen Protokoll, dass sie wirklich von dem stammt, der sie vorgibt zu sein, oder dass sie unterwegs nicht manipuliert wurde. DKIM schließt einen Teil dieser Lücke, indem es jeder Nachricht eine überprüfbare kryptografische Signatur anhängt. Der sendende Server signiert die Nachricht mit einem privaten Schlüssel; der Empfänger holt sich den öffentlichen Schlüssel aus dem DNS der signierenden Domain und prüft, dass sich nichts verändert hat. Dieser Leitfaden erklärt, was DKIM ist, wie die Signatur funktioniert, wie der Eintrag veröffentlicht wird, wie sich Selektoren und Rotation verwalten lassen – und warum DKIM allein ohne DMARC nicht ausreicht.

Was DKIM wirklich ist

DKIM (DomainKeys Identified Mail), definiert durch die RFC 6376, ist ein Authentifizierungsmechanismus, der zwei Dinge gleichzeitig beweist: dass die Nachricht tatsächlich von der signierenden Domain autorisiert wurde und dass sie zwischen Versand und Empfang nicht verändert wurde. Es beruht auf asymmetrischer Kryptografie, genau wie HTTPS: ein Schlüsselpaar, ein privater Schlüssel, der auf der Sendeinfrastruktur geheim bleibt, und ein öffentlicher, der offen im DNS veröffentlicht wird.

Beim Versand berechnet der sendende Server eine Signatur aus bestimmten Kopfzeilen der Nachricht (typischerweise From, Subject, Date…) und dem Nachrichtenrumpf, unter Verwendung des privaten Schlüssels. Diese Signatur reist mit der Nachricht mit, in einer eigenen Kopfzeile. Beim Empfang holt sich der empfangende Server den passenden öffentlichen Schlüssel aus dem DNS und berechnet die Signatur neu. Stimmt das Ergebnis überein, stehen zwei Gewissheiten fest: Die Nachricht stammt tatsächlich von einer Quelle, die den privaten Schlüssel besitzt, und sie ist integer – kein Byte des signierten Inhalts wurde unterwegs verändert.

Das ist ein fundamentaler Unterschied zu SPF, das sich damit begnügt, zu prüfen, welche IP die Nachricht verschickt hat. SPF schaut nicht auf den Inhalt; DKIM hingegen versiegelt die Nachricht. Beide ergänzen sich, und beide werden gebraucht.

Wie die Signatur funktioniert, Schritt für Schritt

Der Mechanismus hält sich in drei Schritten. Wer sie einmal vor Augen hat, dem wird alles Weitere glasklar.

1. Beim Versand – der Server signiert. Der sendende Server (oder die Plattform: Google Workspace, Microsoft 365, der Marketing-Router…) nimmt die Nachricht, wählt eine Liste zu schützender Kopfzeilen und den Rumpf aus und berechnet dann eine kryptografische Signatur mit dem privaten Schlüssel. Anschließend fügt er eine DKIM-Signature-Kopfzeile in die Nachricht ein. Diese Kopfzeile enthält drei entscheidende Informationen: die signierende Domain (d=), den Selektor (s=) und die Signatur selbst (b=), dazu die Liste der abgedeckten Kopfzeilen (h=).

2. Beim Empfang – der Server holt den öffentlichen Schlüssel. Der Empfänger liest die DKIM-Signature-Kopfzeile, findet dort d=beispiel.de und s=s1 und leitet daraus genau ab, wo er den öffentlichen Schlüssel suchen muss: unter der DNS-Adresse s1._domainkey.beispiel.de. Er stellt eine einfache DNS-Abfrage vom Typ TXT und holt sich den Schlüssel.

3. Überprüfung – der Empfänger rechnet nach. Mit dem öffentlichen Schlüssel berechnet der empfangende Server die Signatur über dieselben Kopfzeilen und denselben Rumpf neu. Stimmt sie überein, wird die Nachricht für die signierende Domain als integer und authentifiziert erklärt. Andernfalls scheitert DKIM: Entweder wurde die Nachricht verändert, oder der Schlüssel passt nicht, oder die Signatur fehlte.

Dieses ganze Ballett läuft automatisch und für den Menschen, der seine Post liest, unsichtbar ab. Es spielt sich in wenigen Millisekunden im Hintergrund ab, bei jeder einzelnen E-Mail.

Wie ein DKIM-Eintrag aussieht

Der öffentliche Schlüssel wird im DNS unter einem sehr präzisen Namen veröffentlicht: <selektor>._domainkey.beispiel.de. Hier ein konkretes Beispiel eines TXT-Eintrags:

s1._domainkey.beispiel.de.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Zerlegen wir die Tags, die zählen:

s= (der Selektor) – das ist kein Tag innerhalb des Eintrags, sondern das Präfix des DNS-Namens. Der Selektor erlaubt es, mehrere Schlüssel parallel zu veröffentlichen: einen pro Sendedienstleister oder einen alten und einen neuen während einer Rotation. Er ist der Dreh- und Angelpunkt der gesamten DKIM-Verwaltung. Wir gehen ihm im Detail in die Rolle des DKIM-Selektors auf den Grund.
p= (der öffentliche Schlüssel) – der öffentliche Schlüssel, base64-kodiert. Er ist das Herzstück des Eintrags. Entscheidendes Detail: p= zu löschen oder seinen Wert zu leeren widerruft den Selektor – die Empfänger betrachten den Schlüssel dann als zurückgezogen. Das ist der saubere Mechanismus, um einen kompromittierten Schlüssel zu deaktivieren.
k= (der Algorithmus) – der Schlüsselalgorithmus, wobei rsa bei Weitem der gängigste ist. Manche moderne Infrastrukturen akzeptieren auch ed25519, kompakter, oft als zweiter Selektor neben dem RSA veröffentlicht.
v=DKIM1 – die Version, am Anfang jedes Eintrags vorhanden.

Ein Punkt, der Einsteiger in die Falle lockt: Der öffentliche Schlüssel ist oft zu lang, um in eine einzige DNS-Zeichenkette von 255 Zeichen zu passen. Er wird dann in mehrere Zeichenketten in Anführungszeichen zerlegt, die der Resolver wieder zusammensetzt. Das ist kein Fehler, sondern die normale Funktionsweise.

Selektoren und Rotation: das wahre DKIM-Handwerk

Hier geht DKIM von „es funktioniert" zu „es funktioniert sauber und dauerhaft" über. Der Selektor ist der Schlussstein für zwei wiederkehrende Bedürfnisse.

Ein eigener Selektor pro Sendequelle. Wer über Google Workspace und über eine Marketing-Plattform und über einen eigenen Transaktionsserver versendet, gibt jedem seinen eigenen Selektor mit seinem eigenen Schlüsselpaar. Der Vorteil ist enorm: Sobald ein Dienstleister kompromittiert oder abgelöst wird, fällt nur sein Selektor (indem sein p= entfernt wird), ohne die anderen anzutasten. Die übrigen Sendeströme signieren und passieren weiter ohne Unterbrechung.

Die regelmäßige Rotation. Ein DKIM-Schlüssel ist nicht ewig: Je länger er lebt, desto größer das Risiko, dass er durchsickert. Gute Praxis ist, ihn periodisch zu rotieren, und der Selektor macht die Operation schmerzlos:

Ein neues Schlüsselpaar generieren und den neuen öffentlichen Schlüssel veröffentlichen unter einem neuen Selektor (z. B. s2), während der alte (s1) bestehen bleibt.
Den Sendeserver umstellen, damit er mit dem neuen Schlüssel (s2) signiert.
Warten, bis die gesamte mit dem alten Schlüssel signierte Post zugestellt ist (ein paar Tage Puffer).
Den alten Selektor entfernen (s1) aus dem DNS.

Keine Unterbrechung, keine abgelehnte Nachricht während der Umstellung. Wir gehen die vollständige Prozedur, mit den Fallstricken, in wie man einen DKIM-Schlüssel rotiert, ohne seine Zustellbarkeit zu ruinieren durch. Und für den Start bei null liefert unser Leitfaden ein DKIM-Schlüsselpaar generieren die exakten Befehle.

Schlüssellänge: 1024 vs. 2048 Bit

Die Länge des RSA-Schlüssels bestimmt seine Widerstandsfähigkeit. Zwei Größen kursieren heute:

1024 Bit – historisch der Standard-Default, von den Empfängern noch akzeptiert, aber inzwischen als schwach eingestuft. Ein 1024-Bit-Schlüssel bleibt für einen motivierten Angreifer mit Ressourcen knackbar, und immer mehr Anbieter stufen ihn herab.
2048 Bit – die zu bevorzugende Wahl. Das ist der heute empfohlene Standard, mit einer komfortablen Sicherheitsmarge für die kommenden Jahre. So gut wie alle DNS- und Sendeplattformen unterstützen ihn mühelos.

Die einzige historische Einschränkung von 2048 Bit war die Länge des DNS-Eintrags (daher die weiter oben erwähnte Zerlegung in Zeichenketten), aber das ist kein echtes Hindernis mehr. Für jeden neuen Schlüssel sind immer 2048 Bit zu generieren. Wer noch mit 1024 unterwegs ist, nutzt die nächste Rotation, um auf 2048 aufzustocken – genau die Art Umstellung, die Selektoren einfach machen. Wir vergleichen die beiden im Detail in DKIM 1024 vs. 2048 Bit: welchen wählen.

Signierter Rumpf, signierte Kopfzeilen: was DKIM wirklich schützt

Eine nützliche Feinheit: DKIM signiert nicht die gesamte Nachricht blind. Es signiert den Rumpf und eine ausgewählte Liste von Kopfzeilen (deklariert im h=-Tag der Signatur). Nicht gelistete Kopfzeilen können sich ändern, ohne die Signatur zu brechen – was gewollt ist, denn manche technischen Kopfzeilen werden von zwischengeschalteten Servern legitim umgeschrieben.

Diese Unterscheidung erklärt ein häufiges Phänomen: Eine E-Mail kann unterwegs verändert werden (ein Gateway, das ein „extern"-Banner hinzufügt, eine Mailingliste, die eine Fußzeile anhängt) und ihre DKIM-Signatur brechen sehen, weil der signierte Rumpf nicht mehr identisch ist. Das ist nicht zwingend ein Angriff – manchmal ist es ein etwas zu übereifriger Zwischenserver. Genau um diese Fälle zu unterscheiden, kreuzt man DKIM mit den anderen Signalen. Wer eine echte Signatur inspizieren will, findet in wie man eine DKIM-Signatur überprüft die Anleitung, jedes Tag von Hand zu lesen.

DKIM gegenüber Weiterleitung: da glänzt es

Hier ist der entscheidende Vorteil von DKIM gegenüber SPF. Wenn eine E-Mail weitergeleitet wird (Forwarding) – etwa von einer .de-Adresse an ein privates @gmail.com – ändert sich die Versand-IP: Nun ist es der weiterleitende Server, der die Nachricht auslieferst. Ergebnis: SPF bricht, denn die IP der Weiterleitung steht nicht im SPF-Eintrag der Domain.

DKIM hingegen überlebt die Weiterleitung deutlich besser. Die Signatur reist mit der Nachricht; solange der signierte Rumpf und die signierten Kopfzeilen nicht verändert werden, bleibt die Signatur auch nach mehreren Sprüngen gültig. Deshalb ist DKIM oft der einzige Mechanismus, der bei weitergeleiteter Post „hält", und deshalb ist es unerlässlich, ihn korrekt bereitzustellen. Eine Domain, die sich nur auf SPF stützt, wird einen Teil ihrer legitimen Post an der Authentifizierung scheitern sehen, sobald sie über eine Weiterleitung läuft.

Warum DKIM nicht ausreicht: DMARC muss obendrauf

Hier ist der Punkt, den man nie vergessen darf. DKIM beweist, dass eine Nachricht integer und von einer Domain signiert ist. Aber es prüft nicht, dass diese Domain der entspricht, die der Nutzer im Feld From: sieht. Ein Angreifer kann seine Post ohne Weiteres mit DKIM für seine eigene Domain (boesewicht.com) signieren, die DKIM-Kontrolle problemlos passieren und dennoch eine fremde Domain im From: anzeigen. DKIM allein sieht die Lüge nicht.

Das fehlende Glied heißt Ausrichtung (Alignment), und das ist die Aufgabe von DMARC. DMARC verlangt, dass die von DKIM authentifizierte Domain (das d=) mit der Domain des sichtbaren From: übereinstimmt. Diese Regel verwandelt DKIM von einem bloßen Integritätsbeweis in einen echten Schutz gegen die Usurpation der Identität. Ohne DMARC ist DKIM ein Schloss an einer Tür, die der Angreifer einfach umgeht, indem er durch das Fenster nebenan steigt.

Deshalb bilden DKIM, SPF und DMARC ein Ganzes. DKIM und SPF liefern die Beweise; DMARC verknüpft sie mit der sichtbaren Domain und sagt den Empfängern, was im Fehlerfall zu tun ist. Für den Gesamtüberblick ist was ist DMARC der Einstieg – das ist der Standard, der einer DKIM-Signatur endlich Sinn verleiht.

Die Marschordnung

DKIM ist nicht kompliziert, aber jedes Detail zählt: der richtige Selektor, ein 2048-Bit-Schlüssel, eine saubere Rotation und vor allem DMARC obendrauf, um alles mit der sichtbaren Domain zu verknüpfen. Hier die Marschordnung, die ich empfehle:

Einen 2048-Bit-Schlüssel generieren und ihn unter einem klaren Selektor veröffentlichen (einer pro Sendequelle).
Prüfen, dass jede Sendeplattform auch tatsächlich mit DKIM signiert – Google und Microsoft aktivieren es mit wenigen Klicks, aber Drittanbieter-Tools vergessen es oft.
Eine regelmäßige Rotation planen über einen zweiten Selektor, ohne je den Strom zu unterbrechen.
Das Ganze mit DMARC krönen, um die Ausrichtung zu verlangen und der Usurpation die Tür zu verschließen.

Raten ist dabei die schlechteste Methode. Eine kostenlose und sofortige Überprüfung der SPF-, DKIM- und DMARC-Konfiguration läuft über unseren kostenlosen DMARC-Analyzer – er zeigt die erkannten Selektoren, die Größe der Schlüssel und eine klare Note. Thomas, der virtuelle CISO, nennt anschließend genau, was zu korrigieren ist und in welcher Reihenfolge.

Eine Domain kostenlos analysieren oder ein Konto erstellen und Thomas sich um den Rest kümmern lassen.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos