DKIM Configuration

Was ist DKIM (DomainKeys Identified Mail) und wie schützt es Ihre E-Mails?

4. April 2026 • Von DMARCFlow Team • 9 Min. Lesezeit

Wenn eine E-Mail in Ihrem Posteingang ankommt, die vorgibt, von Ihrer Bank, Ihrem Softwarelieferanten oder Ihrem CEO zu stammen – wie weiß der empfangende Server, dass sie echt ist? SPF prüft, ob die sendende IP-Adresse vom Domain-Inhaber autorisiert ist. Aber SPF versagt bei weitergeleiteten E-Mails und deckt nur den Umschlag ab, nicht die Nachricht selbst. DomainKeys Identified Mail, bekannt als DKIM, verfolgt einen anderen und robusteren Ansatz: Es verwendet kryptografische Signaturen, um zu belegen, dass bestimmte Teile einer E-Mail – Header und Nachrichtentext – vom Inhaber einer bestimmten Domain autorisiert wurden und auf dem Übertragungsweg nicht verändert wurden.

DKIM ist neben SPF und DMARC eine der drei Säulen moderner E-Mail-Authentifizierung. Zu verstehen, wie es funktioniert, was seine Fehlermodi bedeuten und wie es mit DMARC zusammenwirkt, ist für jede Organisation unverzichtbar, die ihre Domain vor Spoofing und Identitätsmissbrauch schützen möchte.

Was ist DKIM?

DomainKeys Identified Mail ist ein E-Mail-Authentifizierungsstandard, der in RFC 6376 definiert ist. Es ermöglicht dem sendenden Mailserver, einer E-Mail eine kryptografische Signatur beizufügen. Die Signatur wird über ausgewählte Header und den Nachrichtentext mithilfe eines privaten Schlüssels berechnet, der vom Absender gehalten wird. Der zugehörige öffentliche Schlüssel wird im DNS unter einer speziellen Subdomain veröffentlicht. Wenn ein empfangender Mailserver die E-Mail erhält, ruft er den öffentlichen Schlüssel ab und verifiziert damit die Signatur.

Ist die Signatur gültig, weiß der empfangende Server zwei Dinge:

1. Die E-Mail wurde von jemandem signiert, der den privaten Schlüssel für die signierende Domain kontrolliert.
2. Die signierten Teile der E-Mail – Header und Nachrichtentext – wurden seit der Signierung nicht verändert.

Entscheidend ist, dass DKIM auf Nachrichtenebene arbeitet, nicht auf Umschlagebene wie SPF. Das bedeutet, es übersteht die E-Mail-Weiterleitung: Wenn ein Weiterleitungsdienst die Nachricht übergibt, verbleiben die DKIM-Signaturen in den Headern und können vom Mailserver des endgültigen Empfängers weiterhin verifiziert werden. Das macht DKIM zum widerstandsfähigeren der beiden Mechanismen SPF und DKIM bei indirekten E-Mail-Flüssen.

Wie DKIM funktioniert – Signierung und Verifizierung

Der DKIM-Prozess hat zwei Seiten: Signierung beim sendenden Server und Verifizierung beim empfangenden Server.

Signierung (ausgehend):

1. Der sendende Mailserver wählt aus, welche Header in die Signatur einbezogen werden – typischerweise From, Subject, Date, To und andere – und kanonisiert sie gemäß einem definierten Algorithmus (simple oder relaxed).
2. Der Server berechnet einen Hash des Nachrichtentexts und nimmt ihn in die Signatur auf.
3. Er signiert die kombinierten Daten mit dem privaten Schlüssel, der einem benannten Selector für die Domain zugeordnet ist.
4. Die resultierende Signatur wird der E-Mail als DKIM-Signature-Header hinzugefügt.

Verifizierung (eingehend):

