DKIM: der vollständige Leitfaden zur DKIM-Signatur

Der DKIM-Signature-Header, entschlüsselt

Die gesamte DKIM-Mechanik steckt in einem einzigen Header, der der Nachricht hinzugefügt wird. Hier ein Beispiel, wie es im Quelltext einer E-Mail zu finden ist:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=beispiel.de; s=s2026; t=1753344000;
  h=from:to:subject:date:mime-version;
  bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR...

Die Etiketten (Tags), aus denen er besteht, sind normiert. Die sieben wichtigsten:

Tag	Name	Rolle
v=	Version	Immer 1: die verwendete Version des DKIM-Standards.
a=	Algorithmus	Der Signatur- und Hash-Algorithmus, in der großen Mehrheit der Fälle rsa-sha256 (ed25519-sha256 bei modernen Schlüsseln).
d=	Domain	Die signierende Domain, die die Nachricht für sich beansprucht. Sie ist es, die DMARC mit dem sichtbaren From: vergleicht.
s=	Selektor	Der Name des verwendeten Schlüssels; er sagt dem Empfänger, wo im DNS der öffentliche Schlüssel zu finden ist.
h=	Signierte Header	Die Liste der von der Signatur abgedeckten Header; jeder Header, der hier fehlt, kann sich ändern, ohne die Signatur zu brechen.
bh=	Body-Hash	Der Hash des Nachrichtenkörpers zum Zeitpunkt der Signatur.
b=	Signatur	Die kryptografische Signatur selbst, base64-kodiert.

Je nach Konfiguration tauchen weitere Tags auf: c= (der oben erwähnte Kanonisierungsmodus), t= (Zeitstempel der Signatur), x= (Ablaufdatum, nach dem die Signatur nicht mehr akzeptiert werden darf), i= (Identität des signierenden Agenten, manchmal eine Subdomain oder eine Adresse) oder l= (signierte Körperlänge — eine riskante Option, weil sie das Anhängen von Inhalten nach dem signierten Teil erlaubt; die gängige Praxis rät davon ab).

Zwei Tags verdienen besondere Aufmerksamkeit. Zuerst d=: Es ist der Identitätsanspruch der Signatur und der Angelpunkt des gesamten DMARC-Gebäudes. Dann h=: Die Liste der signierten Header bestimmt, was die Signatur tatsächlich schützt. From zu signieren ist Pflicht; auch Subject, Date, To und Reply-To zu signieren wird dringend empfohlen, damit sie nachträglich nicht gefälscht werden können.

Selektoren: mehrere Schlüssel für eine Domain

Eine Domain hat fast nie nur einen einzigen DKIM-Schlüssel. Geschäftliche E-Mails verlassen das Haus typischerweise über mehrere Wege — den Haupt-Mailanbieter, ein Marketing-Tool, ein CRM, einen Rechnungsdienst — und jeder signiert mit seinem eigenen Schlüsselpaar. Der Selektor ist der Mechanismus, der dieses Nebeneinander möglich macht: ein frei gewählter Name, der jeden veröffentlichten Schlüssel identifiziert.

Das Auffinden des öffentlichen Schlüssels folgt einer festen Konvention. Der Empfänger liest s= und d= aus der Signatur und fragt dann das DNS ab unter:

<selektor>._domainkey.<domain>

Für s=s2026 und d=beispiel.de zielt die TXT-Abfrage also auf s2026._domainkey.beispiel.de. Jeder Versandanbieter pflegt eigene Namenskonventionen: google bei Google Workspace, selector1/selector2 bei Microsoft 365, plattformspezifische Namen anderswo. Daraus ergibt sich ein nützlicher Audit-Reflex: Wer die unter _domainkey veröffentlichten Selektoren aufzählt, erhält die Liste der Dienste, die für die Domain signieren dürfen — einschließlich derer, die längst in Vergessenheit geraten sind.

Diese Mehrschlüssel-Architektur bringt zwei große betriebliche Vorteile. Isolation: Wird ein Anbieter kompromittiert oder abgelöst, widerruft man seinen Selektor, ohne die anderen Flüsse anzufassen, die normal weitersignieren. Flexibilität: Ein neuer Schlüssel kann neben dem alten eingeführt werden — die Grundlage der unterbrechungsfreien Rotation weiter unten. Rolle, Konventionen und Fallstricke des Selektors behandelt im Detail unser eigener Leitfaden zum Selektor.

Einen DKIM-Schlüssel erzeugen und veröffentlichen

