DKIM-Records erklärt: E-Mail-Authentifizierung und Deliverability verbessern

Was ist ein DKIM-Record?

Ein DKIM-Record ist ein DNS-TXT-Eintrag, der einen öffentlichen Schlüssel enthält. Damit können E-Mail-Server prüfen, ob eine Nachricht tatsächlich von der angegebenen Domain stammt und unterwegs nicht manipuliert wurde. Zusammen mit SPF und DMARC bildet DKIM die drei Säulen der E-Mail-Authentifizierung. Gemeinsam verhindern sie, dass Spammer Ihre Domain fälschen, und entscheiden darüber, ob Ihre E-Mails im Posteingang oder im Spam-Ordner landen.

Bevor es weitergeht, ein paar Begriffe, die Sie kennen sollten:

• •

  DKIM-Record: der DNS-TXT-Eintrag, der den öffentlichen Schlüssel enthält, den empfangende Server abfragen

• •

  DKIM-Signatur: der kryptografische Header, der jeder ausgehenden E-Mail angehängt wird und mit einem privaten Schlüssel erzeugt wurde

• •

  Selektor: ein Label, das empfangende Server zum richtigen öffentlichen Schlüssel in Ihrem DNS leitet

Record und Signatur werden oft verwechselt, sind aber nicht dasselbe. Der Record liegt still in Ihrem DNS. Die Signatur reist mit jeder E-Mail mit, die Sie versenden.

So funktioniert die DKIM-E-Mail-Authentifizierung

DKIM basiert auf einem kryptografischen Schlüsselpaar: einem privaten und einem öffentlichen Schlüssel. So arbeiten beide zusammen, Schritt für Schritt.

Der private Schlüssel und die digitale Signatur

Wenn Ihr Mailserver eine Nachricht versendet, erzeugt er mit einem privaten Schlüssel eine eindeutige digitale Signatur und hängt sie als versteckten Header namens DKIM-Signature an. Diese Signatur deckt in der Regel die Nachrichten-Header und den Body ab. Der private Schlüssel verlässt nie Ihren Server, und genau das ist der Sinn dahinter.

Der öffentliche Schlüssel und der DNS-Lookup

Der empfangende Server liest die Werte s= (Selektor) und d= (Domain) aus dem Signatur-Header und fragt dann im DNS den passenden öffentlichen Schlüssel ab. Genau hier kommt Ihr DKIM-Record ins Spiel. Ohne ihn hat der empfangende Server nichts, wogegen er prüfen kann.

Verifizierung und Authentifizierungsprüfung

Der öffentliche Schlüssel entschlüsselt die Signatur, und der Server vergleicht sie mit einer frisch berechneten Version der Nachricht. Stimmen beide überein, ist die DKIM-Prüfung bestanden. Wurde auch nur ein Zeichen während der Übertragung verändert, schlägt sie fehl, und dieser Fehler wird für das DMARC-Reporting protokolliert.

DKIM-Record: Syntax und Beispiel

Ein DKIM-Record besteht aus zwei Teilen: dem Record-Namen und dem Record-Inhalt. Sobald Sie das Muster kennen, erkennen Sie fehlerhafte Einträge deutlich schneller.

Record-Name und Selektor-Format

DKIM-Records stehen nicht direkt unter Ihrem Domain-Namen. Stattdessen folgen sie diesem Format:

selector._domainkey.ihredomain.com

Ein Selektor wie google auf acme.com wird also zu google._domainkey.acme.com.

Record-Inhalt und öffentlicher Schlüssel

Der Wert folgt einem Tag-Value-Format. v=DKIM1 sagt dem Server, dass es sich um einen DKIM-Record handelt, und alles nach p= ist der öffentliche Schlüssel selbst. Ist p= leer, wurde der Schlüssel bewusst widerrufen und der Record ist praktisch deaktiviert.

Record-Typ und TTL

Technisch gesehen ist ein DKIM-Record einfach ein DNS-TXT-Record, derselbe Typ, der für alle möglichen domainbezogenen Texteinträge genutzt wird. Die meisten DNS-Anbieter setzen die TTL standardmäßig auf 3600 Sekunden (eine Stunde), und das reicht für DKIM in der Regel aus.

