Was Sie über das Fehlschlagen von DKIM wissen müssen

Domain Keys Identified Mail (DKIM) ist eine E-Mail-Authentifizierungsmethode, mit der gefälschte Absenderadressen in E-Mails erkannt werden sollen.

Mit DKIM kann der Empfänger überprüfen, ob eine E-Mail, die angeblich von einer bestimmten Domain stammt, tatsächlich vom Eigentümer dieser Domain autorisiert wurde. Dies wird erreicht, indem jede ausgehende E-Mail-Nachricht mit einer digitalen Signatur versehen wird, die mit einem Domain-Namen verknüpft ist.

Das Empfängersystem kann dies überprüfen, indem es den im DNS veröffentlichten öffentlichen Schlüssel des Absenders nachschlägt. Eine gültige Signatur garantiert auch, dass einige Teile der E-Mail (möglicherweise einschließlich der Anhänge) seit dem Anbringen der Signatur nicht verändert wurden. In der Regel sind DKIM-Signaturen für die Endnutzer nicht sichtbar, da sie von der Infrastruktur und nicht von den Verfassern und Empfängern der Nachricht überprüft und angebracht werden. Die DKIM-Spezifikationen sind im RFC 6376 definiert.

DKIM ermöglicht es dem Empfängerserver, sich zu vergewissern (oder zu überprüfen), dass die empfangene Nachricht vom echten Absender der zugehörigen Domain gesendet wurde und dass der Inhalt der ursprünglichen Nachricht auf ihrem Weg nicht verändert wurde.

Wie unterscheidet sich SPF von DKIM?

Während DKIM es dem empfangenden Mailserver ermöglicht, die Authentizität des Nachrichteninhalts und seine Verbindung mit der sendenden Domain zu überprüfen, indem er die öffentliche DKIM-Zeichenkette nachschlägt, die mit einem bestimmten sendenden System verbunden ist, ermöglicht SPF die Überprüfung, ob die empfangene E-Mail tatsächlich von einer autorisierten Quelle (eventuell von einer IP-Adresse) stammt, die vom Absender über die Veröffentlichung der Liste der autorisierten „Absender-Quellen“ im DNS definiert wurde.

Was ist der Vorteil von DKIM gegenüber SPF?

• In den meisten Fällen wird die DKIM-Signatur (oder das Ergebnis einer vorherigen Überprüfung) während der automatischen Weiterleitung von E-Mails beibehalten, wodurch der empfangende Server sicherstellen kann, dass die empfangene E-Mail echt ist (obwohl es einige Ausnahmen gibt, die im nächsten Punkt erwähnt werden), während SPF fast immer während der Weiterleitung von E-Mails unterbrochen wird (mit der offensichtlichsten Ausnahme, wenn die automatische Weiterleitung zwischen Empfängern innerhalb derselben Domain erfolgt).
• Für die automatische Weiterleitung von Nachrichten werden 2 Methoden verwendet:
• Einige ESPs (z. B. Outlook/Hotmail, iCloud, MailRu) behalten die ursprüngliche smtp.mailfrom-Adresse (Absenderpfad) bei, so dass die Ergebnisse der SPF-Authentifizierungsprüfung einen Domain-Abgleich zeigen, aber fehlschlagen, da der SPF-Eintrag der smtp.mailfrom-Domain die IP-Adresse des Weiterleitungs-Servers nicht abdeckt.
• Andere ESPs (z. B. Gmail/G Suite, O365, Yahoo, Yandex Mail) schreiben die smtp.mailfrom (return-path)-Adresse mit ihrer Domain um, so dass die Ergebnisse der SPF-Authentifizierungsprüfung einen fehlerhaften Domain-Abgleich zeigen, aber erfolgreich sind, da der SPF-Eintrag der umgeschriebenen smtp.mailfrom-Domain die IP-Adresse des Weiterleitungs-Servers enthält.

In beiden Fällen schlägt die SPF-Prüfung also fehl, da die Voraussetzung des Abgleichs der Header-From-Domain mit der smtp.mailfrom-Domain und die Validierung des SPF-Eintrags nie stattfinden.

Wann kann DKIM die Prüfung nicht bestehen?

