DKIM-Validierung: Eine bewährte Methode zur E-Mail-Authentifizierung
Vogel
08.04.2017
1 min read
Wichtige Erkenntnisse
DKIM (DomainKeys Identified Mail) ist eine inhaltsbasierte E-Mail-Authentifizierungsmethode, die überprüft, ob eine Nachricht nach der Unterzeichnung geändert wurde.
Im Gegensatz zu SPF, das den sendenden Pfad validiert, validiert DKIM den Inhalt der Nachricht selbst mithilfe kryptografischer Signaturen.
DKIM verwendet zwei Schlüssel: einen privaten Schlüssel, um ausgehende Nachrichten zu signieren, und einen öffentlichen Schlüssel, der in DNS veröffentlicht wird, damit Empfänger die Signaturen validieren können.
Eine DKIM-Signatur umfasst Hashes sowohl der Header als auch des Körpers, Selektoren, Zeitstempel und Identitätsfelder – all dies muss der Empfänger reproduzieren und verifizieren.
Die DKIM-Validierung hängt davon ab, dass die gesamte Nachricht zuerst empfangen wird, was bedeutet, dass Fehler spät im Prozess auftreten können.
Die Fehlersuche bei gescheiterten DKIM-Validierungen ist oft schwierig, da Absender und Empfänger einander's Signatur-/Verifikationsumgebungen nicht reproduzieren können.
Sogar wenn DKIM fehlschlägt, verursacht es in der Regel nicht allein Probleme beim Zustellen in das Posteingang, es sei denn, es wird mit anderen negativen Reputationssignalen kombiniert.
Q&A Highlights
Was macht DKIM eigentlich?
DKIM fügt einer E-Mail eine kryptografische Signatur hinzu, die es dem empfangenden Server ermöglicht zu bestätigen, ob der Nachrichteninhalt nach dem Versand verändert wurde.
Wie unterscheidet sich DKIM von SPF?
SPF überprüft wer berechtigt ist, E-Mails für eine Domain zu senden (pfadbasiert).
DKIM überprüft, ob der Inhalt intakt ist (inhaltsbasiert).
Beide dienen unterschiedlichen Zwecken und ergänzen sich gegenseitig.
Was befindet sich in einem DKIM-Signature-Header?
Schlüsselfelder umfassen:
v= Version
a= Algorithmus
c= Kanonische Regeln
d= Signier-Domain
s= Selektor
h= Header in der Signatur enthalten
bh= Körper-Hash
b= tatsächliche Signaturdaten
Jeder Teil trägt dazu bei, wie die Signatur validiert wird.
Wie validiert ein empfangender Server DKIM?
Extrahiert die d= und s= Werte.
Sucht den öffentlichen Schlüssel unter:
selector._domainkey.domain
Regeneriert die Header- und Body-Hashes.
Vergleicht sie mit den bh= und b= Werten in der E-Mail.
Wenn sie übereinstimmen, besteht die Nachricht DKIM.
Was führt dazu, dass DKIM fehlschlägt?
Nachricht während der Übertragung verändert (sogar Leerraumänderungen, wenn strikte Kanonisierung verwendet wird)
Falscher oder fehlender öffentlicher Schlüssel im DNS
DNS-Formatierungsfehler
Selektor falsch entfernt oder gedreht
Nicht übereinstimmende Identitäten (i= muss dieselbe Domain oder Subdomain von d= sein)
Warum können DKIM-Fehler schwer zu beheben sein?
Da der Unterzeichner und der Validator in völlig unterschiedlichen Umgebungen arbeiten – keine der Seiten kann die Hash-Bedingungen oder den Signaturzustand der anderen rekonstruieren.
Das macht undurchsichtige „Hash-Mismatch“-Fehler am frustrierendsten zu diagnostizieren.
Bedeutet ein DKIM-Fehler, dass die E-Mail im Spam landet?
Nicht unbedingt.
DKIM ist nur ein Signal. Wenn die Domain einen starken Ruf hat und andere Prüfungen besteht (SPF, DMARC-Ausrichtung, niedrige Beschwerderaten), wirken sich isolierte DKIM-Fehler typischerweise nicht alleine auf das Einsortieren in die Inbox aus.
Warum überhaupt DKIM verwenden?
Schützt die Integrität der Nachricht
Baut die Domain-Reputation auf
Ermöglicht die DMARC-Ausrichtung
Hilft Mailbox-Anbietern, legitime Absender von Spoofern zu unterscheiden
DKIM wird als bewährte Methode für alle ernsthaften E-Mail-Absender betrachtet.
Wenn wir von „Email-Authentifizierung“ sprechen, beziehen wir uns auf eine Technik, die dem Empfänger einer Nachricht ein gewisses Maß an Gewissheit bietet, dass die Nachricht tatsächlich vom angegebenen Absender stammt. Die Idee hinter solchen Techniken ist es, ein gewisses Maß an Schutz gegen betrügerische E-Mails zu erreichen, wie sie beim Phishing oder Spoofing auftreten können – E-Mails, die das Vertrauen des Empfängers in den Empfang von E-Mails untergraben könnten. Das Versenden einer authentifizierten E-Mail bedeutet jedoch nicht, dass die E-Mail gut oder erwünscht ist; es bedeutet nur, dass die Mail so ist, dass ein Ruf für die authentifizierte Partei zuverlässig etabliert und in Akzeptanz- und Platzierungsentscheidungen von E-Mails verwendet werden kann.
Heute gibt es zwei Arten der E-Mail-Authentifizierung:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Im heutigen Beitrag erkläre ich, was DKIM ist und wie es funktioniert.
Wenn wir von „Email-Authentifizierung“ sprechen, beziehen wir uns auf eine Technik, die dem Empfänger einer Nachricht ein gewisses Maß an Gewissheit bietet, dass die Nachricht tatsächlich vom angegebenen Absender stammt. Die Idee hinter solchen Techniken ist es, ein gewisses Maß an Schutz gegen betrügerische E-Mails zu erreichen, wie sie beim Phishing oder Spoofing auftreten können – E-Mails, die das Vertrauen des Empfängers in den Empfang von E-Mails untergraben könnten. Das Versenden einer authentifizierten E-Mail bedeutet jedoch nicht, dass die E-Mail gut oder erwünscht ist; es bedeutet nur, dass die Mail so ist, dass ein Ruf für die authentifizierte Partei zuverlässig etabliert und in Akzeptanz- und Platzierungsentscheidungen von E-Mails verwendet werden kann.
Heute gibt es zwei Arten der E-Mail-Authentifizierung:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Im heutigen Beitrag erkläre ich, was DKIM ist und wie es funktioniert.
Wenn wir von „Email-Authentifizierung“ sprechen, beziehen wir uns auf eine Technik, die dem Empfänger einer Nachricht ein gewisses Maß an Gewissheit bietet, dass die Nachricht tatsächlich vom angegebenen Absender stammt. Die Idee hinter solchen Techniken ist es, ein gewisses Maß an Schutz gegen betrügerische E-Mails zu erreichen, wie sie beim Phishing oder Spoofing auftreten können – E-Mails, die das Vertrauen des Empfängers in den Empfang von E-Mails untergraben könnten. Das Versenden einer authentifizierten E-Mail bedeutet jedoch nicht, dass die E-Mail gut oder erwünscht ist; es bedeutet nur, dass die Mail so ist, dass ein Ruf für die authentifizierte Partei zuverlässig etabliert und in Akzeptanz- und Platzierungsentscheidungen von E-Mails verwendet werden kann.
Heute gibt es zwei Arten der E-Mail-Authentifizierung:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Im heutigen Beitrag erkläre ich, was DKIM ist und wie es funktioniert.
DKIM Überblick
Im Gegensatz zu seinem Authentifizierungs-Gegenstück SPF, das einem Domain ermöglicht, einem Host die Berechtigung zum Versenden von E-Mails in ihrem Namen zu erteilen, bietet DKIM eine Möglichkeit für eine Einheit (Domain, Organisation, Person usw.), die Verantwortung für eine Nachricht zu übernehmen, unabhängig von der Entität, die die Nachricht tatsächlich gesendet hat. Während in vielen Fällen die verantwortliche Entität und die sendende Entität dieselbe oder zumindest eng miteinander verbunden sein werden, gibt es bei DKIM keine Anforderung, dass dies so sein muss.
Meine Ziele mit diesem Beitrag sind, dass Sie die folgenden Konzepte über DKIM lernen und verstehen:
DKIM ist eine „inhaltsbasierte“ Authentifizierung, im Gegensatz zur „pfadbasierten“ SPF.
Die verantwortliche Entität erklärt ihre Verantwortung, indem sie die Nachricht mit einem Paar kryptografischer Hashes signiert, die in einen Nachrichtenheader eingefügt werden.
DKIM-Validierung erfolgt durch die empfangende Domain, die versucht, dieselben zwei Hashes zu erzeugen.
DKIM-Validierung kann in vielen Fällen nicht abgeschlossen werden, bis die vollständige Nachricht vom sendenden Server übermittelt wurde.
Fehler bei der Validierung können schwer zu beheben sein.
Im Gegensatz zu seinem Authentifizierungs-Gegenstück SPF, das einem Domain ermöglicht, einem Host die Berechtigung zum Versenden von E-Mails in ihrem Namen zu erteilen, bietet DKIM eine Möglichkeit für eine Einheit (Domain, Organisation, Person usw.), die Verantwortung für eine Nachricht zu übernehmen, unabhängig von der Entität, die die Nachricht tatsächlich gesendet hat. Während in vielen Fällen die verantwortliche Entität und die sendende Entität dieselbe oder zumindest eng miteinander verbunden sein werden, gibt es bei DKIM keine Anforderung, dass dies so sein muss.
Meine Ziele mit diesem Beitrag sind, dass Sie die folgenden Konzepte über DKIM lernen und verstehen:
DKIM ist eine „inhaltsbasierte“ Authentifizierung, im Gegensatz zur „pfadbasierten“ SPF.
Die verantwortliche Entität erklärt ihre Verantwortung, indem sie die Nachricht mit einem Paar kryptografischer Hashes signiert, die in einen Nachrichtenheader eingefügt werden.
DKIM-Validierung erfolgt durch die empfangende Domain, die versucht, dieselben zwei Hashes zu erzeugen.
DKIM-Validierung kann in vielen Fällen nicht abgeschlossen werden, bis die vollständige Nachricht vom sendenden Server übermittelt wurde.
Fehler bei der Validierung können schwer zu beheben sein.
Im Gegensatz zu seinem Authentifizierungs-Gegenstück SPF, das einem Domain ermöglicht, einem Host die Berechtigung zum Versenden von E-Mails in ihrem Namen zu erteilen, bietet DKIM eine Möglichkeit für eine Einheit (Domain, Organisation, Person usw.), die Verantwortung für eine Nachricht zu übernehmen, unabhängig von der Entität, die die Nachricht tatsächlich gesendet hat. Während in vielen Fällen die verantwortliche Entität und die sendende Entität dieselbe oder zumindest eng miteinander verbunden sein werden, gibt es bei DKIM keine Anforderung, dass dies so sein muss.
Meine Ziele mit diesem Beitrag sind, dass Sie die folgenden Konzepte über DKIM lernen und verstehen:
DKIM ist eine „inhaltsbasierte“ Authentifizierung, im Gegensatz zur „pfadbasierten“ SPF.
Die verantwortliche Entität erklärt ihre Verantwortung, indem sie die Nachricht mit einem Paar kryptografischer Hashes signiert, die in einen Nachrichtenheader eingefügt werden.
DKIM-Validierung erfolgt durch die empfangende Domain, die versucht, dieselben zwei Hashes zu erzeugen.
DKIM-Validierung kann in vielen Fällen nicht abgeschlossen werden, bis die vollständige Nachricht vom sendenden Server übermittelt wurde.
Fehler bei der Validierung können schwer zu beheben sein.
“Inhaltsbasierte” Authentication
DKIM wird als "inhaltbasierte" Authentifizierung bezeichnet, anstatt als "pfadbasierte", da die Gültigkeit der DKIM-Validierung nur darauf basiert, ob sich der Inhalt zwischen dem Zeitpunkt der Signierung und dem Zeitpunkt der Validierungsversuche geändert hat oder nicht.
DKIM wird als "inhaltbasierte" Authentifizierung bezeichnet, anstatt als "pfadbasierte", da die Gültigkeit der DKIM-Validierung nur darauf basiert, ob sich der Inhalt zwischen dem Zeitpunkt der Signierung und dem Zeitpunkt der Validierungsversuche geändert hat oder nicht.
DKIM wird als "inhaltbasierte" Authentifizierung bezeichnet, anstatt als "pfadbasierte", da die Gültigkeit der DKIM-Validierung nur darauf basiert, ob sich der Inhalt zwischen dem Zeitpunkt der Signierung und dem Zeitpunkt der Validierungsversuche geändert hat oder nicht.
DKIM Signing und Validation
Organisationen, die Mails mit DKIM signieren möchten, werden zunächst zwei kryptografische Schlüssel erzeugen. Einer der Schlüssel wird privat gehalten und dem sendenden Server für das Signieren von Mails zur Verfügung gestellt, während der andere öffentlich im DNS gemacht wird, um von empfangenden Domains zur Validierung der Signatur verwendet zu werden. Die Methoden zur Erzeugung und Installation dieser Schlüssel sind plattformabhängig und liegen außerhalb des Umfangs dieses Beitrags, obwohl ich später die Veröffentlichung des öffentlichen DKIM-Schlüssels im DNS beschreiben werde.
Organisationen, die Mails mit DKIM signieren möchten, werden zunächst zwei kryptografische Schlüssel erzeugen. Einer der Schlüssel wird privat gehalten und dem sendenden Server für das Signieren von Mails zur Verfügung gestellt, während der andere öffentlich im DNS gemacht wird, um von empfangenden Domains zur Validierung der Signatur verwendet zu werden. Die Methoden zur Erzeugung und Installation dieser Schlüssel sind plattformabhängig und liegen außerhalb des Umfangs dieses Beitrags, obwohl ich später die Veröffentlichung des öffentlichen DKIM-Schlüssels im DNS beschreiben werde.
Organisationen, die Mails mit DKIM signieren möchten, werden zunächst zwei kryptografische Schlüssel erzeugen. Einer der Schlüssel wird privat gehalten und dem sendenden Server für das Signieren von Mails zur Verfügung gestellt, während der andere öffentlich im DNS gemacht wird, um von empfangenden Domains zur Validierung der Signatur verwendet zu werden. Die Methoden zur Erzeugung und Installation dieser Schlüssel sind plattformabhängig und liegen außerhalb des Umfangs dieses Beitrags, obwohl ich später die Veröffentlichung des öffentlichen DKIM-Schlüssels im DNS beschreiben werde.
Der DKIM-Signature Header
Um unser Verständnis von DKIM zu beginnen, schauen wir uns zuerst einen DKIM-Signature-Header an:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Der DKIM-Signature-Header ist eine Reihe von Schlüssel-Wert-Paaren, von denen einige für den Leser interessanter sind als andere, aber ich werde hier alle beschreiben.
Zuerst schauen wir uns die an, die für den Leser größtenteils von vorübergehendem Interesse sind:
v=1; – Gibt die DKIM-Version an (1 ist der einzige gültige Wert)
a=rsa-sha256; – Der Algorithmus, der zur Erstellung der kryptografischen Hashes verwendet wird
c=relaxed/relaxed; – Es gibt zwei Regelwerke bezüglich der Entfernung von Leerzeichen in den Headern und im Body, die beim Erstellen der Hashes in einer DKIM-Signatur angewendet werden können; diese Regeln werden „Kanonisierungsregeln“ genannt (daher der Schlüssel c) und die Regelwerke sind entweder „entspannt“ oder „streng“.
t=1454417737; – Der Zeitstempel, wann die Signatur erstellt wurde.
Diese drei Header-Teile enthalten die eigentlichen Signaturinformationen:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dies ist der Hash des Nachrichtentextes.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dies ist eine Liste der Header, die verwendet wurden, um die unten gezeigten Signaturdaten zu erstellen.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dies sind die eigentlichen DKIM-Signaturdaten
Diese drei Teile sind für den empfangenden Server von größtem Interesse, der die Signatur validiert:
d=welcome.foo.com; – Dies identifiziert die Domain, die die Nachricht signiert hat
s=notices; – Der Selector; Domains können mehrere Selektoren haben, die sie beim Signieren von Nachrichten verwenden.
i=@welcome.foo.com; – Dies ist die Identität, in deren Namen die Nachricht signiert wurde. Syntaktisch wird dies wie eine E-Mail-Adresse aussehen und könnte sogar eine sein; der lokale Teil der E-Mail-Adresse kann leer sein, wie in diesem Beispiel, und der Domänenteil muss derselbe sein wie oder eine Subdomain der Domain im Teil „d=“ der Signatur.
Der Grund, warum diese Teile für den empfangenden Server von Interesse sind, ist, dass sie die notwendigen Informationen liefern, um dem Empfänger zu helfen, die Signaturen zu validieren.
Um unser Verständnis von DKIM zu beginnen, schauen wir uns zuerst einen DKIM-Signature-Header an:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Der DKIM-Signature-Header ist eine Reihe von Schlüssel-Wert-Paaren, von denen einige für den Leser interessanter sind als andere, aber ich werde hier alle beschreiben.
Zuerst schauen wir uns die an, die für den Leser größtenteils von vorübergehendem Interesse sind:
v=1; – Gibt die DKIM-Version an (1 ist der einzige gültige Wert)
a=rsa-sha256; – Der Algorithmus, der zur Erstellung der kryptografischen Hashes verwendet wird
c=relaxed/relaxed; – Es gibt zwei Regelwerke bezüglich der Entfernung von Leerzeichen in den Headern und im Body, die beim Erstellen der Hashes in einer DKIM-Signatur angewendet werden können; diese Regeln werden „Kanonisierungsregeln“ genannt (daher der Schlüssel c) und die Regelwerke sind entweder „entspannt“ oder „streng“.
t=1454417737; – Der Zeitstempel, wann die Signatur erstellt wurde.
Diese drei Header-Teile enthalten die eigentlichen Signaturinformationen:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dies ist der Hash des Nachrichtentextes.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dies ist eine Liste der Header, die verwendet wurden, um die unten gezeigten Signaturdaten zu erstellen.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dies sind die eigentlichen DKIM-Signaturdaten
Diese drei Teile sind für den empfangenden Server von größtem Interesse, der die Signatur validiert:
d=welcome.foo.com; – Dies identifiziert die Domain, die die Nachricht signiert hat
s=notices; – Der Selector; Domains können mehrere Selektoren haben, die sie beim Signieren von Nachrichten verwenden.
i=@welcome.foo.com; – Dies ist die Identität, in deren Namen die Nachricht signiert wurde. Syntaktisch wird dies wie eine E-Mail-Adresse aussehen und könnte sogar eine sein; der lokale Teil der E-Mail-Adresse kann leer sein, wie in diesem Beispiel, und der Domänenteil muss derselbe sein wie oder eine Subdomain der Domain im Teil „d=“ der Signatur.
Der Grund, warum diese Teile für den empfangenden Server von Interesse sind, ist, dass sie die notwendigen Informationen liefern, um dem Empfänger zu helfen, die Signaturen zu validieren.
Um unser Verständnis von DKIM zu beginnen, schauen wir uns zuerst einen DKIM-Signature-Header an:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Der DKIM-Signature-Header ist eine Reihe von Schlüssel-Wert-Paaren, von denen einige für den Leser interessanter sind als andere, aber ich werde hier alle beschreiben.
Zuerst schauen wir uns die an, die für den Leser größtenteils von vorübergehendem Interesse sind:
v=1; – Gibt die DKIM-Version an (1 ist der einzige gültige Wert)
a=rsa-sha256; – Der Algorithmus, der zur Erstellung der kryptografischen Hashes verwendet wird
c=relaxed/relaxed; – Es gibt zwei Regelwerke bezüglich der Entfernung von Leerzeichen in den Headern und im Body, die beim Erstellen der Hashes in einer DKIM-Signatur angewendet werden können; diese Regeln werden „Kanonisierungsregeln“ genannt (daher der Schlüssel c) und die Regelwerke sind entweder „entspannt“ oder „streng“.
t=1454417737; – Der Zeitstempel, wann die Signatur erstellt wurde.
Diese drei Header-Teile enthalten die eigentlichen Signaturinformationen:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dies ist der Hash des Nachrichtentextes.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dies ist eine Liste der Header, die verwendet wurden, um die unten gezeigten Signaturdaten zu erstellen.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dies sind die eigentlichen DKIM-Signaturdaten
Diese drei Teile sind für den empfangenden Server von größtem Interesse, der die Signatur validiert:
d=welcome.foo.com; – Dies identifiziert die Domain, die die Nachricht signiert hat
s=notices; – Der Selector; Domains können mehrere Selektoren haben, die sie beim Signieren von Nachrichten verwenden.
i=@welcome.foo.com; – Dies ist die Identität, in deren Namen die Nachricht signiert wurde. Syntaktisch wird dies wie eine E-Mail-Adresse aussehen und könnte sogar eine sein; der lokale Teil der E-Mail-Adresse kann leer sein, wie in diesem Beispiel, und der Domänenteil muss derselbe sein wie oder eine Subdomain der Domain im Teil „d=“ der Signatur.
Der Grund, warum diese Teile für den empfangenden Server von Interesse sind, ist, dass sie die notwendigen Informationen liefern, um dem Empfänger zu helfen, die Signaturen zu validieren.
DKIM Validation
Neben der Anforderung, dass die i= Domain die gleiche oder eine Sub-Domain der d= Domain sein muss, werden die d= und s= Bits vom Validator verwendet, um den öffentlichen DKIM-Schlüssel des Unterzeichners im DNS nachzuschlagen. Der Schlüssel ist ein TXT-Eintrag im DNS und befindet sich immer an der Stelle selector._domainkey.domain. In unserem Beispiel hier, mit s=notices und d=welcome.foo.com, würde der öffentliche DKIM-Schlüssel im DNS unter notices._domainkey.welcome.foo.com gefunden werden, und er könnte ungefähr so aussehen:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Der Validator verwendet diesen Schlüssel (die p= Bits), um seine eigenen Hashes der Nachricht zu erstellen; wenn diese Hashes übereinstimmen, dann wurde die Nachricht nicht während der Übertragung verändert, und so kann die Nachricht zu der Reputation beitragen, die für den Unterzeichner der Nachricht besteht und möglicherweise davon profitieren.
Neben der Anforderung, dass die i= Domain die gleiche oder eine Sub-Domain der d= Domain sein muss, werden die d= und s= Bits vom Validator verwendet, um den öffentlichen DKIM-Schlüssel des Unterzeichners im DNS nachzuschlagen. Der Schlüssel ist ein TXT-Eintrag im DNS und befindet sich immer an der Stelle selector._domainkey.domain. In unserem Beispiel hier, mit s=notices und d=welcome.foo.com, würde der öffentliche DKIM-Schlüssel im DNS unter notices._domainkey.welcome.foo.com gefunden werden, und er könnte ungefähr so aussehen:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Der Validator verwendet diesen Schlüssel (die p= Bits), um seine eigenen Hashes der Nachricht zu erstellen; wenn diese Hashes übereinstimmen, dann wurde die Nachricht nicht während der Übertragung verändert, und so kann die Nachricht zu der Reputation beitragen, die für den Unterzeichner der Nachricht besteht und möglicherweise davon profitieren.
Neben der Anforderung, dass die i= Domain die gleiche oder eine Sub-Domain der d= Domain sein muss, werden die d= und s= Bits vom Validator verwendet, um den öffentlichen DKIM-Schlüssel des Unterzeichners im DNS nachzuschlagen. Der Schlüssel ist ein TXT-Eintrag im DNS und befindet sich immer an der Stelle selector._domainkey.domain. In unserem Beispiel hier, mit s=notices und d=welcome.foo.com, würde der öffentliche DKIM-Schlüssel im DNS unter notices._domainkey.welcome.foo.com gefunden werden, und er könnte ungefähr so aussehen:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Der Validator verwendet diesen Schlüssel (die p= Bits), um seine eigenen Hashes der Nachricht zu erstellen; wenn diese Hashes übereinstimmen, dann wurde die Nachricht nicht während der Übertragung verändert, und so kann die Nachricht zu der Reputation beitragen, die für den Unterzeichner der Nachricht besteht und möglicherweise davon profitieren.
Validierungsfehler und Fehlersuche
Ich habe oben erwähnt, dass DKIM-Fehler schwierig zu beheben sein können, und ich werde hier erklären, warum das so ist.
Einige DKIM-Validierungsfehler haben offensichtliche Ursachen, wie zum Beispiel, dass die Nachricht nicht signiert wurde, oder der öffentliche Schlüssel der signierenden Domain nicht im DNS gefunden wurde oder syntaktisch nicht korrekt ist, oder vielleicht wurde die Nachricht offensichtlich während der Übertragung verändert. Wenn solche Fehler auftreten, ist es leicht, das Problem zu erkennen und eine Lösung zu empfehlen. Die schwierigen Fälle jedoch, und diejenigen, die zu den frustrierendsten Supporterfahrungen führen, sind die Fälle, in denen die Nachricht signiert wurde, der öffentliche Schlüssel im DNS vorhanden ist und die Nachricht nicht offensichtlich verändert wurde, aber der Validator berichtet, dass die Signatur nicht validiert werden konnte.
Der Grund, warum diese schwer zu beheben sind, liegt darin, dass es keine wirkliche Möglichkeit für beide Seiten gibt, die Bedingungen nachzustellen, unter denen die Nachricht signiert und validiert wurde. Die Nachricht enthält im DKIM-Signatur-Header die Hashes, die vom Unterzeichner zum Zeitpunkt der Signierung generiert wurden, aber der Validator hat wahrscheinlich keinen Zugang zur Infrastruktur des Unterzeichners und kann daher nicht versuchen, die Signatur unter den Bedingungen des Unterzeichners zu reproduzieren. Ebenso hat der Unterzeichner wahrscheinlich keinen Zugang zur Infrastruktur des Validators und kann daher nicht versuchen, die Nachricht auf die gleiche Weise zu validieren wie der Validator.
Fehler wie die, die ich hier beschreibe, sind seltene Vorkommen, und DKIM-Validierungsfehler allein haben normalerweise keinen Einfluss auf die Zustellungsplatzierung. Während DKIM die Nachrichtenauthentifizierung übernimmt, stellt die Implementierung umfassender E-Mail-Validierungstechniken sicher, dass Sie an legitime Adressen senden, die Ihre Nachrichten tatsächlich empfangen und authentifizieren können. Aus meiner Erfahrung treiben solche Fehler mehr Supporttickets als jede andere Art von DKIM-Problemen.
Ich habe oben erwähnt, dass DKIM-Fehler schwierig zu beheben sein können, und ich werde hier erklären, warum das so ist.
Einige DKIM-Validierungsfehler haben offensichtliche Ursachen, wie zum Beispiel, dass die Nachricht nicht signiert wurde, oder der öffentliche Schlüssel der signierenden Domain nicht im DNS gefunden wurde oder syntaktisch nicht korrekt ist, oder vielleicht wurde die Nachricht offensichtlich während der Übertragung verändert. Wenn solche Fehler auftreten, ist es leicht, das Problem zu erkennen und eine Lösung zu empfehlen. Die schwierigen Fälle jedoch, und diejenigen, die zu den frustrierendsten Supporterfahrungen führen, sind die Fälle, in denen die Nachricht signiert wurde, der öffentliche Schlüssel im DNS vorhanden ist und die Nachricht nicht offensichtlich verändert wurde, aber der Validator berichtet, dass die Signatur nicht validiert werden konnte.
Der Grund, warum diese schwer zu beheben sind, liegt darin, dass es keine wirkliche Möglichkeit für beide Seiten gibt, die Bedingungen nachzustellen, unter denen die Nachricht signiert und validiert wurde. Die Nachricht enthält im DKIM-Signatur-Header die Hashes, die vom Unterzeichner zum Zeitpunkt der Signierung generiert wurden, aber der Validator hat wahrscheinlich keinen Zugang zur Infrastruktur des Unterzeichners und kann daher nicht versuchen, die Signatur unter den Bedingungen des Unterzeichners zu reproduzieren. Ebenso hat der Unterzeichner wahrscheinlich keinen Zugang zur Infrastruktur des Validators und kann daher nicht versuchen, die Nachricht auf die gleiche Weise zu validieren wie der Validator.
Fehler wie die, die ich hier beschreibe, sind seltene Vorkommen, und DKIM-Validierungsfehler allein haben normalerweise keinen Einfluss auf die Zustellungsplatzierung. Während DKIM die Nachrichtenauthentifizierung übernimmt, stellt die Implementierung umfassender E-Mail-Validierungstechniken sicher, dass Sie an legitime Adressen senden, die Ihre Nachrichten tatsächlich empfangen und authentifizieren können. Aus meiner Erfahrung treiben solche Fehler mehr Supporttickets als jede andere Art von DKIM-Problemen.
Ich habe oben erwähnt, dass DKIM-Fehler schwierig zu beheben sein können, und ich werde hier erklären, warum das so ist.
Einige DKIM-Validierungsfehler haben offensichtliche Ursachen, wie zum Beispiel, dass die Nachricht nicht signiert wurde, oder der öffentliche Schlüssel der signierenden Domain nicht im DNS gefunden wurde oder syntaktisch nicht korrekt ist, oder vielleicht wurde die Nachricht offensichtlich während der Übertragung verändert. Wenn solche Fehler auftreten, ist es leicht, das Problem zu erkennen und eine Lösung zu empfehlen. Die schwierigen Fälle jedoch, und diejenigen, die zu den frustrierendsten Supporterfahrungen führen, sind die Fälle, in denen die Nachricht signiert wurde, der öffentliche Schlüssel im DNS vorhanden ist und die Nachricht nicht offensichtlich verändert wurde, aber der Validator berichtet, dass die Signatur nicht validiert werden konnte.
Der Grund, warum diese schwer zu beheben sind, liegt darin, dass es keine wirkliche Möglichkeit für beide Seiten gibt, die Bedingungen nachzustellen, unter denen die Nachricht signiert und validiert wurde. Die Nachricht enthält im DKIM-Signatur-Header die Hashes, die vom Unterzeichner zum Zeitpunkt der Signierung generiert wurden, aber der Validator hat wahrscheinlich keinen Zugang zur Infrastruktur des Unterzeichners und kann daher nicht versuchen, die Signatur unter den Bedingungen des Unterzeichners zu reproduzieren. Ebenso hat der Unterzeichner wahrscheinlich keinen Zugang zur Infrastruktur des Validators und kann daher nicht versuchen, die Nachricht auf die gleiche Weise zu validieren wie der Validator.
Fehler wie die, die ich hier beschreibe, sind seltene Vorkommen, und DKIM-Validierungsfehler allein haben normalerweise keinen Einfluss auf die Zustellungsplatzierung. Während DKIM die Nachrichtenauthentifizierung übernimmt, stellt die Implementierung umfassender E-Mail-Validierungstechniken sicher, dass Sie an legitime Adressen senden, die Ihre Nachrichten tatsächlich empfangen und authentifizieren können. Aus meiner Erfahrung treiben solche Fehler mehr Supporttickets als jede andere Art von DKIM-Problemen.