Was ist ein DKIM-Selektor und wie finden Sie Ihren?

Selektoren gibt es, weil eine Domain oft über mehrere Dienste E-Mails versendet und jeder Dienst einen eigenen Schlüssel braucht. Deshalb sind mehrere DKIM-Records unter einer einzelnen Domain ganz normal, einer pro Sendequelle.

So finden Sie Ihren Selektor in den E-Mail-Headern

Senden Sie sich eine Test-E-Mail an ein Gmail-Konto, öffnen Sie sie und klicken Sie auf „Original anzeigen". Suchen Sie nach dkim=pass im Authentication-Results-Header, oder prüfen Sie den DKIM-Signature-Header direkt auf den s=-Tag. Dieser Wert ist Ihr Selektor.

Gängige Selektoren nach E-Mail-Anbieter

Sie müssen nicht immer die Header durchsuchen. Die meisten Anbieter verwenden einen bekannten Standard-Selektor:

• •

  Google Workspace: google

• •

  Microsoft 365: selector1, selector2

• •

  Mailchimp: k1

• •

  SendGrid: s1, s2

Wenn Sie neben Ihrem Hauptanbieter ein Outreach-Tool wie lemlist nutzen, veröffentlicht dieses in der Regel ebenfalls einen eigenen Selektor.

DKIM-Record einrichten: Schritt für Schritt

Die genauen Schritte können je nach Anbieter leicht variieren, aber der grundsätzliche Ablauf sieht so aus.

1. 1.

   Listen Sie alle Domains und Dienste auf, die in Ihrem Namen versenden, einschließlich Ihres E-Mail-Anbieters, Ihres CRM und aller Outreach-Tools.

2. 2.

   Generieren Sie ein DKIM-Schlüsselpaar. Die meisten Anbieter erledigen das für Sie in ihrer Admin-Konsole.

3. 3.

   Erstellen Sie den DNS-Record im oben beschriebenen Namensformat und fügen Sie den öffentlichen Schlüssel ein.

4. 4.

   Fügen Sie den Record bei Ihrem DNS-Anbieter hinzu (Cloudflare, GoDaddy, Namecheap o. Ä.).

5. 5.

   Aktivieren Sie die DKIM-Signierung auf Ihrem Server. Manche Anbieter aktivieren das automatisch, sobald der Record verifiziert ist. Andere erfordern manuelles Umschalten.

6. 6.

   Testen Sie das Setup mit einer echten E-Mail und einem DKIM-Checker.

Propagation und Signatur-Aktivierung können etwas dauern. Keine Panik, wenn die Prüfung beim ersten Versuch nicht besteht.

TXT- vs. CNAME-Records für DKIM

Nicht jeder Anbieter verlangt denselben Record-Typ, und der Unterschied liegt darin, wer den Schlüssel kontrolliert.

Wann ein TXT-Record sinnvoll ist

Ein TXT-Record speichert den vollständigen öffentlichen Schlüssel direkt in Ihrem DNS, und Sie kontrollieren, wann er sich ändert. Das ist der Standardansatz und entspricht der offiziellen DKIM-Spezifikation.

Wann ein CNAME-Record sinnvoll ist

Microsoft 365 zum Beispiel nutzt CNAME-Records, die auf Microsofts eigene DKIM-Infrastruktur verweisen. Damit liegt die Schlüsselverwaltung beim Anbieter, der die Schlüssel rotieren kann, ohne dass Sie jemals das DNS anfassen müssen. SendGrid arbeitet mit einem ähnlichen Modell. Beide Ansätze funktionieren. Prüfen Sie daher, was Ihr Anbieter empfiehlt, bevor Sie davon ausgehen, dass TXT die einzige Option ist.

DKIM-Record prüfen und verifizieren

Sobald der Record live ist, brauchen Sie nur Ihren Domain-Namen und Selektor, um die Funktion zu bestätigen. Kostenlose Tools wie MxToolbox, EasyDMARC oder die Google Admin Toolbox übernehmen den Lookup für Sie.

• •

  Pass: Das Tool gibt den öffentlichen Schlüssel zurück und bestätigt die korrekte Formatierung