In der Praxis entsteht das Schlüsselpaar auf einem von zwei Wegen. Entweder erzeugt die Versandplattform es für Sie — der Fall bei Office-Suiten und den meisten Versandplattformen, die den zu veröffentlichenden DNS-Eintrag gleich mitliefern. Oder Sie erzeugen es selbst (selbst gehosteter Mailserver, Anforderung an die eigene Schlüsselhoheit), mit einem Standardwerkzeug wie OpenSSL. Die genauen Befehle, Schritt für Schritt, stehen in unserer Anleitung zur Schlüsselerzeugung.

Der öffentliche Schlüssel wird anschließend im DNS veröffentlicht, und dabei existieren zwei Modelle nebeneinander:

Der direkte TXT-Eintrag. Sie legen den TXT-Eintrag selbst unter <selektor>._domainkey.<domain> an, mit dem Schlüssel im Klartext:

s2026._domainkey.beispiel.de.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Sie behalten die volle Kontrolle über den Schlüssel — Sie rotieren ihn, Sie widerrufen ihn. Ein Stolperstein: Ein 2048-Bit-RSA-Schlüssel überschreitet die Grenze von 255 Zeichen pro DNS-Zeichenkette; der Eintrag wird dann in mehrere Zeichenketten in Anführungszeichen aufgeteilt, die Resolver automatisch wieder zusammensetzen. Diese Aufteilung ist normal, aber manche DNS-Oberflächen gehen schlecht damit um.

Der delegierte CNAME. Sie veröffentlichen nur einen Alias, der auf einen beim Versandanbieter gehosteten Eintrag zeigt:

s1._domainkey.beispiel.de.  IN CNAME  s1.domainkey.versandanbieter.example.

Der Anbieter hostet den echten Schlüssel und kann ihn rotieren, ohne dass Sie je Ihre DNS-Zone anfassen. Das ist das vorherrschende Modell bei Versandplattformen, mit einem echten betrieblichen Verdienst: Die Rotation wird sein Problem, nicht Ihres. Der Preis dafür ist delegiertes Vertrauen — der Anbieter kontrolliert eine kryptografische Identität Ihrer Domain. In beiden Modellen kann das Tag t=y (Testmodus) eine Erstinbetriebnahme begleiten, und der Widerruf erfolgt, indem man den p=-Wert des Eintrags leert.

Schlüsselrotation: Hygiene, kein Ereignis

Ein DKIM-Schlüssel ist nicht für die Ewigkeit gedacht. Je länger ein privater Schlüssel existiert, desto größer die Wahrscheinlichkeit, dass er abhandenkommt: ein verlegtes Backup, ein kompromittierter Server, ein verlassener Dienstleister mit weiterhin aktivem Schlüssel, eine vergessene Kopie in einem Code-Repository. Ein gestohlener privater DKIM-Schlüssel erlaubt es, Nachrichten zu signieren, die für Empfänger vollkommen authentisch aussehen — DMARC-Alignment inklusive. Die periodische Rotation begrenzt dieses Risiko zeitlich: Ein gestern gestohlener Schlüssel ist nach der Rotation wertlos.

Zur Frequenz: Die in der Branche üblicherweise zitierte Referenz (insbesondere die M3AAWG-Empfehlungen) ist eine Rotation mindestens zweimal pro Jahr, also etwa alle sechs Monate. In der Praxis: alle sechs Monate bei sensiblen Flüssen, mindestens einmal jährlich, und sofort bei jedem Verdacht auf Kompromittierung oder beim Abschied von einem Dienstleister.

Das Bemerkenswerte daran: Dank der Selektoren kann die Rotation völlig transparent ablaufen. Die unterbrechungsfreie Prozedur umfasst vier Schritte:

1. Ein neues Schlüsselpaar erzeugen und den neuen öffentlichen Schlüssel unter einem neuen Selektor veröffentlichen (etwa s2027), ohne den alten anzurühren.
2. Die Signatur auf der Versandseite auf den neuen Schlüssel umstellen.
3. Einige Tage warten: Mit dem alten Schlüssel signierte Post, noch unterwegs oder in Warteschlangen, muss fertig zugestellt und geprüft werden.
4. Den alten Selektor widerrufen (sein p= leeren) und ihn anschließend entfernen.

Zu keinem Zeitpunkt ist eine Nachricht ohne prüfbaren öffentlichen Schlüssel unterwegs: Beide Selektoren koexistieren während der Umstellung. Die vollständige Prozedur, die Fallstricke und der Fall CNAME-delegierter Schlüssel sind Gegenstand von unserem Leitfaden zur Schlüsselrotation. Ein letzter Punkt derselben Hygiene: Der private Schlüssel ist ein kritisches Geheimnis und genau so zu behandeln (Secrets-Tresor, restriktive Zugriffe) — niemals im Klartext in einem Repository oder einem Ticket.