1. Der empfangende Server liest den DKIM-Signature-Header und extrahiert die signierende Domain (d=) und den Selector (s=).
2. Er führt eine DNS-TXT-Abfrage unter <selector>._domainkey.<domain> durch, um den öffentlichen Schlüssel abzurufen.
3. Er berechnet den Hash der Header und des Nachrichtentexts wie in der Signatur beschrieben neu und verifiziert die Signatur gegen den öffentlichen Schlüssel.
4. Stimmt die Signatur überein und ist der Body-Hash korrekt, lautet das Ergebnis pass. Jede Abweichung – veränderte Header, veränderter Nachrichtentext, falscher Schlüssel – führt zu fail oder einem anderen Nicht-Pass-Ergebnis.

Aufbau eines DKIM-Signature-Headers

Ein DKIM-Signature-Header sieht so aus:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail2024;
  h=from:to:subject:date:message-id; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=abc123...base64kodiertSignatur...==

Die wichtigsten Tags:

Der DNS-Eintrag für den öffentlichen Schlüssel wird unter <selector>._domainkey.<domain> als TXT-Record veröffentlicht, zum Beispiel:

mail2024._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

DKIM-Ergebnistypen: pass, fail, permerror, temperror und mehr

Der DKIM-Verifizierungsprozess kann sechs verschiedene Ergebnisse liefern. Jedes hat unterschiedliche Auswirkungen auf DMARC:

Nur pass kann DMARC-DKIM erfüllen — und nur dann, wenn die signierende Domain auch mit der Header-From-Adresse aligniert ist.

DKIM und DMARC – Warum Alignment der Schlüssel ist

Eine erfolgreich verifizierte DKIM-Signatur ist notwendig, aber nicht ausreichend für DMARC. DMARC fügt eine weitere Anforderung hinzu: Alignment. Die signierende Domain im d=-Tag der DKIM-Signatur muss mit der Domain in der sichtbaren Header-From-Adresse übereinstimmen – also der, die Ihre Empfänger im E-Mail-Client sehen.

Zwei Alignment-Modi stehen zur Verfügung, konfiguriert über den adkim-Tag in Ihrem DMARC-Record:

• Relaxed Alignment (adkim=r, Standard) — die organisatorischen Domains müssen übereinstimmen. Eine Signatur von mail.example.com aligniert mit example.com in der From-Adresse.
• Strict Alignment (adkim=s) — die Domains müssen identisch sein. mail.example.com aligniert nicht mit example.com.

Diese Unterscheidung ist in der Praxis entscheidend. Viele E-Mail-Dienstleister signieren ausgehende Nachrichten standardmäßig mit ihrer eigenen Domain im d=-Tag statt mit Ihrer. Die DKIM-Signatur verifiziert — die Nachricht wurde nicht manipuliert — aber die signierende Domain ist mailchimp.com oder sendgrid.net, nicht ihredomain.de. Das bedeutet: DMARC-DKIM schlägt fehl trotz einer kryptografisch gültigen Signatur.

Die Lösung besteht darin, DKIM-Signierung mit Ihrer eigenen Domain bei jedem ESP zu konfigurieren. Das erfordert typischerweise die Erzeugung eines Schlüsselpaars, das Veröffentlichen des öffentlichen Schlüssels in Ihrem DNS und das Autorisieren des ESPs, den entsprechenden privaten Schlüssel beim Signieren von Nachrichten in Ihrem Namen zu verwenden.

Wie DMARCFlow DKIM-Alignment in DMARC-Reports erklärt

DMARC-Aggregate-Reports enthalten rohe DKIM-Authentifizierungsergebnisse — Domain, Selector und Ergebnis — für jede Nachrichten-Charge aus jeder sendenden Quelle. DMARCFlow analysiert diese Daten Datensatz für Datensatz und ordnet jedes Ergebnis einem von vier klaren DKIM-Insight-Szenarien zu:

