A DKIM-Signature ist eine Reihe von durch Semikolons getrennten Tags, die beschreiben, wie eine Domäne eine Nachricht signiert hat. Das Lesen dieser Felder hilft Ihnen bei der Auswahl des richtigen DNS Such- und Untersuchungspfads. Es ist nicht möglich, die Kryptografie per Augenschein zu validieren. Bewahren Sie die Originalnachricht auf, bevor Sie eine Signatur zur Überprüfung kopieren oder neu formatieren.
Beginnen Sie mit den Such- und Algorithmusfeldern
Der erforderliche d=-Wert ist die Signaturdomäne; erforderlich s= ist das Wähler. Bei der normalen DNS TXT Abfragemethode führen diese zu s. _domainkey.d. Das a=-Tag identifiziert den Signierungs- und Hash-Algorithmus. Das erforderliche v=-Tag muss für RFC 6376 -Signatursyntax den Wert 1 haben. Dies unterscheidet sich vom Versions-Tag in einem DNS Schlüsseleintrag. Diese Werte beschreiben die Signatur, nicht ihr Überprüfungsergebnis. RFC 6376 §3.5, RFC 6376 §3.6.2.
Illustratives Fragment, absichtlich unvollständig und keine gültige Signatur: d=example.com; s=outbound2026; a=rsa-sha256; c=relaxed/relaxed; h=from:to:subject:date. Sein Suchname ist outbound2026._domainkey.example.com . Es ist Kanonisierung Verwendet eine entspannte Verarbeitung sowohl für Kopfzeilen als auch für Textkörper. Die Liste der signierten Header benennt die ausgewählten Headerfelder. Das Fragment lässt erforderliche kryptografische Werte weg und darf niemals als Produktionsdatensatz verwendet werden.
Unterscheiden Sie die Inhaltsabdeckung von Signaturdaten
Das h=-Tag listet die an den Signaturvorgang übergebenen Headerfelder in ihrer definierten Reihenfolge auf. Es handelt sich nicht um einen Hash-Algorithmus. Von muss in einer gültigen DKIM -Signatur enthalten sein. Wiederholte Header-Namen und doppelte Nachrichtenfelder erfordern die Auswahlregeln in der Spezifikation; Ein flüchtiger Blick auf die Liste kann nicht alle Fragen zur Abdeckung klären.
Das bh=-Tag enthält das Körper-Hash. Das b=-Tag enthält den Signaturwert. Passende oder plausibel erscheinende Kodierungen beweisen keine Gültigkeit. Das c=-Tag beschreibt die Kanonisierung, die eine spezifische Normalisierung der vorzeichenbehafteten Darstellung ermöglicht. Es erlaubt kein willkürliches Umschreiben einer Nachricht. Wenn c= weggelassen wird, ist der Standardwert einfach/einfach; Wenn nur ein Algorithmus benannt ist, gilt dieser für Header und der Hauptteil ist standardmäßig „einfach“. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §5.4.
Das optionale l=-Tag begrenzt die Anzahl der enthaltenen kanonisierten Body-Oktette. Sein Vorhandensein erfordert Sorgfalt: Eine gültige Signatur darf Inhalte, die über diese Länge hinaus angehängt werden, nicht abdecken. Beschreiben Sie nicht alles DKIM gelten als Beweis dafür, dass jedes sichtbare Byte unverändert ist. RFC 6376 §3.5, RFC 6376 §8.2.
Interpretieren Sie Identität und Zeit sorgfältig
Der optionale i=-Wert ist eine Agenten- oder Benutzerkennung, die gemäß den Regeln der signierenden Domäne geltend gemacht wird. Es handelt sich nicht unbedingt um ein funktionierendes Postfach. DMARC verwendet validiertes d=, nicht i=, für DKIM Ausrichtung. Die Tags t= und x= beschreiben die Signaturzeit und den Signaturablauf. RFC 6376 §3.5 markiert beide offiziell als EMPFOHLEN, obwohl sie möglicherweise fehlen. Dabei handelt es sich um Signaturmetadaten und nicht um einen Nachweis der tatsächlichen SMTP Ankunftszeit. Bewahren Sie empfangene Header und Systemprotokolle für die Transitanalyse auf.
Eine Signatur, die veraltete Kryptographie verwendet, sollte nicht nur deshalb akzeptiert werden, weil ihre Felder analysiert werden. RFC 8301 §3.1 verbietet rsa-sha1; RFC 8301 §3.2 Aktualisiert die wichtigsten RSA-Anforderungen. Verwenden Sie unterstützte Verifizierungssoftware und aktuelle Anbieterrichtlinien, anstatt diese Prüfungen aus diesem Praxisleitfaden manuell durchzuführen.
Schließen Sie mit dem Empfängerergebnis ab
Erfassen Sie das D/S-Paar, den Algorithmus, die relevanten Abdeckungsfelder, das vertrauenswürdige DKIM Ergebnis und den Fehlergrund. Wenn DNS fehlt, untersuchen Sie den genauen Besitzernamen und den Schlüssellebenszyklus. Wenn der Schlüssel verfügbar ist, die Überprüfung jedoch fehlschlägt, vergleichen Sie die Signatur- und Übermittlungspfade, ohne den Originalnachweis zu ändern. Bestätigen Sie alle Abhilfemaßnahmen mit einer neu gesendeten Nachricht und einem vertrauenswürdigen Empfängerergebnis. Das Ziel ist eine vertretbare Erklärung einer Signatur, nicht eine visuelle Gut/Schlecht-Vermutung.
Wenden Sie die Unterscheidung an
Lesen Sie das illustrative Fragment in vier Gruppen: d/s wählt Identität und Suche aus; a/c spezifiziert Algorithmus und Kanonisierung; h und jedes l definieren die Abdeckung; b/bh tragen Werte, die von der Software überprüft werden. Fehlt das erforderliche v/b/bh, bedeutet das, dass das Fragment keine gültige Signatur ist. Wenn l=0 in einer echten Signatur vorkommt, werden Null-Body-Oktette gehasht, sodass die Body-Integrität nicht geschützt ist. RFC 6376 §3.5 definiert diesen Längenmechanismus. Keine dieser Beobachtungen ist ein kryptografischer Pass.