• •

  Fail: Record nicht gefunden, Syntaxfehler oder ein nicht übereinstimmender Selektor

Diese Prüfung einmal nach dem Setup durchzuführen ist sinnvoll. Sie manuell für jedes Postfach zu wiederholen, wird aber schnell mühsam. Genau hier kommt der Deliverability Hub von lemlist ins Spiel. Er überwacht DKIM und andere Authentifizierungseinträge über alle Ihre Sendedomains hinweg in einem einzigen Dashboard.

Häufige DKIM-Record-Fehler und wie Sie sie beheben

Die meisten DKIM-Fehler gehen auf eine Handvoll vorhersehbarer Ursachen zurück.

Falscher Selektor oder Record-Name

Ein Tippfehler im Selektor oder ein fehlendes ._domainkey. im Hostnamen macht den Record für empfangende Server unsichtbar. Vergleichen Sie den vollständigen Record-Namen Zeichen für Zeichen mit der Anleitung Ihres Anbieters.

Fehlender oder fehlerhafter öffentlicher Schlüssel

Längere Schlüssel werden manchmal in mehrere Strings aufgeteilt. Wenn Ihr DNS-Anbieter den Wert dabei kürzt, bricht der Schlüssel ohne sichtbare Fehlermeldung. Prüfen Sie, ob der gesamte Base64-String intakt ist. Das erspart Ihnen später viel Kopfzerbrechen.

Zu schwache Schlüssellänge

1024-Bit-Schlüssel waren jahrelang Standard, gelten inzwischen aber als grenzwertig gegenüber moderner Kryptoanalyse. Google, Microsoft, Yahoo und Amazon SES empfehlen mittlerweile 2048-Bit als Minimum.

DKIM-Signierung auf dem Server nicht aktiviert

Der DNS-Record sagt empfangenden Servern nur, wo sie nachschauen sollen. Wenn Ihr Sendeserver den ausgehenden E-Mails keine Signatur anhängt, bringt der Record allein nichts. Besonders bei Drittanbieter-Tools wird dieser Schritt leicht übersehen.

Wie DKIM mit SPF und DMARC zusammenspielt

DKIM arbeitet selten allein. Es ist eine Schicht in einem dreiteiligen Authentifizierungs-Stack:

• •

  SPF: bestätigt, dass die IP des sendenden Servers durch das DNS der Domain autorisiert ist

• •

  DKIM: bestätigt, dass die Nachricht nicht verändert wurde und die Signatur zum öffentlichen Schlüssel der Domain passt

• •

  DMARC: sagt empfangenden Servern, was zu tun ist, wenn SPF oder DKIM fehlschlägt, und verlangt, dass mindestens eines davon mit Domain-Alignment besteht

DKIM-Signaturen überstehen auch die E-Mail-Weiterleitung, was bei SPF oft nicht der Fall ist. Das macht DKIM zum stabileren Baustein für das DMARC-Alignment. Deshalb bietet die Kombination beider Verfahren den stärksten Schutz, statt sich nur auf eines zu verlassen.

Warum DKIM für die Cold-E-Mail-Deliverability entscheidend ist

Wer Outbound-Kampagnen betreibt, kommt an DKIM nicht mehr vorbei. Google und Yahoo verlangen von Massenversendern eine Authentifizierung mit SPF und DKIM plus einem DMARC-Record. Nicht konforme E-Mails werden abgewiesen. Über die reine Compliance hinaus fließt DKIM auch in den Aufbau der Domain-Reputation bei ISPs ein, zusammen mit niedrigen Spam-Beschwerden und gesundem Engagement.

Das korrekte Setup ist aber erst der Anfang. Authentifizierung braucht laufendes Monitoring, und neue Domains müssen schrittweise aufgewärmt werden. Der Deliverability Hub von lemlist bietet DKIM-Monitoring pro Postfach mit Alerts, wenn etwas nicht stimmt. Und jeder Sitzplatz enthält lemwarm, das auf Basis einer korrekt authentifizierten Domain die Absender-Reputation aufbaut, indem echte E-Mails in kontrolliertem Tempo ausgetauscht werden.