Wie man die DKIM-Signatur einer E-Mail prüft

Von Thomas · virtueller CISO · 2026-07-13

DKIM ist aktiviert, der Schlüssel veröffentlicht — bleibt die Frage, die wirklich zählt: funktioniert es? Eine DKIM-Signatur zu prüfen heißt zu bestätigen, dass eine Nachricht tatsächlich signiert wurde, dass die Signatur gültig ist, und — für DMARC — dass sie sich mit der eigenen Domain ausrichtet. Dieser Leitfaden zeigt, wo man das Ergebnis liest, wie man die Tags der Signatur interpretiert, wie man selbst prüft, und warum eine legitime Signatur manchmal scheitern kann.

Die einfachste Methode: `Authentication-Results` lesen

Die kryptografischen Berechnungen muss niemand von Hand nachmachen: Der empfangende Server hat es bereits getan, und er schreibt sein Urteil in einen Header der Nachricht, Authentication-Results. Man öffnet eine selbst versandte E-Mail in einem fremden Postfach und zeigt ihre vollständigen Header an (oft „Original anzeigen" oder „Quelltext anzeigen"). Gesucht wird eine Zeile wie:

Authentication-Results: mx.google.com;
  dkim=pass header.d=beispiel.de;
  spf=pass ...; dmarc=pass ...

Drei Schlüsselinformationen hier: dkim=pass (die Signatur ist gültig), header.d=beispiel.de (die signierende Domain — sie muss die eigene sein), und dmarc=pass (das Ganze richtet sich aus und erfüllt DMARC). Lautet dkim=pass, aber header.d gehört einem Dienstleister, ist die Signatur gültig, aber nicht ausgerichtet — sie zählt nicht für DMARC.

Den `DKIM-Signature`-Header lesen

Um weiterzugehen, lohnt der direkte Blick auf den DKIM-Signature-Header der Nachricht. Er enthält mehrere Tags:

d= — die signierende Domain. Sie ist es, die sich mit dem From: für DMARC ausrichten muss.
s= — der Selektor, der auf den zu verwendenden öffentlichen Schlüssel zeigt (siehe der Selektor).
h= — die Liste der von der Signatur abgedeckten Header.
bh= — der Hash des Rumpfs der Nachricht.
b= — die kryptografische Signatur selbst.

Der Empfänger holt den öffentlichen Schlüssel bei s=._domainkey.d=, berechnet den Hash des Rumpfs und der signierten Header neu, und vergleicht mit b=. Wenn alles übereinstimmt, dkim=pass. Diese Mechanik erklärt die meisten Ausfälle (siehe unten).

Selbst prüfen, ohne auf eine E-Mail zu warten

Die Hälfte der Gleichung lässt sich kontrollieren, ohne überhaupt eine Nachricht zu senden: der öffentliche Schlüssel. Dazu wird der Selektor im DNS abgefragt:

dig TXT selektor._domainkey.beispiel.de

Dort muss ein Eintrag v=DKIM1; k=rsa; p=... mit einem vollständigen und nicht leeren öffentlichen Schlüssel stehen. Ein fehlender, abgeschnittener Schlüssel oder ein leeres p= (widerrufener Schlüssel) garantiert den Ausfall. Für die End-to-End-Prüfung — Signatur inbegriffen — macht ein Analyzer die Runde: Unser kostenloser DMARC-Analyzer bestätigt die Präsenz und Gültigkeit des Schlüssels und, gekoppelt mit den Berichten, die tatsächliche Ausrichtung der Quellen.

Die Ausrichtung: das Einzige, was für DMARC zählt

Wiederholen wir es, denn es ist der Fehler Nr. 1: Eine gültige DKIM-Signatur nützt DMARC nur, wenn sie ausgerichtet ist. Die DKIM-Ausrichtung bedeutet, dass die d=-Domain der Signatur mit der Domain des From: übereinstimmt. Viele Plattformen signieren standardmäßig mit ihrer Domain (d=plattform.de): dkim=pass, aber keine Ausrichtung, also stützt sich DMARC nicht darauf. Der endgültige Beweis der Ausrichtung liest sich in den Aggregatberichten, Quelle für Quelle. Für das vollständige Konzept siehe wie die drei Protokolle zusammenarbeiten.

Warum eine legitime Signatur manchmal scheitert

Eine Signatur kann scheitern, obwohl die Nachricht völlig legitim ist. Die klassischen Ursachen:

Der Rumpf der Nachricht wurde im Transit verändert. Eine Verteilerliste, die eine Fußzeile hinzufügt, ein Gateway, das den Inhalt umschreibt: Der Hash bh= stimmt nicht mehr, die Signatur bricht. Das ist häufig bei Listen und manchen Weiterleitungen.
Der öffentliche Schlüssel ist abwesend oder abgeschnitten beim angegebenen Selektor (fehlende Veröffentlichung, beim Kopieren abgeschnittener Schlüssel).
Der Selektor entspricht nichts — typischerweise nach einer Rotation, bei der der alte Selektor zu früh entfernt wurde.
Der Schlüssel ist widerrufen (p= leer) oder die DNS-Verbreitung ist für einen frisch veröffentlichten Schlüssel nicht abgeschlossen.

Gute Nachricht: DKIM übersteht die Weiterleitung besser als SPF (die Signatur reist mit der Nachricht), was es zum zuverlässigsten Anker für die DMARC-Ausrichtung macht — wenn der Rumpf nicht verändert wird.

Der Fall der Weiterleitungen und Listen

Ein Punkt, der verwirrt: Eine weitergeleitete oder über eine Verteilerliste gelaufene Nachricht kann ihre DKIM-Signatur brechen sehen, wenn der Inhalt verändert wird. Das ist kein Konfigurationsfehler — es ist die Liste, die die Nachricht nach der Signatur ändert. Für diese Fälle existieren ergänzende Mechanismen (wie ARC, das das Authentifizierungsergebnis über die Zwischenstationen bewahrt), aber das Wesentliche zum Merken ist, bei vereinzelten DKIM-Ausfällen, die offensichtlich aus Weiterleitungen stammen, nicht in Panik zu geraten: Volumen und Quelle kommen zuerst, erst dann der Schluss auf ein Problem.

Ein vollständiges Authentication-Results zerlegen

Dieser Header verdichtet das Urteil der drei Mechanismen, und ihn lesen zu können erspart viele Vermutungen. Ein Beispiel:

Authentication-Results: mx.exemple.com;
  dkim=pass header.d=unternehmen.de header.s=mail2025;
  spf=fail smtp.mailfrom=router.com;
  dmarc=pass (p=reject) header.from=unternehmen.de

Dekodieren wir. dkim=pass header.d=unternehmen.de: Die Signatur ist gültig und auf die Absenderdomain ausgerichtet — perfekt. spf=fail: Hier scheitert SPF, weil der Envelope dem Router gehört, nicht dem Absender; das ist nicht schlimm, denn DMARC braucht nur eine einzige Ausrichtung. dmarc=pass (p=reject): Trotz des SPF-Ausfalls erfüllt die Nachricht DMARC dank ausgerichtetem DKIM. Das ist die konkrete Illustration, warum die DKIM-Ausrichtung das Arbeitspferd realer Deployments ist: Sie rettet die Authentifizierung dort, wo SPF sich wegen des Drittanbieter-Envelope nicht ausrichtet. Diesen Header vollständig zu lesen, statt beim ersten pass aufzuhören, verrät genau, warum eine Nachricht besteht oder scheitert.

Wenn DKIM allein nicht genügt

DKIM prüft die Integrität und den Ursprung, aber es sagt allein nichts darüber, was ein Empfänger mit einer nicht signierten oder gefälschten Nachricht tun soll. Das ist die Rolle von DMARC, das sich auf die DKIM-Ausrichtung (oder SPF) stützt und die veröffentlichte Richtlinie anwendet. Anders gesagt, zu prüfen, dass die DKIM-Signatur besteht, ist notwendig, aber nicht hinreichend: Solange die DMARC-Richtlinie im p=none bleibt, erreicht eine Nachricht, die die Domain fälscht — ohne jede gültige Signatur des echten Inhabers — trotzdem die Postfächer. Die DKIM-Prüfung ist also ein Baustein eines größeren Bauwerks; sobald die Signaturen zuverlässig und ausgerichtet sind, ist der nächste Schritt, DMARC bis p=reject zu verschärfen, damit das Fehlen einer gültigen Signatur endlich reale Konsequenzen für die Fälscher hat.

Warum DKIM die Weiterleitung besser übersteht als SPF

Dieser Punkt verdient eine eigene Erklärung, denn er ist der Grund, warum die DKIM-Ausrichtung in realen Deployments so zentral ist. SPF prüft die IP-Adresse des sendenden Servers gegen den veröffentlichten Eintrag. Sobald eine Nachricht weitergeleitet wird, ändert sich diese sendende IP: Es ist nicht mehr der Server des Absenders, sondern der des Weiterleitenden, der die Nachricht ausliefert. SPF scheitert also fast systematisch bei einer Weiterleitung, weil die neue IP nicht im Eintrag steht — und daran lässt sich nichts ändern.