1024 oder 2048 Bit: die Schlüssellänge

Bei RSA-Schlüsseln begegnet man in der Praxis zwei Längen. 1024 Bit, lange der Standardwert, wird von Verifizierern noch akzeptiert, bietet aber keine ernsthafte Sicherheitsmarge mehr: RFC 8301 hat diese Länge als absolutes Minimum festgelegt, und die Faktorisierung eines solchen Schlüssels liegt für einen sehr gut ausgestatteten Angreifer nicht mehr außer Reichweite. 2048 Bit ist der heutige Standard: komfortable kryptografische Marge, universelle Unterstützung auf Empfängerseite, und die einzige praktische Einschränkung — der auf mehrere Zeichenketten aufgeteilte DNS-Eintrag — ist bei jedem ordentlichen DNS-Anbieter ein Nicht-Thema.

Die Regel ist also einfach: Jeder neue Schlüssel wird mit 2048 Bit erzeugt, und eine noch mit 1024 Bit ausgestattete Domain nutzt ihre nächste Rotation für das Upgrade — genau die Art von Umstellung, die der Selektor-Mechanismus schmerzfrei macht. Die Geschichte hat hier längst entschieden: Kurze Schlüssel (512 und 768 Bit) wurden vor über einem Jahrzehnt öffentlich faktorisiert, und die großen Provider bestrafen oder ignorieren Signaturen aus schwachen Schlüsseln. Die vollständige Argumentation, mit Zahlen, steht in dem Vergleich 1024 vs. 2048 Bit.

Jenseits von RSA hat RFC 8463 Ed25519-Schlüssel eingeführt: bei gleichwertiger Stärke deutlich kürzer, passen sie ohne Aufteilung in einen DNS-Eintrag. Die Unterstützung auf Verifiziererseite wächst, bleibt aber lückenhaft; die empfohlene Praxis ist, sie als zweiten Selektor zu veröffentlichen, in Doppelsignatur neben einem RSA-2048-Schlüssel — nie als harten Ersatz.

DKIM und DMARC: das Alignment des d=

Es muss klar gesagt werden: DKIM allein schützt nicht vor Identitätsmissbrauch. Eine gültige DKIM-Signatur beweist, dass die Nachricht unverändert ist und von der d=-Domain signiert wurde — aber nichts in DKIM verlangt, dass dieses d= mit der Domain übereinstimmt, die im sichtbaren From: steht. Ein Angreifer kann sauber mit seiner eigenen Domain signieren und Ihre im From: anzeigen: DKIM steht auf Grün.

Genau dieses Glied fügt DMARC hinzu: das Alignment. Damit eine Nachricht DMARC über DKIM besteht, muss die Signatur gültig sein und ihre d=-Domain mit der From:-Domain aligned sein. Im Modus relaxed (der Standard) genügt eine gemeinsame Organisationsdomain — eine Signatur von newsletter.beispiel.de aligned mit einem From: auf beispiel.de; im Modus strict (adkim=s) muss die Übereinstimmung exakt sein. Diese Regel macht aus einem Integritätsbeweis einen echten Identitätsschutz, und deshalb wird DKIM immer mit Blick auf DMARC eingerichtet — die vollständige Mechanik der Richtlinie beschreibt die DMARC-Referenzseite.

Das DKIM-Alignment hat eine entscheidende Eigenschaft: Es überlebt die Weiterleitung (Forwarding). Wird eine E-Mail weitergereicht — etwa vom beruflichen Postfach an eine private Adresse —, stellt der weiterleitende Server sie zu, und die ursprüngliche IP passt nicht mehr: Die IP-Prüfung schlägt fehl, wie die SPF-Referenzseite erklärt. Die DKIM-Signatur dagegen reist in der Nachricht mit: Solange der signierte Inhalt unverändert bleibt, ist sie auch nach einem oder mehreren Sprüngen gültig. Bei weitergeleiteter Post ist DKIM oft der einzige Mechanismus, der noch ein aligntes Ergebnis liefern kann — weshalb eine strikte DMARC-Richtlinie ohne solides DKIM eine fragile Richtlinie ist. Auch die Grenze existiert: Mailinglisten, die den Betreff umschreiben oder eine Fußzeile anhängen, brechen die Signatur — ein Fall, den der ARC-Standard aufzufangen versucht. In der Praxis ist ein auf allen Quellen signiertes und aligntes DKIM die Bedingung Nummer eins, um den Weg von p=none zu p=reject gelassen zu gehen.

Eine DKIM-Signatur überprüfen

