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 Übersicht
Im Gegensatz zu seinem Authentifizierungsgegenstück SPF, das eine Möglichkeit bietet, einer Domäne zu autorisieren, einen Host im Namen der Domäne E-Mails zu senden, bietet DKIM eine Möglichkeit für eine Entität (Domäne, 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 identisch oder zumindest eng miteinander verbunden sein werden, gibt es bei DKIM keine Anforderung, dass dies so sein muss.
Meine Ziele für Sie 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 durch „Signieren“ der Nachricht mit einem Paar kryptografischer Hashes, die in einen Nachrichtenkopf eingefügt werden.
Die DKIM-Validierung wird von der empfangenden Domäne durchgeführt, die versucht, die gleichen zwei Hashes zu erzeugen.
Die DKIM-Validierung kann in vielen Fällen nicht abgeschlossen werden, bis die vollständige Nachricht vom sendenden Server übertragen wurde.
Validierungsfehler können schwierig zu beheben sein.
Im Gegensatz zu seinem Authentifizierungsgegenstück SPF, das eine Möglichkeit bietet, einer Domäne zu autorisieren, einen Host im Namen der Domäne E-Mails zu senden, bietet DKIM eine Möglichkeit für eine Entität (Domäne, 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 identisch oder zumindest eng miteinander verbunden sein werden, gibt es bei DKIM keine Anforderung, dass dies so sein muss.
Meine Ziele für Sie 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 durch „Signieren“ der Nachricht mit einem Paar kryptografischer Hashes, die in einen Nachrichtenkopf eingefügt werden.
Die DKIM-Validierung wird von der empfangenden Domäne durchgeführt, die versucht, die gleichen zwei Hashes zu erzeugen.
Die DKIM-Validierung kann in vielen Fällen nicht abgeschlossen werden, bis die vollständige Nachricht vom sendenden Server übertragen wurde.
Validierungsfehler können schwierig zu beheben sein.
Im Gegensatz zu seinem Authentifizierungsgegenstück SPF, das eine Möglichkeit bietet, einer Domäne zu autorisieren, einen Host im Namen der Domäne E-Mails zu senden, bietet DKIM eine Möglichkeit für eine Entität (Domäne, 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 identisch oder zumindest eng miteinander verbunden sein werden, gibt es bei DKIM keine Anforderung, dass dies so sein muss.
Meine Ziele für Sie 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 durch „Signieren“ der Nachricht mit einem Paar kryptografischer Hashes, die in einen Nachrichtenkopf eingefügt werden.
Die DKIM-Validierung wird von der empfangenden Domäne durchgeführt, die versucht, die gleichen zwei Hashes zu erzeugen.
Die DKIM-Validierung kann in vielen Fällen nicht abgeschlossen werden, bis die vollständige Nachricht vom sendenden Server übertragen wurde.
Validierungsfehler können schwierig zu beheben sein.
“Content-Based” Authentifizierung
DKIM wird als „inhaltsbasierte“ Authentifizierung bezeichnet, im Gegensatz zu „pfadbasiert“, da das Bestehen der DKIM-Validierung ausschließlich darauf beruht, ob sich der Inhalt zwischen dem Zeitpunkt der Signierung und dem Zeitpunkt der Validierung geändert hat.
DKIM wird als „inhaltsbasierte“ Authentifizierung bezeichnet, im Gegensatz zu „pfadbasiert“, da das Bestehen der DKIM-Validierung ausschließlich darauf beruht, ob sich der Inhalt zwischen dem Zeitpunkt der Signierung und dem Zeitpunkt der Validierung geändert hat.
DKIM wird als „inhaltsbasierte“ Authentifizierung bezeichnet, im Gegensatz zu „pfadbasiert“, da das Bestehen der DKIM-Validierung ausschließlich darauf beruht, ob sich der Inhalt zwischen dem Zeitpunkt der Signierung und dem Zeitpunkt der Validierung geändert hat.
DKIM-Signierung und Validierung
Organisationen, die E-Mails mit DKIM signieren möchten, erstellen zunächst zwei kryptografische Schlüssel. Einer der Schlüssel wird privat gehalten und ist dem sendenden Server zum Signieren von E-Mails zugänglich, und der andere soll im DNS öffentlich gemacht werden, damit empfangende Domains versuchen können, die Signatur zu validieren. Die Methoden zur Erstellung und Installation dieser Schlüssel sind plattformabhängig und liegen außerhalb des Rahmens dieses Beitrags. Später werde ich jedoch die Veröffentlichung des öffentlichen DKIM-Schlüssels im DNS beschreiben.
Organisationen, die E-Mails mit DKIM signieren möchten, erstellen zunächst zwei kryptografische Schlüssel. Einer der Schlüssel wird privat gehalten und ist dem sendenden Server zum Signieren von E-Mails zugänglich, und der andere soll im DNS öffentlich gemacht werden, damit empfangende Domains versuchen können, die Signatur zu validieren. Die Methoden zur Erstellung und Installation dieser Schlüssel sind plattformabhängig und liegen außerhalb des Rahmens dieses Beitrags. Später werde ich jedoch die Veröffentlichung des öffentlichen DKIM-Schlüssels im DNS beschreiben.
Organisationen, die E-Mails mit DKIM signieren möchten, erstellen zunächst zwei kryptografische Schlüssel. Einer der Schlüssel wird privat gehalten und ist dem sendenden Server zum Signieren von E-Mails zugänglich, und der andere soll im DNS öffentlich gemacht werden, damit empfangende Domains versuchen können, die Signatur zu validieren. Die Methoden zur Erstellung und Installation dieser Schlüssel sind plattformabhängig und liegen außerhalb des Rahmens dieses Beitrags. Später werde ich jedoch die Veröffentlichung des öffentlichen DKIM-Schlüssels im DNS beschreiben.
Der DKIM-Signature Header
Um unser Verständnis von DKIM zu beginnen, schauen wir uns zunächst einen DKIM-Signaturheader 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-Signaturheader ist eine Reihe von Schlüssel-Wert-Paaren, von denen einige für den Leser von mehr Interesse sind als andere, aber ich werde sie hier alle beschreiben.
Erstens schauen wir uns die an, die meist von geringem Interesse für den Leser 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 Sätze von Regeln bezüglich der Entfernung von Leerzeichen in den Headers und im Textkörper, die beim Erstellen der Hashes in einer DKIM-Signatur angewendet werden können; diese Regeln werden als „Kanonisierungsregeln“ bezeichnet (daher der Schlüssel c) und die Regelwerke sind entweder „relaxed“ oder „strict“.
t=1454417737; – Der Zeitstempel, wann die Signatur erstellt wurde.
Diese drei Headerteile enthalten die tatsächlichen Signaturinformationen:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dies ist der Hash des Nachrichtentexts.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dies ist eine Liste der Headers, 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 von größtem Interesse für den empfangenden Server, der die Signatur validieren wird:
d=welcome.foo.com; – Dies identifiziert die Domain, die die Nachricht signiert hat
s=notices; – Der Selector; Domains können mehrere Selector 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 sieht das aus wie eine E-Mail-Adresse und könnte sogar eine sein; der lokale Teil der E-Mail-Adresse kann leer sein, wie in diesem Beispiel, und der Domain-Teil muss mit der Domain im d= Teil der Signatur übereinstimmen oder ein Subdomain dieser sein.
Der Grund, warum diese Teile für den empfangenden Server von Interesse sind, ist, dass sie die notwendigen Informationen bereitstellen, um dem Empfänger bei der Validierung der Signaturen zu helfen.
Feld | Bedeutung | Wie es die Empfänger verwenden |
|---|---|---|
v= | DKIM-Version (immer 1) | Bestätigt das Signaturformat |
a= | Hashing- + Signaturalgorithmus (z.B. rsa-sha256) | Stellt sicher, dass der Validator die Signatur korrekt reproduziert |
c= | Kanonisierungsregeln (Header/Body) | Normalisiert Leerzeichen vor dem Hashing |
t= | Zeitstempel der Signaturerstellung | Wird für Frischeprüfungen und zur Verhinderung von Wiederholungen verwendet |
bh= | Körperhash | Der Empfänger generiert dies neu, um die Integrität des Nachrichtentextes zu bestätigen |
h= | Liste der signierten Kopfzeilenfelder | Stellt sicher, dass die bei der Signierung verwendeten Headers verfügbar und unverändert sind |
b= | Eigentliche DKIM-Signatur | Der Empfänger verifiziert diese Signatur gegen den öffentlichen Schlüssel |
d= | Signierdomain | Wird verwendet, um den DNS-öffentlichen Schlüssel des Signierenden zu finden |
s= | Selector | Kombiniert mit der Domain, um zu bilden: selector._domainkey.domain |
i= | Signaturidentität | Muss gleich oder Subdomain von d= sein, identifiziert die signierende Einheit |
Um unser Verständnis von DKIM zu beginnen, schauen wir uns zunächst einen DKIM-Signaturheader 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-Signaturheader ist eine Reihe von Schlüssel-Wert-Paaren, von denen einige für den Leser von mehr Interesse sind als andere, aber ich werde sie hier alle beschreiben.
Erstens schauen wir uns die an, die meist von geringem Interesse für den Leser 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 Sätze von Regeln bezüglich der Entfernung von Leerzeichen in den Headers und im Textkörper, die beim Erstellen der Hashes in einer DKIM-Signatur angewendet werden können; diese Regeln werden als „Kanonisierungsregeln“ bezeichnet (daher der Schlüssel c) und die Regelwerke sind entweder „relaxed“ oder „strict“.
t=1454417737; – Der Zeitstempel, wann die Signatur erstellt wurde.
Diese drei Headerteile enthalten die tatsächlichen Signaturinformationen:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dies ist der Hash des Nachrichtentexts.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dies ist eine Liste der Headers, 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 von größtem Interesse für den empfangenden Server, der die Signatur validieren wird:
d=welcome.foo.com; – Dies identifiziert die Domain, die die Nachricht signiert hat
s=notices; – Der Selector; Domains können mehrere Selector 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 sieht das aus wie eine E-Mail-Adresse und könnte sogar eine sein; der lokale Teil der E-Mail-Adresse kann leer sein, wie in diesem Beispiel, und der Domain-Teil muss mit der Domain im d= Teil der Signatur übereinstimmen oder ein Subdomain dieser sein.
Der Grund, warum diese Teile für den empfangenden Server von Interesse sind, ist, dass sie die notwendigen Informationen bereitstellen, um dem Empfänger bei der Validierung der Signaturen zu helfen.
Feld | Bedeutung | Wie es die Empfänger verwenden |
|---|---|---|
v= | DKIM-Version (immer 1) | Bestätigt das Signaturformat |
a= | Hashing- + Signaturalgorithmus (z.B. rsa-sha256) | Stellt sicher, dass der Validator die Signatur korrekt reproduziert |
c= | Kanonisierungsregeln (Header/Body) | Normalisiert Leerzeichen vor dem Hashing |
t= | Zeitstempel der Signaturerstellung | Wird für Frischeprüfungen und zur Verhinderung von Wiederholungen verwendet |
bh= | Körperhash | Der Empfänger generiert dies neu, um die Integrität des Nachrichtentextes zu bestätigen |
h= | Liste der signierten Kopfzeilenfelder | Stellt sicher, dass die bei der Signierung verwendeten Headers verfügbar und unverändert sind |
b= | Eigentliche DKIM-Signatur | Der Empfänger verifiziert diese Signatur gegen den öffentlichen Schlüssel |
d= | Signierdomain | Wird verwendet, um den DNS-öffentlichen Schlüssel des Signierenden zu finden |
s= | Selector | Kombiniert mit der Domain, um zu bilden: selector._domainkey.domain |
i= | Signaturidentität | Muss gleich oder Subdomain von d= sein, identifiziert die signierende Einheit |
Um unser Verständnis von DKIM zu beginnen, schauen wir uns zunächst einen DKIM-Signaturheader 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-Signaturheader ist eine Reihe von Schlüssel-Wert-Paaren, von denen einige für den Leser von mehr Interesse sind als andere, aber ich werde sie hier alle beschreiben.
Erstens schauen wir uns die an, die meist von geringem Interesse für den Leser 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 Sätze von Regeln bezüglich der Entfernung von Leerzeichen in den Headers und im Textkörper, die beim Erstellen der Hashes in einer DKIM-Signatur angewendet werden können; diese Regeln werden als „Kanonisierungsregeln“ bezeichnet (daher der Schlüssel c) und die Regelwerke sind entweder „relaxed“ oder „strict“.
t=1454417737; – Der Zeitstempel, wann die Signatur erstellt wurde.
Diese drei Headerteile enthalten die tatsächlichen Signaturinformationen:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dies ist der Hash des Nachrichtentexts.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dies ist eine Liste der Headers, 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 von größtem Interesse für den empfangenden Server, der die Signatur validieren wird:
d=welcome.foo.com; – Dies identifiziert die Domain, die die Nachricht signiert hat
s=notices; – Der Selector; Domains können mehrere Selector 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 sieht das aus wie eine E-Mail-Adresse und könnte sogar eine sein; der lokale Teil der E-Mail-Adresse kann leer sein, wie in diesem Beispiel, und der Domain-Teil muss mit der Domain im d= Teil der Signatur übereinstimmen oder ein Subdomain dieser sein.
Der Grund, warum diese Teile für den empfangenden Server von Interesse sind, ist, dass sie die notwendigen Informationen bereitstellen, um dem Empfänger bei der Validierung der Signaturen zu helfen.
Feld | Bedeutung | Wie es die Empfänger verwenden |
|---|---|---|
v= | DKIM-Version (immer 1) | Bestätigt das Signaturformat |
a= | Hashing- + Signaturalgorithmus (z.B. rsa-sha256) | Stellt sicher, dass der Validator die Signatur korrekt reproduziert |
c= | Kanonisierungsregeln (Header/Body) | Normalisiert Leerzeichen vor dem Hashing |
t= | Zeitstempel der Signaturerstellung | Wird für Frischeprüfungen und zur Verhinderung von Wiederholungen verwendet |
bh= | Körperhash | Der Empfänger generiert dies neu, um die Integrität des Nachrichtentextes zu bestätigen |
h= | Liste der signierten Kopfzeilenfelder | Stellt sicher, dass die bei der Signierung verwendeten Headers verfügbar und unverändert sind |
b= | Eigentliche DKIM-Signatur | Der Empfänger verifiziert diese Signatur gegen den öffentlichen Schlüssel |
d= | Signierdomain | Wird verwendet, um den DNS-öffentlichen Schlüssel des Signierenden zu finden |
s= | Selector | Kombiniert mit der Domain, um zu bilden: selector._domainkey.domain |
i= | Signaturidentität | Muss gleich oder Subdomain von d= sein, identifiziert die signierende Einheit |
DKIM-Validierung
Zusätzlich zu der genannten Anforderung, dass die i= Domain dieselbe sein muss wie oder eine Subdomain der d= Domain, 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 etwa 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 eigene Menge an Hashes der Nachricht zu erzeugen; wenn diese Hashes übereinstimmen, wurde die Nachricht während der Übertragung nicht geändert und kann daher zum Ruf des Unterzeichners der Nachricht beitragen und möglicherweise davon profitieren.
Zusätzlich zu der genannten Anforderung, dass die i= Domain dieselbe sein muss wie oder eine Subdomain der d= Domain, 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 etwa 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 eigene Menge an Hashes der Nachricht zu erzeugen; wenn diese Hashes übereinstimmen, wurde die Nachricht während der Übertragung nicht geändert und kann daher zum Ruf des Unterzeichners der Nachricht beitragen und möglicherweise davon profitieren.
Zusätzlich zu der genannten Anforderung, dass die i= Domain dieselbe sein muss wie oder eine Subdomain der d= Domain, 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 etwa 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 eigene Menge an Hashes der Nachricht zu erzeugen; wenn diese Hashes übereinstimmen, wurde die Nachricht während der Übertragung nicht geändert und kann daher zum Ruf des Unterzeichners der Nachricht beitragen und möglicherweise davon profitieren.
Validierungsfehler und Fehlerbehebung
Ich habe oben erwähnt, dass DKIM-Fehler schwer 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 ist, oder der öffentliche Schlüssel der signierenden Domäne nicht im DNS gefunden wird oder syntaktisch nicht korrekt ist, oder vielleicht wurde die Nachricht offensichtlich während des Transits verändert. Wenn solche Arten von Fehlern auftreten, ist es einfach, das Problem herauszufinden und eine Lösung zu empfehlen. Die schwierigen Fälle jedoch, und diejenigen, die zu den frustrierendsten Support-Erfahrungen führen, sind die Fälle, in denen die Nachricht signiert wurde, der öffentliche Schlüssel im DNS existiert und die Nachricht nicht offensichtlich verändert wurde, aber der Validator meldet, 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 zu reproduzieren, unter denen die Nachricht signiert und validiert wurde. Die Nachricht hat in ihrem DKIM-Signatur-Header die Hashes, die der Unterzeichner zum Zeitpunkt der Signaturerstellung generiert hat, 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 hat daher keine Möglichkeit, die Nachricht auf dieselbe Weise zu validieren, wie es der Validator getan hat.
Fehler wie die, die ich hier beschreibe, sind seltene Vorkommnisse, und DKIM-Validierungsfehler allein haben in der Regel keine Auswirkungen auf die Zustellplatzierung. Während DKIM die Nachrichtenauthentifizierung handhabt, sichert die Implementierung umfassender E-Mail-Validierungstechniken, dass Sie an legitime Adressen senden, die tatsächlich empfangen und Ihre Nachrichten authentifizieren können. Meiner Erfahrung nach verursachen solche Fehler mehr Support-Tickets als jede andere Art von DKIM-Problemen.
Ich habe oben erwähnt, dass DKIM-Fehler schwer 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 ist, oder der öffentliche Schlüssel der signierenden Domäne nicht im DNS gefunden wird oder syntaktisch nicht korrekt ist, oder vielleicht wurde die Nachricht offensichtlich während des Transits verändert. Wenn solche Arten von Fehlern auftreten, ist es einfach, das Problem herauszufinden und eine Lösung zu empfehlen. Die schwierigen Fälle jedoch, und diejenigen, die zu den frustrierendsten Support-Erfahrungen führen, sind die Fälle, in denen die Nachricht signiert wurde, der öffentliche Schlüssel im DNS existiert und die Nachricht nicht offensichtlich verändert wurde, aber der Validator meldet, 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 zu reproduzieren, unter denen die Nachricht signiert und validiert wurde. Die Nachricht hat in ihrem DKIM-Signatur-Header die Hashes, die der Unterzeichner zum Zeitpunkt der Signaturerstellung generiert hat, 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 hat daher keine Möglichkeit, die Nachricht auf dieselbe Weise zu validieren, wie es der Validator getan hat.
Fehler wie die, die ich hier beschreibe, sind seltene Vorkommnisse, und DKIM-Validierungsfehler allein haben in der Regel keine Auswirkungen auf die Zustellplatzierung. Während DKIM die Nachrichtenauthentifizierung handhabt, sichert die Implementierung umfassender E-Mail-Validierungstechniken, dass Sie an legitime Adressen senden, die tatsächlich empfangen und Ihre Nachrichten authentifizieren können. Meiner Erfahrung nach verursachen solche Fehler mehr Support-Tickets als jede andere Art von DKIM-Problemen.
Ich habe oben erwähnt, dass DKIM-Fehler schwer 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 ist, oder der öffentliche Schlüssel der signierenden Domäne nicht im DNS gefunden wird oder syntaktisch nicht korrekt ist, oder vielleicht wurde die Nachricht offensichtlich während des Transits verändert. Wenn solche Arten von Fehlern auftreten, ist es einfach, das Problem herauszufinden und eine Lösung zu empfehlen. Die schwierigen Fälle jedoch, und diejenigen, die zu den frustrierendsten Support-Erfahrungen führen, sind die Fälle, in denen die Nachricht signiert wurde, der öffentliche Schlüssel im DNS existiert und die Nachricht nicht offensichtlich verändert wurde, aber der Validator meldet, 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 zu reproduzieren, unter denen die Nachricht signiert und validiert wurde. Die Nachricht hat in ihrem DKIM-Signatur-Header die Hashes, die der Unterzeichner zum Zeitpunkt der Signaturerstellung generiert hat, 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 hat daher keine Möglichkeit, die Nachricht auf dieselbe Weise zu validieren, wie es der Validator getan hat.
Fehler wie die, die ich hier beschreibe, sind seltene Vorkommnisse, und DKIM-Validierungsfehler allein haben in der Regel keine Auswirkungen auf die Zustellplatzierung. Während DKIM die Nachrichtenauthentifizierung handhabt, sichert die Implementierung umfassender E-Mail-Validierungstechniken, dass Sie an legitime Adressen senden, die tatsächlich empfangen und Ihre Nachrichten authentifizieren können. Meiner Erfahrung nach verursachen solche Fehler mehr Support-Tickets als jede andere Art von DKIM-Problemen.