Die DKIM-Prüfung schlägt fehl, wenn die DKIM-Authentifizierungsprüfungen fehlschlagen. Hier sind mögliche Gründe für fehlgeschlagene Prüfungen:

• DKIM-Signatur-Domain und Absender-Domain (Header From) stimmen nicht überein.
• Der im DNS veröffentlichte öffentliche DKIM-Schlüssel-Eintrag ist nicht korrekt oder wird gar nicht veröffentlicht.
• Die DNS-Zone der Domain des Absenders ist für die Suche unerreichbar. Dies ist eine übliche Situation für schlechte Host-Anbieter.
• Die Länge des DKIM-Schlüssels, der zum Signieren verwendet wird, ist zu kurz. Heutzutage werden 1024 und 2048 Bit lange Schlüssel unterstützt. Wenn Ihr Webmail-Hosting-Provider also E-Mails mit einem DKIM-Schlüssel geringerer Länge signiert, schlägt die DKIM-Signaturprüfung fehl.
• Während der automatischen Weiterleitung wurden Änderungen im Nachrichtentext vorgenommen.

Schauen wir uns den letzten Fall genauer an.

Sign Up Free

Wenn z. B. der Forwarder den Compliance-Fußtext an die empfangene E-Mail anhängt und sie automatisch weiterleitet, wird der ursprüngliche Nachrichteninhalt verändert, so dass die Nachrichtenintegrität unterbrochen wird. Infolgedessen ist der empfangende Server nicht in der Lage, die DKIM-Signatur zu verifizieren, und das DKIM-Verifizierungsergebnis, das in der Kopfzeile der empfangenen Nachricht enthalten ist, wird als „dkim=neutral (body hash did not verify)“ gelesen. Nachfolgend ist der Auszug aus dem Gmail-Nachrichtenkopf zu sehen.

Authentication-Results: mx.google.com;

dkim=neutral (body hash did not verify) [email protected] header.s=google header.b=QR1SAS6X;

arc=pass (i=2 spf=pass spfdomain=company.com dkim=pass dkdomain=company.com dmarc=pass fromdomain=company.com);

spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender)

smtp.mailfrom=”[email protected]”;

dmarc=fail (p=REJECT sp=REJECT dis=NONE arc=pass) header.from=company.com

Ist es möglich, eine fehlgeschlagene DKIM-Prüfung zu vermeiden?

Alle oben aufgeführten Fälle, mit Ausnahme des letzten, sind technische Probleme, die Sie durch entsprechende Maßnahmen lösen können.

Was den letzten Fall betrifft, so ist es nicht realistisch, ihn zu vermeiden, da Sie die Empfänger nicht zwingen können, keine Compliance-Fußzeilen mehr anzuhängen, was durchaus üblich und manchmal sogar obligatorisch ist, insbesondere in einem Unternehmensumfeld.

Was passiert mit solchen automatisch weitergeleiteten E-Mails, die sowohl SPF als auch DKIM nicht erfüllen, wenn Sie die DMARC-Richtlinie „reject“ durchsetzen?

• Vor einigen Jahren war es für die Empfängerserver eine echte Herausforderung, mit solchen nicht authentifizierten, aber echten E-Mails umzugehen, aber jetzt, wo viele große ESPs das Protokoll Authenticated Received Chain (ARC) verwenden, hat sich die Situation verbessert.
• ARC ist ein Protokoll, das es jedem E-Mail-Server, der die Nachricht verarbeitet, ermöglicht, festzustellen, welcher E-Mail-Server sie zuvor bearbeitet hat und wie die Authentifizierungsbewertung der Nachricht bei jedem Schritt in der Bearbeitungskette war.

Wenn Google also z. B. eine E-Mail erhält, die sowohl die SPF- als auch die DKIM-Abgleichsprüfung nicht bestanden hat, kann es anhand der Kopfzeile der Nachricht feststellen, ob die E-Mail die SPF- und DKIM-Abgleichsprüfung bei dem vorherigen E-Mail-Server bestanden hat, der die Nachricht an Gmail / G Suite weitergeleitet hat. Wenn sie bestanden hat, stuft Google die Richtlinie „reject“ der sendenden Domain entweder auf „none“ oder „quarantine“ herab, so dass die Richtlinie „reject“ für solche Nachrichten nicht gilt (siehe Screenshot unten).

