DKIM einrichten: Selector, 2048-Bit-Schlüssel, DNS-Eintrag

Ein falsch kopierter DKIM-Schlüssel fällt niemandem auf. Die Mails gehen raus, landen meistens sogar im Posteingang, und erst wenn du DMARC auf reject stellst, fehlen plötzlich die Rechnungen des Buchhaltungstools. Deshalb lohnt es sich, beim DKIM-Einrichten ein paar Minuten länger zu prüfen.

Wie DKIM funktioniert

DKIM (DomainKeys Identified Mail, RFC 6376) signiert ausgehende Mails mit einem privaten Schlüssel. Die Signatur steht im Header DKIM-Signature und deckt den Body und eine Liste von Headern ab, typischerweise From, Subject, Date und To. Der Empfänger liest zwei Werte aus der Signatur, die Domain (d=) und den Selector (s=), und holt sich damit den öffentlichen Schlüssel aus dem DNS:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beispiel.de; s=s2026;
  h=from:to:subject:date:message-id; bh=…; b=…

Hier fragt der Empfänger s2026._domainkey.beispiel.de ab. Passt die Signatur, ist belegt, dass die Mail von jemandem mit Zugriff auf den privaten Schlüssel kommt und unterwegs nicht verändert wurde.

Anders als SPF übersteht DKIM in der Regel Weiterleitungen, solange niemand den Inhalt ändert. Mailinglisten, die Betreffzeilen umschreiben oder Fußzeilen anhängen, brechen die Signatur trotzdem.

DKIM-Selector: einer pro Dienst

Ein häufiger Gedanke ist, ein Schlüssel müsse für die ganze Domain reichen. Das Gegenteil ist sinnvoll. Gib jedem Versender einen eigenen Selector:

Fliegt ein Dienst raus, löschst du genau dessen Record, und nichts anderes ist betroffen. Bei Microsoft 365 und vielen Newsletter-Diensten zeigt der Selector per CNAME auf einen Record beim Anbieter. Der rotiert die Schlüssel dann selbst, du musst nichts tun.

Schlüssellänge: warum 2048 Bit

RFC 8301 legt fest, dass Signierer RSA-Schlüssel mit mindestens 1024 Bit verwenden müssen und 2048 Bit verwenden sollten. Google schreibt in seinen Absenderrichtlinien für Gmail ebenfalls: mindestens 1024, empfohlen 2048, sofern der DNS-Anbieter das unterstützt.

Der Haken ist die Länge. Ein 2048-Bit-Schlüssel ergibt in Base64 rund 400 Zeichen, ein einzelner TXT-String darf aber nur 255 haben. Der Record wird deshalb in zwei Strings aufgeteilt, die der Empfänger zusammensetzt:

s2026._domainkey.beispiel.de. 3600 IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3x…"
                                             "…kQIDAQAB" )

Gute DNS-Oberflächen teilen automatisch. Manche ältere schneiden stattdessen ab, und dann ist die Signatur ungültig. Das siehst du sofort bei der Abfrage, wenn der Schlüssel nicht auf IDAQAB endet (das ist bei RSA mit Exponent 65537 der Standard-Abschluss).

Ed25519-Schlüssel (RFC 8463) wären deutlich kürzer, werden aber nicht von allen Empfängern geprüft. Wer sie nutzt, signiert zusätzlich mit RSA.

DKIM einrichten auf einem eigenen Mailserver

Bei gehosteten Diensten klickst du dich durch die Oberfläche. Auf einem eigenen Server erzeugst du das Schlüsselpaar selbst:

openssl genrsa -out s2026.private 2048
openssl rsa -in s2026.private -pubout -outform der 2>/dev/null | openssl base64 -A

Die zweite Zeile gibt den öffentlichen Schlüssel als eine lange Base64-Zeile aus. Die setzt du hinter p= in den TXT-Record. Den privaten Schlüssel bekommt nur der signierende Dienst (OpenDKIM, rspamd o. Ä.), mit Leserechten ausschließlich für dessen Benutzer.

Danach prüfst du, ob der Record ankommt:

$ dig +short TXT s2026._domainkey.beispiel.de
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3x…" "…kQIDAQAB"

Ein leeres p= bedeutet: Dieser Schlüssel ist widerrufen. Das nutzen manche Domains bewusst. Bei example.com antwortet jeder beliebige Selector so:

$ dig +short TXT google._domainkey.example.com
"v=DKIM1; p="

Signatur in einer echten Mail prüfen

Schicke eine Testmail an ein Gmail- oder Outlook-Konto und öffne den Quelltext (bei Gmail: drei Punkte, „Original anzeigen“). Entscheidend ist die Zeile Authentication-Results:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=s2026 header.b=Ab3xY9…;
       spf=pass (google.com: domain of [email protected] designates 203.0.113.10 as permitted sender);
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=beispiel.de

Steht bei header.i oder header.d eine fremde Domain, etwa die des Newsletter-Anbieters, signiert der Dienst noch mit seinem eigenen Schlüssel. Für DMARC zählt das nicht. In fast jedem Tool gibt es dafür einen Menüpunkt wie „Domain authentifizieren“ oder „eigene Absenderdomain“.

Typische DKIM-Fehler

• dkim=neutral (body hash did not verify): Der Inhalt wurde nach dem Signieren verändert. Häufigster Grund: ein Virenscanner oder Disclaimer-Tool, das nach der Signierung eine Fußzeile anhängt.
• dkim=temperror oder no key for signature: Der Record existiert nicht oder ist noch nicht propagiert. Signierung zu früh aktiviert.
• dkim=fail (bad signature): Meist ein abgeschnittener oder falsch kopierter Schlüssel, oft mit einem Zeilenumbruch mittendrin.
• Signatur deckt den From-Header nicht ab: Kommt bei selbstgebauten Setups vor. RFC 6376 verlangt, dass From signiert wird.

DKIM allein sagt dem Empfänger noch nicht, was er mit unsignierten Mails tun soll. Das regelt erst die Richtlinie, wenn du DMARC einrichten gehst. Die Gegenseite, also welche Server überhaupt senden dürfen, steht im Artikel SPF-Record einrichten.

Schlüssel wechseln ohne Ausfall

Mit Selectors ist die Rotation einfach. Lege einen neuen Selector an (s2027), veröffentliche dessen Record, warte die TTL ab und stelle die Signierung um. Den alten Record lässt du noch ein paar Tage stehen, weil Mails in Warteschlangen mit dem alten Selector unterwegs sein können. Danach setzt du ihn auf p= oder löschst ihn.

Rotation, neue Selectors, CNAMEs für Dienste: Das alles passiert in der DNS-Zone deiner Domain. Wenn du deine Mail-Domain bisher beim Webhoster „mitgemietet“ hast und dort keinen Zugriff auf TXT-Records bekommst, ist es Zeit für einen Umzug. Bei betadomain siehst du in der Preisübersicht aller Endungen, was eine Domain mit voller DNS-Verwaltung pro Jahr kostet, und kannst den Wunschnamen für deine Mail-Adresse prüfen. Wer eine .eu bevorzugt, findet sie auf der Seite zur .eu-Endung für 10,99 € im Jahr. Wie du danach Mails mit deiner Domain gegen Fälschung absicherst, zeigt E-Mail-Spoofing verhindern.

Schritt für Schritt

1. Versender und Selector festlegenLege für jeden Dienst, der in deinem Namen sendet, einen eigenen Selector fest oder übernimm den vom Anbieter vorgegebenen, etwa google bei Google Workspace oder selector1 und selector2 bei Microsoft 365.
2. Schlüssel erzeugenLass den Dienst einen 2048-Bit-Schlüssel erzeugen. Bei einem eigenen Mailserver erzeugst du ihn mit openssl genrsa und exportierst den öffentlichen Teil als Base64.
3. DNS-Record anlegenLege unter selector._domainkey.deinedomain.de einen TXT-Record mit v=DKIM1; k=rsa; p=… an, oder einen CNAME, wenn der Dienst das so vorgibt.
4. Signierung aktivierenStarte die Signierung erst im Dienst, wenn der DNS-Eintrag weltweit sichtbar ist. Prüfe das vorher mit dig +short TXT selector._domainkey.deinedomain.de.
5. Testmail auswertenSchicke eine Mail an ein externes Postfach und suche im Quelltext nach dkim=pass header.d=deinedomain.de. Steht dort eine fremde Domain, signiert der Dienst noch nicht mit deiner.