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

Wenn du eine E-Mail empfängst, garantiert dir 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 deinem DNS und prüft, dass sich nichts verändert hat. Dieser Leitfaden erklärt dir, was DKIM ist, wie die Signatur funktioniert, wie du deinen Eintrag veröffentlichst, wie du Selektoren und Rotation verwaltest – 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, den du auf deiner Sendeinfrastruktur geheim hältst, und ein öffentlicher, den du offen im DNS veröffentlichst.

Beim Versand berechnet dein 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 deinem DNS und berechnet die Signatur neu. Stimmt das Ergebnis überein, hast du zwei Gewissheiten: Die Nachricht stammt tatsächlich von einer Quelle, die deinen 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 du brauchst beide.

Wie die Signatur funktioniert, Schritt für Schritt

Der Mechanismus hält sich in drei Schritten. Sobald du ihn dir vorstellst, wird alles Weitere glasklar.

1. Beim Versand – der Server signiert. Dein sendender Server (oder deine Plattform: Google Workspace, Microsoft 365, dein 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=deine-domain.de und s=s1 und leitet daraus genau ab, wo er den öffentlichen Schlüssel suchen muss: unter der DNS-Adresse s1._domainkey.deine-domain.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 dein DKIM-Eintrag aussieht

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

s1._domainkey.deine-domain.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 dir, 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 dein Schlussstein für zwei wiederkehrende Bedürfnisse.

Ein eigener Selektor pro Sendequelle. Wenn du über Google Workspace und über eine Marketing-Plattform und über deinen eigenen Transaktionsserver versendest, gib jedem seinen eigenen Selektor mit seinem eigenen Schlüsselpaar. Der Vorteil ist enorm: Sobald ein Dienstleister kompromittiert wird oder du ihn verlässt, widerrufst du nur seinen Selektor (indem du sein p= entfernst), ohne die anderen anzutasten. Deine ü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:

1. Generiere ein neues Schlüsselpaar und veröffentliche den neuen öffentlichen Schlüssel unter einem neuen Selektor (z. B. s2), während du den alten (s1) bestehen lässt.
2. Stelle deinen Sendeserver um, damit er mit dem neuen Schlüssel (s2) signiert.
3. Warte, bis die gesamte mit dem alten Schlüssel signierte Post zugestellt ist (ein paar Tage Puffer).
4. Entferne den alten Selektor (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 wenn du bei null anfängst, gibt dir 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. Generiere immer 2048 Bit für jeden neuen Schlüssel. Wenn du noch mit 1024 unterwegs bist, nutze deine 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. Wenn du eine echte Signatur inspizieren willst, zeigt dir wie man eine DKIM-Signatur überprüft, wie du jedes Tag von Hand liest.

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 in deinem SPF-Eintrag.

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 deine 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 deiner 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 deiner sichtbaren Domain und sagt den Empfängern, was im Fehlerfall zu tun ist. Für den Gesamtüberblick beginne mit was ist DMARC – das ist der Standard, der deiner DKIM-Signatur endlich Sinn verleiht.

Werde aktiv

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 deiner sichtbaren Domain zu verknüpfen. Hier die Marschordnung, die ich empfehle:

• Generiere einen 2048-Bit-Schlüssel und veröffentliche ihn unter einem klaren Selektor (einer pro Sendequelle).
• Prüfe, dass jede deiner Sendeplattformen auch tatsächlich mit DKIM signiert – Google und Microsoft aktivieren es mit wenigen Klicks, aber Drittanbieter-Tools vergessen es oft.
• Plane eine regelmäßige Rotation über einen zweiten Selektor, ohne je den Strom zu unterbrechen.
• Krönt das Ganze mit DMARC, um die Ausrichtung zu verlangen und der Usurpation die Tür zu verschließen.

Keine Lust zu raten, wo du stehst? Starte eine kostenlose und sofortige Überprüfung deiner SPF-, DKIM- und DMARC-Konfiguration mit unserem kostenlosen DMARC-Analyzer – er zeigt dir deine erkannten Selektoren, die Größe deiner Schlüssel und eine klare Note. Dann lass Thomas, deinen virtuellen CISO, dir genau sagen, was zu korrigieren ist und in welcher Reihenfolge.

Analysiere deine Domain kostenlos → oder erstelle ein Konto und lass Thomas sich um den Rest kümmern.