DKIM einrichten: Schlüssel erzeugen und DNS-Eintrag setzen

DKIM steht für DomainKeys Identified Mail. Der sendende Server setzt eine digitale Signatur in den Kopf jeder Mail, und der empfangende Server prüft sie mit einem öffentlichen Schlüssel, den er im DNS der Domain findet ^[1]. Stimmt die Signatur, weiß der Empfänger zweierlei: Die Domain hat die Mail tatsächlich signiert, und die signierten Teile wurden unterwegs nicht verändert. Dieser Ratgeber zeigt, wie der DNS-Eintrag aufgebaut ist, wie du ihn bei den großen Anbietern und am eigenen Server einrichtest und wie du später den Schlüssel wechselst. Wie DKIM mit SPF und DMARC zusammenspielt, erklärt SPF, DKIM und DMARC im Zusammenspiel.

So funktioniert die Signatur

Der Mailserver des Absenders besitzt einen privaten Schlüssel. Damit berechnet er für jede ausgehende Nachricht eine Signatur über ausgewählte Kopfzeilen und den Text und schreibt das Ergebnis in die Kopfzeile DKIM-Signature. Darin stehen unter anderem die signierende Domain im Feld d= und der Selektor im Feld s= ^[1]. Der empfangende Server setzt aus beiden einen DNS-Namen zusammen. Bei d=example.com und s=brisbane fragt er nach brisbane._domainkey.example.com, holt dort den öffentlichen Schlüssel und prüft die Signatur ^[1].

Weil die Signatur an der Nachricht hängt, übersteht sie in der Regel auch Weiterleitungen. RFC 9989 beschreibt den Fall einer Adresse, die Mails an ein anderes Postfach weiterreicht: SPF schlägt dann meist fehl, weil die Mail von der IP-Adresse des Weiterleiters kommt, die DKIM-Signatur bleibt aber gültig ^[4].

Der Selektor

Eine Domain kann mehrere DKIM-Schlüssel gleichzeitig haben. Damit der Empfänger weiß, welcher gemeint ist, gibt es den Selektor. RFC 6376 nennt als Beispiele Namen von Standorten oder Monatsangaben wie "january2005" ^[1]. Den Namen wählst du frei, er muss nur als DNS-Name gültig sein. Viele Domains kommen mit einem einzigen Selektor aus. Mehrere Selektoren lohnen sich, wenn verschiedene Systeme für dieselbe Domain senden, etwa das Postfach beim Mailanbieter und ein Newsletterdienst. Jedes System bekommt dann einen eigenen Schlüssel.

Google Workspace schlägt als Selektor "google" vor ^[5]. Microsoft 365 verwendet immer die beiden Selektoren selector1 und selector2 ^[6]. Welchen Selektor ein Dienst nutzt, siehst du im Quelltext einer Mail, die er verschickt hat: im Wert s= der Kopfzeile DKIM-Signature ^[5].

Aufbau des DNS-Eintrags

Der öffentliche Schlüssel steht in einem TXT-Eintrag. Sein Inhalt ist eine Liste von Feldern in der Form name=wert, getrennt durch Semikolons ^[1]. Ein typischer Eintrag sieht so aus: v=DKIM1; k=rsa; p=MIIBIjANBgkq… (gekürzt). Die wichtigsten Felder:

Die Angaben stammen aus RFC 6376, Abschnitt 3.6.1; den Typ ed25519 hat RFC 8463 ergänzt ^{[1, 3]}. Ein 2048-Bit-Schlüssel ist als Base64-Text länger als 255 Zeichen. Eine einzelne Zeichenkette in einem TXT-Eintrag darf aber höchstens 255 Bytes lang sein. Der Eintrag wird deshalb in mehrere Zeichenketten aufgeteilt, die der Empfänger ohne Leerzeichen wieder zusammensetzt ^[1]. Die meisten Verwaltungsoberflächen erledigen das selbst. Google weist darauf hin, dass manche Domainanbieter die Länge von TXT-Einträgen begrenzen ^[5].

Unter einem Selektor darf nur ein TXT-Eintrag stehen. Gibt es dort mehrere, ist das Ergebnis laut RFC 6376 undefiniert ^[1].

Schlüssellänge und Verfahren

