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

Du hast DKIM aktiviert, deinen Schlüssel veröffentlicht, und jetzt willst du 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 deiner 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

Du musst die kryptografischen Berechnungen nicht von Hand nachmachen: Der empfangende Server hat es bereits getan, und er schreibt sein Urteil in einen Header der Nachricht, Authentication-Results. Öffne eine E-Mail, die du gesendet hast (in einem Postfach, das nicht deins ist), und zeige ihre vollständigen Header an (oft „Original anzeigen" oder „Quelltext anzeigen"). Suche eine Zeile wie:

Authentication-Results: mx.google.com;
  dkim=pass header.d=ton-domaine.fr;
  spf=pass ...; dmarc=pass ...

Drei Schlüsselinformationen hier: dkim=pass (die Signatur ist gültig), header.d=ton-domaine.fr (die signierende Domain — prüfe, dass es deine ist), und dmarc=pass (das Ganze richtet sich aus und erfüllt DMARC). Wenn dkim=pass, aber header.d die eines Dienstleisters ist, ist deine Signatur gültig, aber nicht ausgerichtet — sie zählt nicht für DMARC.

Den DKIM-Signature-Header lesen

Um weiterzugehen, schau dir direkt den DKIM-Signature-Header der Nachricht an. Er enthält mehrere Tags:

• d= — die signierende Domain. Sie ist es, die sich mit deinem 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

Du kannst die Hälfte der Gleichung kontrollieren, ohne überhaupt eine Nachricht zu senden: den öffentlichen Schlüssel. Frage den Selektor im DNS ab:

dig TXT selecteur._domainkey.ton-domaine.fr

Du musst dort einen Eintrag v=DKIM1; k=rsa; p=... mit einem vollständigen und nicht leeren öffentlichen Schlüssel finden. 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 deines Schlüssels und, gekoppelt mit deinen Berichten, die tatsächliche Ausrichtung deiner 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 deines From: übereinstimmt. Viele Plattformen signieren standardmäßig mit ihrer Domain (d=plateforme.com): dkim=pass, aber keine Ausrichtung, also stützt sich DMARC nicht darauf. Der endgültige Beweis der Ausrichtung liest sich in deinen 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 Fehler deiner Konfiguration — 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: Schau auf Volumen und Quelle, bevor du auf ein Problem schließt.

Ein vollständiges Authentication-Results zerlegen

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

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

Dekodieren wir. dkim=pass header.d=entreprise.fr: Die Signatur ist gültig und auf deine Domain ausgerichtet — perfekt. spf=fail: Hier scheitert SPF, weil der Envelope dem Router gehört, nicht dir; 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, sagt dir 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 deine Richtlinie anwendet. Anders gesagt, zu prüfen, dass deine DKIM-Signatur besteht, ist notwendig, aber nicht hinreichend: Solange deine DMARC-Richtlinie im p=none bleibt, erreicht eine Nachricht, die deine Domain fälscht — ohne jede gültige Signatur deinerseits — trotzdem die Postfächer. Die DKIM-Prüfung ist also ein Baustein eines größeren Bauwerks; sobald deine 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 deinen veröffentlichten Eintrag. Sobald eine Nachricht weitergeleitet wird, ändert sich diese sendende IP: Es ist nicht mehr dein Server, sondern der des Weiterleitenden, der die Nachricht ausliefert. SPF scheitert also fast systematisch bei einer Weiterleitung, weil die neue IP nicht in deinem Eintrag steht — und daran kannst du 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. Wenn du entscheiden musst, welchen der beiden Mechanismen du zuerst sorgfältig ausrichtest, 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 deinen 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 deinem From: ausrichten. Prüfe immer beides.

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? Du kannst ihren öffentlichen Schlüssel prüfen (das DNS ist öffentlich) und das Ergebnis in den Headern einer E-Mail lesen, die sie dir gesendet hat. Das ist nützlich, um einen Partner zu diagnostizieren.

Ist ein leeres p= normal? Nein: Ein leeres p= signalisiert einen widerrufenen Schlüssel. Wenn deine Signaturen auf einen Selektor zeigen, dessen Schlüssel leer ist, werden sie scheitern — veröffentliche einen gültigen Schlüssel neu.

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

Die Prüfung in deine 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 deine DMARC-Aggregatberichte (bestätigen, dass alle deine Quellen ihre Ausrichtung über die Zeit halten, ohne stille Drift). Die Aggregatberichte sind besonders nützlich, weil sie die Gesamtheit deiner Sendequellen abdecken, ohne dass du eine Test-E-Mail zu jeder senden müsstest — sie geben dir 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 deine Zustellbarkeit oder deine DMARC-Haltung beeinträchtigt.

Lass Thomas deine Signaturen bestätigen

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

Analysiere deine Domain kostenlos → oder erstelle ein Konto für kontinuierlich geprüfte DKIM-Signaturen.