Für jeden Datensatz zeigt DMARCFlow auch die einzelnen rohen DKIM-Ergebnisse — signierende Domain, Selector und rohes Ergebnis (pass / fail / permerror / temperror / neutral / none) — zusammen mit einer verständlichen Erklärung, was jedes Ergebnis bedeutet und ob es zu DMARC beitragen kann. Damit werden undurchsichtige XML-Daten zu handlungsorientierten Erkenntnissen.

DKIM vs. SPF – Ergänzend, nicht konkurrierend

SPF und DKIM lösen verwandte, aber unterschiedliche Probleme, und ihre Schwächen ergänzen sich gegenseitig:

DMARC erfordert nur, dass entweder SPF oder DKIM besteht und aligniert ist. In der Praxis bietet die Konfiguration beider Mechanismen Redundanz: Wenn SPF bei einem Weiterleitungsdienst bricht, kann DKIM DMARC noch erfüllen. Wenn DKIM bei einem ESP nicht eingerichtet ist, kann SPF-Alignment noch retten. Die widerstandsfähigste Konfiguration hat beide korrekt aligniert.

Häufige DKIM-Probleme und wie man sie behebt

• Keine DKIM-Signatur überhaupt. Viele Organisationen richten SPF ein, konfigurieren aber nie DKIM-Signierung und sind dadurch vollständig auf SPF für DMARC angewiesen. Jeder ESP, der DKIM nicht unterstützt — oder bei dem DKIM nicht aktiviert wurde — produziert Nachrichten ohne DKIM-Ergebnis. Lösung: DKIM-Signierung bei jeder sendenden Plattform aktivieren und den zugehörigen öffentlichen Schlüssel im DNS veröffentlichen.
• Signierung mit der ESP-Domain statt der eigenen. Die häufigste Ursache für „pass, aber nicht aligniert": Ihr ESP signiert standardmäßig mit seiner eigenen Domain. Lösung: Konfigurieren Sie eine eigene DKIM-Identität beim ESP. Das bedeutet typischerweise, ein Schlüsselpaar im ESP-Control-Panel zu generieren, einen DNS-TXT-Record für den bereitgestellten Selector hinzuzufügen und domainausgerichtete Signierung zu aktivieren.
• Body-Änderungen zerstören die Signatur. Mailinglisten, Weiterleitungsdienste oder Sicherheitsgateways, die Footer anhängen, Subject-Zeilen verändern oder Header modifizieren, können DKIM-Signaturen ungültig machen. Die Verwendung von relaxed-Kanonisierung (c=relaxed/relaxed) toleriert geringfügige Leerraumänderungen, übersteht aber keine strukturellen Modifikationen. Erwägen Sie, in h= nur die stabilsten Header einzubeziehen, oder koordinieren Sie mit Listenbetreibern die Nutzung von ARC (Authenticated Received Chain).
• Abgelaufene oder widerrufene Schlüssel. Wenn ein privater Schlüssel kompromittiert wird oder Sie den DNS-Eintrag für den öffentlichen Schlüssel widerrufen, bevor die TTL abgelaufen ist, können sich noch im Transit befindliche Nachrichten bei DKIM fehlschlagen. Planen Sie die Key-Rotation sorgfältig (siehe unten) und halten Sie alte Schlüsseleinträge für die Dauer möglicher Nachrichten im Transit aktiv.
• permerror bei jeder Nachricht. Ein dauerhafter Fehler bedeutet meist, dass der DKIM-Signature-Header fehlerhaft ist, Pflicht-Tags fehlen oder der DNS-Eintrag für den öffentlichen Schlüssel ungültig oder nicht vorhanden ist. Überprüfen Sie den Eintrag unter <selector>._domainkey.<domain> mit einem DNS-Abfragetool und vergleichen Sie ihn mit dem vom ESP veröffentlichten.
• Intermittierende temperror-Fehler. Vorübergehende DNS-Fehler beim Schlüsselabruf verursachen temperror. Das sind keine kryptografischen Fehler und sollten sich bei einem erneuten Versuch auflösen. Wenn sie dauerhaft auftreten, untersuchen Sie den DNS-Zustand bei Ihrem Registrar oder erwägen Sie einen sekundären DNS-Anbieter.
• Falscher Selector im DNS. Wenn der Selector im DKIM-Signature-Header mit keinem veröffentlichten DNS-Eintrag übereinstimmt, schlägt die Verifizierung fehl. Stellen Sie sicher, dass der in Ihrer Signierungsplattform konfigurierte Selector-Name exakt mit der Subdomain übereinstimmt, unter der Sie den Schlüssel veröffentlicht haben.

