Dieses Kapitel erklärt, was Sie an einem DNS-Eintrag erkennen, welche Angaben Sie aus einer tatsächlichen Nachricht benötigen und wie Sie Selektoren, Schlüsselwechsel und fehlgeschlagene Prüfungen einordnen.
Welche Aussage DKIM ermöglicht
DomainKeys Identified Mail verbindet eine Signatur mit der Domain im Parameter d=. Der Parameter s= nennt den Selektor, unter dem der Empfänger den passenden öffentlichen Schlüssel sucht. Gemeinsam bilden diese beiden Angaben den DNS-Namen des Schlüssels.
Eine bestandene DKIM-Prüfung bezieht sich auf die signierten Headerfelder und den erfassten Nachrichtenkörper. Dabei gelten Regeln zur Kanonisierung: Bestimmte Änderungen an der Darstellung von Leerraum können je nach gewähltem Verfahren unschädlich sein. Nicht signierte Headerfelder oder ein nicht erfasster Teil des Körpers werden durch diese Signatur nicht geschützt.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Prüfgegenstand | Was Sie daraus ableiten können |
|---|---|
d= und s= einer Nachricht | Welche Signierdomain und welcher Selektor für diese Signatur verwendet werden. |
| Öffentlicher DNS-Schlüssel | Welcher Schlüssel unter dem abgefragten Namen zum Abrufzeitpunkt veröffentlicht ist. |
| Bestandene Signaturprüfung | Die geprüfte Signatur ist für die erfassten Nachrichtenteile unter den angewendeten DKIM-Regeln gültig. |
DKIM bestätigt keine natürliche Person und keine geschäftliche Berechtigung. Eine gültige Signatur sagt nicht, dass der Inhalt harmlos ist. Sie verschlüsselt auch keine Nachricht. Eine kompromittierte Signierumgebung kann weiterhin gültige Signaturen für ihre Domain erzeugen.
Die sichtbare From:-Domain muss nicht mit d= identisch sein. DMARC prüft diesen Zusammenhang durch Alignment. Allgemein reicht für einen DMARC-Pass ein erfolgreicher, ausgerichteter SPF-Prüfpfad oder eine erfolgreiche, ausgerichtete DKIM-Signatur. Für den Betrieb mit p=reject kommen strengere Anforderungen hinzu; diese werden im DMARC-Kapitel getrennt erklärt.
Vom privaten Schlüssel zur Prüfung beim Empfänger
Schematische Erklärung · keine Messung
Signieren beim Versender, prüfen beim Empfänger
- Versanddienst · signieren: Der Versanddienst bereitet die zu signierenden Headerfelder und den Nachrichtenkörper nach den gewählten Kanonisierungsregeln auf. Er erzeugt mit dem privaten Schlüssel die DKIM-Signatur.
- Versanddienst · versenden: Die Nachricht erhält ein
DKIM-Signature-Headerfeld. Darin stehen unter anderem Signierdomaind=, Selektors=, Algorithmus und Signaturdaten. - Empfänger · Schlüssel per DNS abfragen: Der Empfänger bildet aus
s=undd=den Namen unter_domainkeyund fragt den öffentlichen Schlüssel per DNS ab. Beis=mail202609undd=example.comlautet der Namemail202609._domainkey.example.com. - Empfänger · verifizieren: Der Empfänger prüft unter anderem Syntax, verwendbaren Schlüssel, Körperhash und Signatur. Erst diese Auswertung kann eine gültige Signatur bestätigen. DNS- oder Konfigurationsfehler sind mögliche andere Ergebnisse.
Kanonisierung und erfasste Nachrichtenteile begrenzen die Aussage. Ein DNS-Fund beweist keine gültige Signatur. Dies ist keine hier getestete E-Mail. Der private Schlüssel bleibt beim Versender; über DNS wird der öffentliche Schlüssel abgefragt.
Ohne DKIM fehlt dieser Signaturnachweis. SPF oder andere Empfangsprüfungen bleiben möglich, und ein ausgerichteter SPF-Pass kann das allgemeine DMARC-Pass-Kriterium erfüllen. Mit DKIM kann eine Signatur auch eine Weiterleitung überstehen, wenn die relevanten Nachrichtenteile unter der verwendeten Kanonisierung erhalten bleiben. Anders als SPF hängt diese Prüfung nicht von der Autorisierung der aktuellen Verbindungs-IP ab. Eine weitergeleitete Nachricht besteht deshalb aber nicht automatisch DKIM oder DMARC.
Die technischen Grundlagen stehen in RFC 6376, Abschnitte 3 und 6.
RSA, Ed25519 und die Größe des DNS-Eintrags
Für RSA unterscheidet der Standard Mindestanforderung und Empfehlung. Signierer müssen nach RFC 8301 mindestens 1024 Bit verwenden; empfohlen sind mindestens 2048 Bit. Verifizierer müssen Schlüssel von 1024 bis 4096 Bit unterstützen. Ein lokaler Empfänger darf zusätzliche Anforderungen an akzeptierte Signaturen stellen.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Schlüsseltyp | Protokollstatus | Praktische Einordnung |
|---|---|---|
| RSA 1024 Bit | Mindestgröße nach RFC 8301 | Geringere Sicherheitsreserve als bei größeren RSA-Schlüsseln; eine Umstellung auf mindestens 2048 Bit prüfen. Nicht pauschal mit „bereits gebrochen“ gleichsetzen. |
| RSA 2048 Bit | Entspricht der Empfehlung von mindestens 2048 Bit | Geeigneter Ausgangspunkt, wenn Versanddienst und DNS-Verwaltung dies unterstützen. |
| RSA 4096 Bit | Verifikation dieser Größe vorgeschrieben | Größerer Schlüssel und DNS-Eintrag; nicht allein wegen der höheren Zahl für jeden Dienst erforderlich. |
| Ed25519 | Zusätzlicher Algorithmus nach RFC 8463 | Eigener Algorithmus mit kurzen Schlüsseln; seine Bitzahl ist nicht direkt mit RSA vergleichbar. |
Signaturen mit RSA-Schlüsseln unter 1024 Bit dürfen nicht als gültig gelten. rsa-sha1 darf weder zum Signieren noch zur Verifikation verwendet werden. Die RSA-Anforderungen sind in RFC 8301, Abschnitt 3 festgelegt.
Ed25519 benötigt das richtige Format und Unterstützung im Betrieb
RFC 8463 ergänzt ed25519-sha256. Im öffentlichen Schlüsselrecord kennzeichnet k=ed25519 den Typ. Sein p=-Wert enthält die 32 rohen Schlüsselbytes als Base64, also 44 Zeichen. Ein ASN.1-/SPKI-Wrapper gehört bei diesem Algorithmus nicht in diesen Wert.
Der Standard verlangt Ed25519-Unterstützung von Verifizierern und empfiehlt sie für Signierer. Welche Funktion eine konkrete Installation anbietet, hängt dennoch von Software, Version, Kryptobibliothek und Versanddienst ab. Ein veröffentlichter Ed25519-Schlüssel bestätigt nicht, dass ausgehende Nachrichten damit signiert werden.
Falls Ihr Dienst mehrere Signaturen unterstützt, kann er RSA und Ed25519 mit unterschiedlichen Selektoren verwenden. Zwei DNS-Schlüssel allein sind kein Nachweis für dieses Dual-Signing. Prüfen Sie dafür die tatsächlich erzeugten Signaturen einer Nachricht.
Lange TXT-Werte sind nicht mehrere Schlüsselrecords
Ein DNS-TXT-Record kann mehrere Teilstrings von jeweils höchstens 255 Bytes enthalten. DKIM setzt diese Teilstrings ohne zusätzliche Leerzeichen zusammen. Das ist bei längeren RSA-Schlüsseln relevant, auch bei üblichen 2048-Bit-Konfigurationen. Aus den Teilstrings dürfen Sie keine getrennten Schlüsselrecords machen.
Veröffentlichen Sie nur den öffentlichen Wert, den Ihr Signierer oder Anbieter für DNS erzeugt hat. Ein privater Schlüssel gehört nicht in DNS und nicht in einen öffentlichen Prüfbericht.
Selektoren finden und Schlüssel wechseln
Ein Selektor ist ein Name für einen Schlüssel innerhalb einer Signierdomain. Mehrere Selektoren können unterschiedliche Versanddienste, einen alten Schlüssel oder einen vorbereiteten Wechsel repräsentieren. Ihre bloße Anzahl belegt keine regelmäßige Rotation.
Für eine bestimmte Nachricht lesen Sie s= und d= gemeinsam aus DKIM-Signature. Ein typischer Anbietername oder der sichtbare Absender allein reicht nicht, um den richtigen DNS-Namen abzuleiten.
Beispiele aus Anbieter-Dokumentationen
Diese Tabelle dient zur Orientierung, nicht als vollständige Einrichtungsvorlage. Dokumentationsstand: 12. September 2026. Übernehmen Sie die aktuellen Werte aus der Verwaltung des tatsächlich verwendeten Produkts.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Dienst | Dokumentierte Selektoren | DNS-Eintrag | Grenze |
|---|---|---|---|
| Microsoft 365 | selector1, selector2 | CNAME | Zielwerte aus der eigenen Konfiguration übernehmen; es bestehen unterschiedliche Zielnamensformate. |
| Google Workspace | google oder gewählter Präfix | TXT | Die Admin-Konsole liefert den für die Domain erzeugten Wert. |
| IONOS | s1-ionos, s2-ionos, s42582890 | CNAME | Der Beleg betrifft IONOS-Postfächer; für extern verwaltetes DNS nennt er dieselben drei Einträge. |
| STRATO | strato-dkim-0002, strato-dkim-0003 | CNAME | Der Anbieter weist auf mögliche Wechsel der Selektoren hin. |
| Netcup Webhosting | key1, key2 | CNAME | Beide dokumentierten Einträge gehören zu diesem Produkt; der Beleg schließt alternative Versandwege wie externen SMTP-Versand oder Versand über den Webserver aus. |
| Eigener Signierer | Frei gewählter Name, etwa mail202609 | TXT | Schlüsselverwendung und Rotation selbst betreiben und dokumentieren. |
Betriebsablauf · keine feste Wartefrist
Geplante Rotation mit Überlappung
Bei einer regulären Rotation soll der bisherige öffentliche Schlüssel für noch unterwegs befindliche Nachrichten zunächst weiter abrufbar bleiben. Die Selektor-Regeln in RFC 6376 ermöglichen diesen Übergang.
- Neuen Schlüssel erzeugen. Verwenden Sie einen neuen Selektor, etwa
mail202609, statt den bisher verwendeten Namen mit einem anderen Schlüssel zu überschreiben. - Neuen öffentlichen Schlüssel veröffentlichen. Berücksichtigen Sie vorhandene DNS-Cachefristen und gegebenenfalls zwischengespeicherte negative Antworten für den neuen Namen.
- Signierer umstellen. Aktivieren Sie die Signierung mit dem neuen privaten Schlüssel und Selektor. Ein DNS-Eintrag stellt den Mailserver nicht selbst um.
- Übergang prüfen. Stellen Sie anhand ausgehender Nachrichten fest, welcher Selektor verwendet wird. Halten Sie den alten öffentlichen Schlüssel für Nachrichten vor, die noch unterwegs sind. Die Dauer hängt vom Betrieb und seinen Verzögerungen ab, nicht von einem universellen Kalenderintervall.
- Alten Schlüssel außer Betrieb nehmen. Ein leerer
p=-Wert wiev=DKIM1; p=kennzeichnet den Widerruf. Auch das Entfernen des Schlüsselrecords verhindert eine erfolgreiche Verifikation über diesen Schlüssel; DNS-Caches können die Änderung verzögern.
Warum eine DKIM-Prüfung fehlschlagen kann
DKIM wird über definierte Nachrichtenteile berechnet, nicht über die Bedeutung des für Menschen sichtbaren Textes. Zwei Nachrichten können im Mailprogramm gleich aussehen und trotzdem andere signierte Bytes enthalten. Umgekehrt können die gewählten Kanonisierungsregeln bestimmte Leerraumänderungen ausgleichen.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Änderung auf dem Versandweg | Wann sie für die Signatur relevant ist |
|---|---|
| Footer oder Disclaimer anhängen | Wenn die Änderung den signierten Körper nach Kanonisierung verändert. Ein gesetztes l= kann den erfassten Körper begrenzen; ein gültiges Ergebnis bestätigt dann nicht automatisch nachträglich angehängten Inhalt. |
Betreff um [LISTNAME], [SPAM] oder [EXTERN] ergänzen | Wenn das betroffene Subject-Feld signiert ist. Die Änderung des Betreffinhalts wird durch relaxed nicht einfach rückgängig gemacht. |
| URLs umschreiben | Wenn eine umgeschriebene URL Teil des signierten Körpers ist und ihn unter der Kanonisierung verändert. |
| Zeichensatz oder MIME-Kodierung ändern | Wenn etwa eine Umkodierung zwischen UTF-8 und ISO-8859-1 die erfassten Bytes verändert; gleicher sichtbarer Text genügt nicht. |
| Zeilen neu umbrechen | Wenn die Änderung nicht von der gewählten Kanonisierung ausgeglichen wird. Nachrichtenzeilen unterliegen außerdem den Formatgrenzen von RFC 5322: höchstens 998 Zeichen ohne abschließendes CRLF. |
Die Kanonisierung ist in RFC 6376, Abschnitt 3.4 beschrieben; die Zeilenlänge in RFC 5322, Abschnitt 2.1.1.
„body hash did not verify“ eingrenzen
Der Befund bedeutet, dass der beim Prüfer berechnete Körperhash nicht zum Wert in bh= passt. Das ist kein bloßer Hinweis auf einen fehlenden DNS-Schlüssel. Prüfen Sie zuerst, ob die untersuchte Nachricht vollständig und in ihrer ursprünglichen Form vorliegt. Vergleichen Sie dann die Verarbeitungsschritte nach der Signierung: Footer, URL-Umschreibung, MIME-Umwandlung und Kanonisierung sind mögliche Ansatzpunkte. Der Text der Fehlermeldung allein beweist nicht, welcher Dienst die Änderung verursacht hat. RFC 6376, Abschnitt 6.1.3
Platzieren Sie die Signierung Ihrer eigenen ausgehenden Nachrichten nach den von Ihnen vorgesehenen inhaltlichen Änderungen. Wenn ein Gateway fremde Nachrichten verändert, sollte es vorhandene Authentifizierung vorher prüfen. ARC kann frühere Authentifizierungsergebnisse über Zwischenstationen dokumentieren. ARC repariert keine ungültige DKIM-Signatur und verpflichtet den letzten Empfänger nicht zur Annahme.
DNS-Konfiguration und Nachricht getrennt prüfen
- Signaturangaben bestimmen. Lesen Sie aus einer konkreten Nachricht Signierdomain
d=, Selektors=und Algorithmusa=. Bei mehreren Signaturen betrachten Sie jede getrennt. - Genauen Schlüssel abfragen. Für die Beispielkombination
s=mail202609undd=example.comlautet eine DNS-Abfrage:
dig TXT mail202609._domainkey.example.com- Antwort einordnen. Unterscheiden Sie den veröffentlichten Schlüssel, einen CNAME-Verweis, einen fehlenden Record und einen temporären DNS-Fehler. Prüfen Sie, ob das Schlüsselmaterial zum angegebenen Algorithmus passt. Der Befehl ist hier nur ein nicht ausgeführtes Lese-Beispiel.
- Signaturprüfung nachvollziehen. Dafür benötigen Sie die tatsächliche Nachricht und einen geeigneten Verifizierer oder das Ergebnis eines vertrauenswürdigen empfangenden Systems. Ein beliebiges
Authentication-Resultsohne geklärte Herkunft genügt nicht. Der Abschnitt zu Headerbefunden erklärt diese Vertrauensgrenze. - DMARC getrennt bewerten. Erst wenn eine Signatur besteht, prüfen Sie die Ausrichtung ihrer
d=-Domain zur sichtbarenFrom:-Domain. Ein DKIM-Pass für eine nicht ausgerichtete Domain liefert allein keinen DMARC-Pass.
Der E-Mail Security Check untersucht öffentlich erreichbare DNS-Konfiguration. Für die erste Frage nach einem bekannten Selektor kann dieser Befund genügen. Er bestätigt keine Signatur einer echten Nachricht, keine regelmäßige Schlüsselrotation und keine vollständige Abdeckung aller Selektoren oder Versanddienste.
DKIM als dokumentierte technische Maßnahme
Dokumentieren Sie, welcher Dienst mit welcher Domain signiert, wer den privaten Schlüssel schützt und wer DNS sowie Rotation verantwortet. Diese Betriebsangaben sind etwas anderes als ein einzelner DNS-Fund. Sie helfen, Änderungen und Übergaben nachvollziehbar zu machen.
Die folgenden rechtlichen Bezüge betreffen Deutschland und die EU:
- Deutschland: § 30 BSIG nennt für erfasste Einrichtungen angemessene und verhältnismäßige Risikomanagementmaßnahmen, darunter den Umgang mit Kryptografie. Ein DKIM-Schlüssel allein erfüllt oder belegt diese Anforderungen nicht; die Norm schreibt DKIM nicht pauschal für jede Domain vor.
- Technische Richtlinien: BSI TR-03182 betrifft E-Mail-Authentifizierung. Die ergänzende TR-03108 betrifft sicheren E-Mail-Transport. Eine DKIM-Signatur ist kein Nachweis der Konformität mit einer ganzen Richtlinie.
- Europäische Union: Artikel 32 DSGVO verlangt risikogerechte technische und organisatorische Maßnahmen. DKIM kann einen begrenzten Integritäts- und Authentifizierungsbeitrag leisten; es ersetzt weder Vertraulichkeitsschutz noch Zugriffskontrollen.
Eine bestandene DKIM-Prüfung ist kein Zertifikat, kein Compliance-Nachweis und kein Versprechen zur Zustellung.
Die Abschnitte zu E-Mail-Spoofing und Phishing ordnen weitere Angriffswege ein. Eine gültige Signatur ersetzt diese inhaltliche Beurteilung nicht.
Anleitung für Ihren Signierdienst
Die vorhandenen Anleitungen ordnen die jeweilige Einrichtung ein. Wählen Sie den tatsächlich verwendeten Versanddienst; DNS-Anbieter und Signierdienst müssen nicht derselbe sein.
Häufige Fragen
Was ist DKIM?
DKIM ist ein Verfahren für kryptografische E-Mail-Signaturen mit einer Signierdomain. Der Empfänger prüft die erfassten Nachrichtenteile anhand des zu d= und s= gehörenden öffentlichen DNS-Schlüssels. DKIM ist keine Verschlüsselung und bestätigt keine natürliche Person.
Worin unterscheiden sich SPF und DKIM?
SPF vergleicht eine Verbindungs-IP mit der DNS-Richtlinie einer SMTP-Identität. DKIM prüft eine Signatur an einer tatsächlichen Nachricht. DMARC kann einen erfolgreichen und ausgerichteten Pfad eines der beiden Verfahren mit der sichtbaren Absenderdomain verbinden.
Welchen DKIM-Schlüssel sollte ich verwenden?
Für RSA empfiehlt RFC 8301 mindestens 2048 Bit; 1024 Bit ist das Protokollminimum, nicht die allgemeine Empfehlung für eine neue Einrichtung. Ed25519 ist ein eigener Algorithmus mit anderem Schlüsselformat. Verwenden Sie die von Ihrem Dienst unterstützten Verfahren und prüfen Sie die tatsächlich erzeugten Signaturen.
Wie oft muss ich DKIM-Schlüssel rotieren?
Aus DKIM ergibt sich kein universeller Kalenderabstand für jede Installation. Planen Sie den Wechsel nach Ihrem Betrieb, dem Umgang mit privaten Schlüsseln und Anbieteranforderungen. Reguläre Rotation benötigt einen nachvollziehbaren Übergang; eine Kompromittierung verlangt eine gesonderte Reaktion. Zwei veröffentlichte Selektoren beweisen keinen ausgeführten Wechsel.
Welche Änderungen können DKIM ungültig machen?
Änderungen an erfassten Nachrichtenteilen, die nach der verwendeten Kanonisierung bestehen bleiben. Beispiele sind angehängte Footer, umgeschriebene URLs oder ein veränderter signierter Betreff. Ein nicht signiertes Headerfeld oder eine von der Kanonisierung ausgeglichene Leerraumänderung ist anders zu beurteilen.
Wie prüfe ich, ob DKIM funktioniert?
DNS zeigt, ob am konkreten Selektornamen ein Schlüssel veröffentlicht ist. Ob DKIM an einer Nachricht funktioniert, ergibt erst deren tatsächliche Signaturprüfung. Nutzen Sie d= und s= dieser Nachricht, trennen Sie einzelne Signaturen und prüfen Sie zusätzlich das DMARC-Alignment, wenn dies Ihre Frage ist.
Quellen und Anschluss
RFC 6376 ist der DKIM-Internetstandard STD 76. Er wird durch RFC 8301, RFC 8463, RFC 8553 und RFC 8616 aktualisiert. Quellenstand: 12. September 2026. Die DKIM-Errata und die Errata zu den hier verwendeten Kryptografie-Updates wurden auf relevante Grenzen geprüft. Ein nur gemeldetes Erratum ist keine bereits angenommene Änderung des Standards.