Die gute Nachricht: Es gibt nichts selbst nachzurechnen. Jeder empfangende Server prüft die Signaturen und protokolliert sein Urteil in einem Authentication-Results-Header, sichtbar im Quelltext jeder empfangenen Nachricht:

Authentication-Results: mx.example.net;
  dkim=pass header.d=beispiel.de;
  spf=pass ...; dmarc=pass ...

Zwei Informationen zählen. dkim=pass: Die Signatur ist kryptografisch gültig. header.d=: die signierende Domain — sie ist mit dem From: zu vergleichen, um das Alignment zu beurteilen. Ein dkim=pass mit dem header.d= eines Dienstleisters bringt DMARC nichts: gültige Signatur, nicht aligned Identität. Wie man diese Header im Detail liest, Tag für Tag, samt der typischen Fehlerursachen, zeigt unser Leitfaden zur Signaturprüfung.

Diese Einzelprüfung sagt allerdings nichts über den Verkehr als Ganzes. Den vollständigen Überblick liefern die DMARC-Aggregatberichte, die Quelle für Quelle die DKIM-Ergebnisse und ihr Alignment auflisten, so wie die großen Empfänger sie tatsächlich bewertet haben — das Thema von unserem Leitfaden zu den Aggregatberichten. Und für eine sofortige Bestandsaufnahme Ihrer Domain — erkannte Selektoren, veröffentlichte Schlüssel, Alignment, DMARC-Richtlinie — liefert unser kostenloser DKIM-Check alles in wenigen Sekunden, ohne Anmeldung.

FAQ

Ist DKIM Pflicht für den E-Mail-Versand?

Formal nein: Eine unsignierte Nachricht kann zugestellt werden. Praktisch ja. Die Absenderanforderungen von Gmail und Yahoo schreiben DKIM für Massenversender vor, DMARC kann ohne DKIM kein robustes Alignment erzeugen, und Empfänger bringen unsignierter Post weniger Vertrauen entgegen. Für jede Domain, die geschäftliche E-Mails versendet, ist DKIM eine faktische Voraussetzung.

Verschlüsselt DKIM den Inhalt der Nachrichten?

Nein. DKIM signiert, es verschlüsselt nicht: Unter diesem Gesichtspunkt reist die Nachricht im Klartext, und die Signatur beweist nur Herkunft und Unversehrtheit. Die Vertraulichkeit des Transports übernehmen andere Mechanismen (TLS zwischen Servern, gehärtet durch MTA-STS), die Ende-zu-Ende-Verschlüsselung wieder andere Werkzeuge (S/MIME, OpenPGP).

Was passiert, wenn eine DKIM-Signatur fehlschlägt?

Nichts Automatisches. Ein isoliertes dkim=fail führt nicht zur Ablehnung der Nachricht: Es ist ein Signal, das der Empfänger mit SPF, der Reputation und vor allem der DMARC-Richtlinie der Domain kombiniert. DMARC entscheidet — liefert weder DKIM noch SPF ein aligntes Ergebnis, greift die veröffentlichte Richtlinie (none, quarantine oder reject).

Wie viele Selektoren kann eine Domain veröffentlichen?

So viele wie nötig: Der Standard setzt keine Grenze. Eine aktive Domain veröffentlicht üblicherweise fünf bis zehn Selektoren — einen oder zwei pro Versanddienst, plus die, die während einer Rotation vorübergehend koexistieren. Die gute Praxis besteht nicht darin, sie zu begrenzen, sondern sie zu inventarisieren: Jeder aktive Selektor ist eine Identität, die für die Domain signieren kann, und ein vergessener Selektor eines verlassenen Dienstleisters ist eine offen gebliebene Tür.

Wie oft sollte der DKIM-Schlüssel rotiert werden?

Die Branchenreferenz ist eine halbjährliche Rotation, mindestens einmal pro Jahr, und ohne Verzögerung bei Kompromittierungsverdacht oder beim Abschied von einem Dienstleister. Dank der Doppel-Selektor-Methode verursacht die Operation keinerlei Unterbrechung. CNAME-delegierte Schlüssel rotiert der Anbieter selbst — prüfen Sie, ob das tatsächlich geschieht; die Delegation ist keine Garantie.

Kann eine Nachricht mehrere DKIM-Signaturen tragen?

Ja, und das ist häufig: Der Standard erlaubt mehrere DKIM-Signature-Header auf einer Nachricht. Eine Versandplattform signiert oft mit ihrer eigenen Domain und mit Ihrer; auch eine Doppelsignatur RSA + Ed25519 ist gängige Übergangspraxis. Für DMARC genügt eine einzige gültige, alignte Signatur — die übrigen stören nicht.