Warum sehe ich DKIM= neutral (body hash did not verify)?

Wenn die Überprüfung des Hashwerts des Nachrichtentextes fehlschlägt, bedeutet dies, dass der berechnete Hashwert des Nachrichtentextes nicht mit dem Hashwert des Nachrichtentextes übereinstimmt, der im „bh=“-Tag der DKIM-Signatur gespeichert ist.

Einige E-Mail-Server von Unternehmen fügen Inline-Text an das Ende eingehender E-Mails an, bevor sie von Anti-Spam-Agenten analysiert werden. In solchen Fällen würde der Body-Hash-Wert ungültig werden.

Die E-Mail(s) von dieser Quelle haben die DMARC-Prüfung nicht bestanden. Dies bedeutet, dass die E-Mail nicht DMARC-konform war und daher sowohl SPF als auch DKIM ungültig sind. Dies kann zweierlei bedeuten:

Die Quelle hat die DMARC-Prüfungen nicht bestanden, weil DKIM und/oder SPF nicht korrekt eingerichtet waren.

Die Quelle hat die DMARC-Prüfungen nicht bestanden, weil jemand bösartige E-Mails im Namen Ihrer Domain versendet hat.

Es ist wichtig, dass Sie alle Quellen, die im Abschnitt „fehlgeschlagen“ erscheinen, untersuchen, um die Quellen als gültig oder bösartig zu identifizieren. Wenn Sie eine Quelle als legitim erkennen, können Sie in den Daten suchen und sicherstellen, dass Sie SPF oder DKIM korrekt einrichten und ausrichten. Wenn Sie eine Quelle nicht erkennen, müssen Sie dies untersuchen, da diese Quelle möglicherweise versucht, bösartige E-Mails im Namen Ihrer Domain zu versenden.

Es gibt mehrere Gründe, die zu DKIM= neutral (body hash did not verify) führen können:

• Ein Forwarder, ein Smart-Host oder ein anderer Filteragent hat den Text der E-Mail verändert.
• Der Unterzeichner hat den Signaturwert falsch berechnet.
• Jemand hat die E-Mail gefälscht und signiert, ohne den richtigen privaten Schlüssel zu besitzen.
• Der im DKIM-Signatur-Header angegebene öffentliche Schlüssel ist falsch.
• Der öffentliche Schlüssel, den der Absender in seinem DNS veröffentlicht hat, ist falsch.

Sie können die folgenden Schritte unternehmen, um die Quelle zu untersuchen:

• Erkenne ich die Quelle als einen Partner meines Unternehmens?
• Suchen Sie bei Google, um welche Art von Quelle es sich handelt.
• Steht die Quelle auf einer schwarzen Liste von RBL-Websites?
• Prüfen Sie die forensischen Berichte, um zu sehen, welche Art von E-Mails die Quelle versendet.
• Wenn die Quelle gültig ist, suchen Sie nach einer Dokumentation, um DMARC korrekt einzurichten.
• Nehmen Sie Kontakt mit der Quelle auf.

DKIM-Fehler in Berichten

Wie SPF ist auch DKIM ein wichtiger Aspekt von DMARC. Wenn der DKIM-Abgleich fehlschlägt – oder wenn der d=-Wert im Header From nicht mit dem d=-Wert in der DKIM-Signatur übereinstimmt –, kann sich dies negativ auf die Zustellbarkeit auswirken, da Mailbox-Anbieter die Nachricht möglicherweise an den Spam-Ordner senden oder sie ganz blockieren.

Fehler: Mehrere DKIM-Signaturen

Die Spezifikation erlaubt es, E-Mails mit zwei DKIM-Signaturen zu versehen. Die erste Signatur hatte einen d=-Wert, der mit der Header From-Domain der E-Mail übereinstimmte, und die zweite hatte einen d=-Wert einer Domain, die dem Absender eines Dritten gehörte.