RFC 8301 hat 2018 die Regeln verschärft. Signiert wird mit rsa-sha256, das ältere rsa-sha1 darf weder zum Signieren noch zum Prüfen verwendet werden. RSA-Schlüssel müssen mindestens 1024 Bit lang sein und sollen mindestens 2048 Bit haben. Prüfende Server müssen Schlüssel von 1024 bis 4096 Bit verarbeiten können und dürfen Signaturen mit kürzeren Schlüsseln nicht als gültig werten ^[2].

Gmail verlangt für Mails an private Konten einen DKIM-Schlüssel mit mindestens 1024 Bit und empfiehlt 2048 Bit, wenn der Domainanbieter das unterstützt ^[7]. Yahoo nennt ebenfalls 1024 Bit als Mindestlänge ^[8]. Wenn du die Wahl hast, nimm 2048 Bit.

Seit RFC 8463 gibt es zusätzlich das Verfahren Ed25519-SHA256. Sein öffentlicher Schlüssel ist nur 44 Zeichen lang und passt in eine einzige TXT-Zeichenkette ^[3]. Eine Mail kann mehrere voneinander unabhängige Signaturen tragen; das Beispiel in RFC 8463 zeigt eine Nachricht mit einer RSA- und einer Ed25519-Signatur ^[3]. Wer Ed25519 nutzt, signiert deshalb sinnvollerweise zusätzlich mit RSA.

Schritt für Schritt am eigenen Server

Betreibst du den Mailserver selbst oder verwendest einen Dienst ohne fertige DKIM-Einstellung, sieht der Ablauf so aus:

1. Selektor festlegen, zum Beispiel mail oder ein Datum.
2. Schlüsselpaar erzeugen: RSA mit 2048 Bit. Mailserver-Software bringt dafür meist ein eigenes Werkzeug mit.
3. Den privaten Schlüssel in der Konfiguration des Mailservers hinterlegen. Er bleibt auf dem Server und wird nie veröffentlicht.
4. In der DNS-Verwaltung einen TXT-Eintrag mit dem Namen selektor._domainkey anlegen und als Wert v=DKIM1; k=rsa; p= gefolgt vom öffentlichen Schlüssel eintragen ^[5].
5. Warten, bis der Eintrag ausgeliefert wird. Mit dem DNS-Check kannst du den TXT-Eintrag abfragen. Wie lange das dauert, hängt von der TTL ab.
6. Erst dann die Signatur im Mailserver einschalten.
7. Testen: eine Mail an ein Postfach bei einem anderen Anbieter schicken und im Quelltext die Kopfzeile Authentication-Results suchen. Dort sollte dkim=pass stehen ^[5].

Manche Oberflächen ergänzen den Domainnamen automatisch. Trägst du dort mail._domainkey.beispiel.de ein, entsteht leicht mail._domainkey.beispiel.de.beispiel.de. In Zonendateien gilt ein Name ohne Punkt am Ende als relativ und wird um den Namen der Zone ergänzt ^[9]. Gib im Feld für den Namen deshalb nur den Teil vor der Domain ein, wenn die Oberfläche die Domain selbst anhängt.

Google Workspace und Microsoft 365

In Google Workspace erzeugst du den Schlüssel in der Admin-Konsole unter Apps, Google Workspace, Gmail, E-Mail authentifizieren. Nach dem Aktivieren von Gmail musst du 24 bis 72 Stunden warten, bevor die Konsole einen Schlüssel erstellen kann. Zur Wahl stehen 2048 und 1024 Bit, als Selektor ist "google" voreingestellt. Die Konsole zeigt dann den Namen google._domainkey und den Wert v=DKIM1; k=rsa; p=… an, die du bei deinem Domainanbieter als TXT-Eintrag anlegst. Bis die Prüfung funktioniert, kann es bis zu 48 Stunden dauern. Danach klickst du in der Konsole auf "Authentifizierung starten" ^[5].

Microsoft 365 geht einen anderen Weg. Für eine eigene Domain legst du zwei CNAME-Einträge an, selector1._domainkey und selector2._domainkey. Sie zeigen auf Namen bei Microsoft, unter denen die öffentlichen Schlüssel liegen; die privaten Schlüssel hält Microsoft unter Verschluss ^[6]. Seit Mai 2025 verwenden neu hinzugefügte Domains ein Format, das auf dkim.mail.microsoft endet; ältere Domains behalten das Format mit onmicrosoft.com. Die genauen Zielwerte zeigt das Defender-Portal oder der PowerShell-Befehl Get-DkimSigningConfig an ^[6]. Wer Mails nur über die Startdomain auf onmicrosoft.com verschickt, muss nichts einrichten; diese Mails signiert Microsoft automatisch ^[6].