DKIM Key Rotation – Warum und wie

Private DKIM-Schlüssel sind langlebige Geheimnisse. Anders als SPF-Records, die öffentlich sind, muss der private Schlüssel vertraulich bleiben. Falls er jemals geleakt oder kompromittiert wird, kann ein Angreifer Nachrichten mit der Identität Ihrer Domain signieren. Key-Rotation — das regelmäßige Ersetzen alter Schlüsselpaare durch neue — begrenzt das Schadensfenster eines kompromittierten Schlüssels.

Eine Best-Practice-Rotation sieht so aus:

1. Neues Schlüsselpaar generieren für einen neuen Selector (z. B. mail2026).
2. Neuen öffentlichen Schlüssel im DNS veröffentlichen unter der neuen Selector-Subdomain.
3. DNS-Propagation abwarten — typischerweise wenige Minuten bis eine Stunde je nach TTL.
4. Signierungsplattform umstellen auf den neuen privaten Schlüssel und Selector.
5. Alten DNS-Eintrag aktiv halten für mindestens 48–72 Stunden (oder länger, wenn Nachrichten verzögert sein können), damit sich noch im Transit befindliche Nachrichten, die mit dem alten Schlüssel signiert wurden, noch erfolgreich verifizieren lassen.
6. Alten DNS-Eintrag entfernen nach Ablauf der Übergangsfrist.

Viele Organisationen rotieren jährlich. Sicherheitsbewusste Organisationen rotieren alle 3–6 Monate. Bei Verdacht auf eine Schlüsselkompromittierung rotieren Sie sofort nach den obigen Schritten, aber komprimieren Sie den Zeitplan.

Wie DMARCFlow DKIM-Komplexität verständlich macht

DKIM über mehrere ESPs, Domains und Selektoren zu verwalten — dabei Fehler zu überwachen, Alignment zu verfolgen und zu wissen, wann Schlüssel rotiert werden müssen — ist eine erhebliche operative Last. DMARCFlow ist darauf ausgelegt, diese Komplexität zu absorbieren und Ihnen eine klare, handlungsorientierte Sicht auf Ihre DKIM-Sicherheitslage zu geben.

Konkret bietet DMARCFlow für DKIM:

• DKIM-Insight-Analyse je Datensatz. Jeder Datensatz in jedem DMARC-Aggregate-Report wird einzeln analysiert. Für jeden Datensatz identifiziert DMARCFlow alle rohen DKIM-Ergebnisse (Domain, Selector, Ergebnis), bestimmt, welches der vier DMARC-DKIM-Szenarien zutrifft, und erklärt das Ergebnis in verständlicher Sprache. Sie sehen genau, welche signierende Domain und welcher Selector DMARC-DKIM erfüllt haben — oder genau warum es fehlgeschlagen ist.
• Alignment-Modus-Bewusstsein. DMARCFlow liest den adkim-Tag aus Ihrer tatsächlichen DMARC-Richtlinie aus und bewertet jedes DKIM-Ergebnis gegen den korrekten Alignment-Modus — relaxed oder strict. Die Analyse spiegelt stets Ihre reale Konfiguration wider, keine generischen Annahmen.
• Unterstützung mehrerer Signaturen. Eine E-Mail kann mehr als eine DKIM-Signatur tragen — zum Beispiel eine von Ihrer Domain und eine vom ESP. DMARCFlow wertet alle aus und bestimmt korrekt, ob mindestens eine einen alignierten Pass liefert, was DMARC erfordert.
• Authentifizierungsfehler-Analyse. Wenn DKIM-Fehler über viele Datensätze auftreten, gruppiert sie DMARCFlow, berechnet Fehlerquoten nach sendender Quelle und zeigt die fehlschlagenden IP-Adressen — damit Sie wissen, wo zuerst zu untersuchen ist.
• Security Score mit DKIM-Komponente. DMARCFlow berechnet einen Security Score von 100 für Ihre Domain. Die Aufschlüsselung zeigt genau, wie Ihre DKIM-Sicherheitslage zum Gesamtscore beiträgt — neben SPF, Policy-Durchsetzung, Abdeckung und Reporting. Eine Domain ohne DKIM-Alignment wird an einem hohen Score gehindert, und die Aufschlüsselung erklärt warum.
• Maturity Level Tracking. Domains ohne DKIM-Alignment sind auf niedrigere Reifegradstufen beschränkt. Das Reifegradmodell von DMARCFlow zeigt präzise, was die Weiterentwicklung blockiert und was die Konfiguration von DKIM-Alignment freischalten würde.
• Empfehlungs-Engine. Wenn DKIM aufgrund einer nicht-alignierten signierenden Domain bei einem bestimmten ESP fehlschlägt, erklärt DMARCFlow, was zu beheben ist und wie — einschließlich Anleitungen zur Veröffentlichung eines eigenen Selectors für diese Plattform.
• DSGVO-konform, EU-gehostet. Alle Report-Daten werden ausschließlich innerhalb der Europäischen Union verarbeitet und gespeichert. Es werden keine personenbezogenen Daten vorgehalten. Unverzichtbar für DSGVO-regulierte Organisationen.

Fazit

DKIM ist ein leistungsstarker und robuster E-Mail-Authentifizierungsmechanismus. Durch das Anfügen einer kryptografischen Signatur an Ihre ausgehenden Nachrichten beweist er, dass bestimmte Teile der E-Mail von einem Inhaber des privaten Schlüssels Ihrer Domain autorisiert wurden und auf dem Übertragungsweg nicht verändert wurden. Anders als SPF übersteht DKIM die E-Mail-Weiterleitung — was ihn unverzichtbar für Organisationen macht, die auf Mailinglisten, Weiterleitungsdienste oder indirekte Sendewege angewiesen sind.

Aber ein DKIM-Pass allein genügt DMARC nicht. Die signierende Domain muss mit der Header-From-Adresse unter dem konfigurierten Alignment-Modus übereinstimmen. Die vier DKIM-Insight-Szenarien — von einer alignierten Signatur, die besteht, bis zu keinerlei DKIM-Ergebnissen — repräsentieren das gesamte Spektrum dessen, was Ihnen in DMARC-Reports begegnen wird. Zu wissen, welches Szenario auf jede Ihrer sendenden Quellen zutrifft, ist das, was die richtige Korrekturmaßnahme ermöglicht.

DMARCFlow macht diese Diagnose schnell und präzise. Es analysiert jedes DKIM-Ergebnis in jedem DMARC-Report, ordnet es einem klaren Szenario zu und gibt Ihnen die Empfehlungen, um zu handeln — ob das bedeutet, einen eigenen Selector bei einem ESP zu veröffentlichen, einen Schlüssel zu rotieren oder einen dauerhaften permerror zu untersuchen. Gepaart mit dem Security Score, Maturity-Tracking und DSGVO-konformem Datenmanagement haben Sie eine Plattform, die Sie von „DKIM existiert irgendwo" zu „DKIM ist vollständig aligniert und schützt meine Domain aktiv" bringt.