Zur Erinnerung: Damit eine Nachricht den DKIM-Abgleich bestehen kann, muss der d=-Wert in der DKIM-Signatur mit dem d=-Wert in der Header From-Adresse übereinstimmen. Bei der Analyse der von den einzelnen Mailbox-Anbietern gemeldeten Ergebnisse konnten wir feststellen, dass die Mailbox-Anbieter, die sowohl DKIM bestanden als auch DKIM-Abgleich meldeten, zur Überprüfung des Abgleichs den d=-Wert in der ersten Signatur verwendeten, der mit der d= Domain in der Header From-Adresse übereinstimmte. Aufgrund dieser Übereinstimmung meldeten die Mailbox-Anbieter ein positives Ergebnis.

Der Schuldige kann der d=-Wert in der Signatur sein, da er nicht mit der Header From-Adresse übereinstimmte.

Die Lösung: Entfernen Sie die zweite DKIM-Signatur

Ein Absender erstellt die DKIM, indem er die E-Mail mit einer digitalen Signatur „signiert“. Diese „Signatur“ befindet sich in der Kopfzeile der Nachricht. Der sendende Mail Transfer Agent (MTA) erzeugt die Signatur mit Hilfe eines Algorithmus, der auf den Inhalt der signierten Felder angewendet wird. Dieser Algorithmus erzeugt eine eindeutige Zeichenkette oder einen „Hash-Wert“.

Wenn der MTA die Signatur erzeugt, speichert die aufgelistete Domain den öffentlichen Schlüssel, der zur Erzeugung der Signatur verwendet wurde. Nach dem Empfang der E-Mail kann der Empfänger-MTA die DKIM-Signatur überprüfen, indem er den öffentlichen Schlüssel des Unterzeichners über DNS wiederherstellt. Der MTA des Empfängers verwendet dann diesen Schlüssel, um den Hash-Wert in der Kopfzeile der E-Mail zu entschlüsseln und gleichzeitig den Hash-Wert für die empfangene E-Mail-Nachricht neu zu berechnen. Wenn diese beiden Schlüssel übereinstimmen, wurde die E-Mail nicht verändert. Dies gibt den Benutzern die Sicherheit, dass die E-Mail tatsächlich von der angegebenen Domain stammt und seit dem Versand nicht verändert wurde.

Beim Versand einer großen Anzahl von Marketingnachrichten pro Tag ist es unvermeidlich, dass ein kleiner Prozentsatz DMARC nicht besteht. Einige dieser Nachrichten scheitern, weil die Weiterleitungen ihre DKIM-Signaturen brechen und somit DMARC am endgültigen Zielort nicht bestehen.

Auch wenn der Prozentsatz der Fehler gering sein mag (0,1 % oder weniger), wenn Sie Millionen oder Zehnmillionen von Nachrichten pro Tag versenden, sind das Tausende von Fehlern. Es ist äußerst schwierig und zeitaufwändig, sich durch dieses Rauschen hindurchzuwühlen.

Kann DKIM E-Mails filtern?

Nein, das ist nicht der Fall. Die bereitgestellten Informationen helfen jedoch den Filtern, die die empfangende Domain einrichtet. Wenn die E-Mail beispielsweise von einer vertrauenswürdigen Domain stammt und erfolgreich über DKIM verifiziert werden kann, wird die Spam-Bewertung der E-Mail möglicherweise reduziert. Wenn die DKIM-Signatur der E-Mail nicht verifiziert werden kann (weil die E-Mail gefälscht wurde oder aus einem anderen Grund), wird die E-Mail möglicherweise als Spam markiert und entweder in Quarantäne gestellt oder in der Betreffzeile mit einem Spam-Tag versehen (um die Empfänger zu warnen, dass die E-Mail verdächtig ist).

Als Domain-Besitzer müssen Sie wissen, dass Sie keinen Einfluss darauf haben, was in den DMARC-Fehlerbericht aufgenommen wird – das ist Sache des Empfängers. Und wenn es sich bei dem Bericht um einen False Positive handelt (eine E-Mail, die DMARC nicht bestanden hat, aber nicht hätte bestehen dürfen), kann dies bedeuten, dass „echte“ Informationen in den Fehlerbericht aufgenommen werden. Das macht den Fehlerbericht zu einer einfachen Möglichkeit, vertrauliche Unternehmens- oder Kundeninformationen weiterzugeben.