DKIM funktioniert grundlegend anders: Die Signatur ist an den Inhalt der Nachricht gebunden, nicht an den sendenden Server. Sie reist mit der Nachricht, egal über wie viele Zwischenstationen sie läuft, und bleibt gültig, solange der Rumpf und die signierten Header unverändert bleiben. Ein Weiterleitender, der nichts am Inhalt ändert, bricht die DKIM-Signatur nicht — und genau deshalb ist DKIM der zuverlässigere der beiden Anker für DMARC. Steht die Entscheidung an, welcher der beiden Mechanismen zuerst sorgfältig auszurichten ist, ist DKIM in fast allen Fällen die bessere Investition, weil er die Weiterleitungen überlebt, die SPF unweigerlich zu Fall bringen.

Die Grenze bleibt der veränderte Inhalt: Eine Verteilerliste, die eine Fußzeile oder ein [EXTERN]-Präfix im Betreff hinzufügt, bricht den Hash und damit die Signatur. Dafür wurde ARC entworfen, das das ursprüngliche Authentifizierungsergebnis über die Zwischenstationen bewahrt — aber ARC ist noch nicht universell eingesetzt, und die pragmatische Haltung bleibt, vereinzelte DKIM-Ausfälle aus Listen zu erkennen und nicht mit echten Fälschungen zu verwechseln.

Häufige Fragen

Wo sehe ich, ob DKIM besteht? Im Authentication-Results-Header der empfangenen Nachricht (dkim=pass/fail), und aggregiert in den DMARC-Berichten. „Original anzeigen" in den meisten Webmails gibt Zugang zu den Headern.

Genügt dkim=pass? Für die Gültigkeit der Signatur, ja. Für DMARC, nein: Es muss sich auch header.d (die signierende Domain) mit dem From: ausrichten. Beides gehört immer geprüft.

Warum scheitert mein DKIM nur bei manchen E-Mails? Oft, weil diese Nachrichten über eine Liste oder eine Weiterleitung laufen, die den Rumpf verändert und den Hash bricht. Die Direktversände bestehen. Das Profil (Listen, geringes verstreutes Volumen) verrät die Ursache.

Kann ich das DKIM einer Drittdomain prüfen? Der öffentliche Schlüssel ist prüfbar (das DNS ist öffentlich), und das Ergebnis steht in den Headern jeder E-Mail, die sie versandt hat. Das ist nützlich, um einen Partner zu diagnostizieren.

Ist ein leeres p= normal? Nein: Ein leeres p= signalisiert einen widerrufenen Schlüssel. Zeigen die Signaturen auf einen Selektor, dessen Schlüssel leer ist, werden sie scheitern — dann ist ein gültiger Schlüssel neu zu veröffentlichen.

Wie lange dauert es, bis DKIM in den Berichten sichtbar ist? Die DMARC-Berichte werden am Ende der Berichtsperiode gesendet (oft 24 Stunden). Die ersten geprüften Signaturen tauchen am Tag nach der Aktivierung auf. Bei geringem Versandvolumen braucht es vielleicht ein paar Tage für eine repräsentative Stichprobe.

Die Prüfung in die Routine integrieren

Die DKIM-Prüfung sollte kein punktueller Handgriff sein, den man bei der Konfiguration macht und dann vergisst. Drei Schlüsselmomente verdienen eine aktive Prüfung: bei der Aktivierung (bestätigen, dass der Schlüssel veröffentlicht ist, die Signatur besteht und sich ausrichtet); nach jeder Rotation (bestätigen, dass der neue Selektor korrekt signiert und der alte keinen Fehler hinterlassen hat); und periodisch, über die DMARC-Aggregatberichte (bestätigen, dass alle Quellen ihre Ausrichtung über die Zeit halten, ohne stille Drift). Die Aggregatberichte sind besonders nützlich, weil sie die Gesamtheit der Sendequellen abdecken, ohne dass an jede eine Test-E-Mail gehen müsste — sie liefern eine systematische Sicht, Domain für Domain, Quelle für Quelle. Das Lesen der Berichte in eine monatliche Routine zu setzen — auch schnell, auch partiell — ist das einzige Mittel, um eine sich verschlechternde Signatur zu erkennen, bevor sie die Zustellbarkeit oder die DMARC-Haltung beeinträchtigt.

Thomas bestätigt die Signaturen

Für jede Quelle Header von Hand zu lesen, ist mühsam und unvollständig. Thomas, der virtuelle CISO, prüft, dass jede Quelle in DKIM signiert, dass die Signatur gültig und ausgerichtet mit der Domain ist, und meldet die Quellen, deren Signatur bricht — Listen und Weiterleitungen ausgenommen — bevor sie die Bereitschaft für p=reject belasten.

Eine Domain kostenlos analysieren oder ein Konto erstellen für kontinuierlich geprüfte DKIM-Signaturen.

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