Schlüssel wechseln

Ein Schlüssel sollte nicht ewig gelten. Microsoft vergleicht den Wechsel mit dem regelmäßigen Ändern von Passwörtern ^[6]. RFC 6376 beschreibt, wie das ohne Unterbrechung geht: Du veröffentlichst den neuen Schlüssel unter einem neuen Selektor, während der alte noch im DNS steht. Dann stellst du den Server auf den neuen Schlüssel um. Den alten Eintrag entfernst du erst, wenn keine Mails mit der alten Signatur mehr unterwegs sein können ^[1].

In Microsoft 365 übernimmt der Befehl Rotate-DkimSigningConfig den Wechsel zwischen selector1 und selector2, auf Wunsch zusammen mit dem Umstieg auf 2048 Bit. Der neue Schlüssel signiert dort erst nach vier Tagen (96 Stunden) ^[6].

Ist ein privater Schlüssel in falsche Hände geraten oder endet der Vertrag mit einem Versanddienst, kannst du den Schlüssel widerrufen. Dazu lässt du den Eintrag stehen und leerst das Feld p=. Signaturen mit diesem Selektor schlagen dann fehl ^[1].

DKIM und DMARC

Eine gültige DKIM-Signatur allein sagt nur, dass irgendeine Domain die Mail signiert hat. Für DMARC muss die signierende Domain aus d= zur Domain in der Absenderzeile passen. Bei der üblichen lockeren Prüfung reicht es, wenn beide dieselbe registrierte Domain haben; news.beispiel.de passt also zu beispiel.de ^[4]. Signiert ein Newsletterdienst mit seiner eigenen Domain, ist die Signatur zwar gültig, hilft aber nicht bei DMARC. Richte beim Dienst deshalb DKIM mit deiner eigenen Domain ein. Für Domains mit p=reject verlangt RFC 9989 ausdrücklich gültige DKIM-Signaturen, weil SPF bei Weiterleitungen versagt ^[4]. Empfänger sollen Mails trotzdem nicht allein wegen p=reject ablehnen; ohne weitere Prüfung behandeln sie sie wie bei p=quarantine ^[4]. Mehr dazu unter DMARC-Eintrag setzen und Berichte lesen.

Typische Fehler

• Testmodus vergessen: Steht t=y im Eintrag, müssen Empfänger signierte Mails so behandeln wie unsignierte, auch wenn die Signatur nicht stimmt ^[1]. Nimm das Feld heraus, sobald alles läuft.
• Ein Gateway ändert die Mail nach dem Signieren: Google nennt als Beispiel Ausgangsgateways, die jeder Nachricht eine Fußzeile anhängen ^[5]. Dann passt die Signatur nicht mehr zum Text.
• Schlüssel zu kurz: Signaturen mit RSA-Schlüsseln unter 1024 Bit gelten als ungültig ^[2].
• Zwei TXT-Einträge unter demselben Selektor, etwa nach einem Anbieterwechsel ^[1].
• Schlüssel beim Kopieren abgeschnitten oder mit Zeilenumbrüchen eingefügt: Die Signatur lässt sich dann nicht prüfen.

Bleiben Mails trotz gültiger Signatur im Spam hängen, helfen die Hinweise unter Eigene E-Mails landen im Spam. Wie Empfänger gefälschte Absender erkennen, steht auf Gefälschte Absender erkennen.

1. Gesetz RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. IETF. Stand September 2011. abgerufen am 29.10.2026
2. Gesetz RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM. IETF. Stand Januar 2018. abgerufen am 29.10.2026
3. Gesetz RFC 8463: A New Cryptographic Signature Method for DKIM. IETF. Stand September 2018. abgerufen am 29.10.2026
4. Gesetz RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC). IETF. Stand Mai 2026. abgerufen am 29.10.2026
5. Organisation DKIM einrichten. Google. Stand ohne Datum. abgerufen am 29.10.2026
6. Organisation Verwenden von DKIM für E-Mail in Ihrer benutzerdefinierten Domäne. Microsoft. Stand 03.07.2026. abgerufen am 29.10.2026
7. Organisation Richtlinien für E-Mail-Absender. Google. Stand ohne Datum. abgerufen am 29.10.2026
8. Organisation Sender Requirements and Recommendations. Yahoo. Stand ohne Datum. abgerufen am 29.10.2026
9. Gesetz RFC 1035: Domain Names, Implementation and Specification, Abschnitt 5.1. IETF. Stand November 1987. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.