DKIM einrichten: Selektor, Schlüssel und DNS-Record

Wie DKIM funktioniert

DKIM nach RFC 6376 ist eine digitale Signatur über ausgewählte Header und den Body einer Mail. Der sendende Server signiert mit einem privaten Schlüssel und hängt das Ergebnis als Header DKIM-Signature an. Darin stehen unter anderem die signierende Domain (d=), der Selektor (s=) und die Liste der signierten Header (h=).

Der Empfänger liest d= und s= aus der Signatur, holt den öffentlichen Schlüssel aus dem TXT-Record unter selektor._domainkey.domain und prüft die Signatur. Stimmt sie, weiß er, dass die Mail von jemandem mit Zugriff auf den privaten Schlüssel der Domain stammt und seitdem nicht verändert wurde. Anders als SPF ist die Prüfung unabhängig davon, welcher Server die Mail zuletzt eingeliefert hat.

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

Selektoren wählen

Der Selektor ist ein frei wählbarer Name, der es erlaubt, mehrere Schlüssel gleichzeitig unter einer Domain zu veröffentlichen. Jeder Absender bekommt seinen eigenen: Microsoft 365 nutzt selector1 und selector2, Google Workspace standardmäßig google, Newsletter-Tools geben Namen wie k1 oder s1 vor. Für eigene Server nimmst du etwas Sprechendes mit Datum oder Jahr, etwa mail2026a, das erleichtert später die Rotation.

Weil Selektoren unabhängig voneinander sind, können beliebig viele Dienste für dieselbe Domain signieren, ohne sich in die Quere zu kommen. Das ist der große Unterschied zu SPF mit seinem einen Record und dem Lookup-Limit.

Schlüssellänge: 2048 Bit

RFC 8301 verlangt von Empfängern, RSA-Schlüssel zwischen 1024 und 4096 Bit zu prüfen, und empfiehlt Absendern mindestens 2048 Bit. 1024 Bit gilt als zu schwach und wird von manchen Empfängern bereits abgewertet. 4096 Bit ist kryptografisch nicht nötig und erzeugt einen p=-Wert von rund 700 Zeichen, den einige DNS-Anbieter und Mailsysteme nicht sauber verarbeiten.

Ein 2048-Bit-Schlüssel ergibt einen Record von etwa 400 Zeichen. Das ist länger als die 255 Zeichen, die ein einzelner TXT-String haben darf. DNS erlaubt mehrere Strings in einem Record, die der Empfänger aneinanderhängt. Ein guter DNS-Editor macht das automatisch, ein schlechter schneidet ab oder setzt Anführungszeichen mitten in den Schlüssel.

s1._domainkey.beispiel.de.  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx2f...ersteHaelfte"
                                    "zweiteHaelfte...IDAQAB" )

CNAME-Delegation bei Dienstleistern

Die meisten Dienste wollen den Schlüssel selbst verwalten und rotieren. Dafür legst du keinen TXT-Record mit dem Schlüssel an, sondern einen CNAME, der auf einen Hostnamen des Anbieters zeigt. Microsoft 365, SendGrid, Mailchimp und Amazon SES arbeiten so. Google Workspace gibt dir dagegen einen fertigen TXT-Record zum Eintragen.

Der Vorteil der Delegation: Der Anbieter kann Schlüssel tauschen, ohne dass du etwas tun musst. Der Nachteil: Der DKIM-Record ist nur so lange gültig, wie das CNAME-Ziel existiert. Kündigt der Kunde den Dienst, bleibt ein CNAME ins Leere zurück, und die Signatur kann nicht mehr geprüft werden.

selector1._domainkey.beispiel.de.  CNAME  selector1-beispiel-de._domainkey.tenant.onmicrosoft.com.
s1._domainkey.beispiel.de.         CNAME  s1.domainkey.u1234567.wl123.sendgrid.net.

Testmodus, Rotation und Widerruf

Mit dem Tag t=y markierst du einen Schlüssel als im Test. Empfänger prüfen die Signatur, sollen aber ein Fehlschlagen nicht anders behandeln als eine fehlende Signatur. Das ist nützlich, wenn du einen eigenen Server neu signieren lässt und noch nicht sicher bist, ob die Header-Kanonisierung passt. Vergiss nicht, t=y wieder zu entfernen, denn im Testmodus zählt DKIM für manche Empfänger nicht als vollwertig.

Schlüssel sollten regelmäßig rotiert werden, weil ein privater Schlüssel auf einem Server liegt und Server kompromittiert werden. Die Rotation ist einfach, weil Selektoren beliebig sind: Neuen Schlüssel unter neuem Selektor veröffentlichen, Signierung umstellen, alten Record einige Tage stehen lassen, bis alle unterwegs befindlichen Mails geprüft sind, dann entfernen. Zum expliziten Widerruf veröffentlichst du einen Record mit leerem p=, das signalisiert Empfängern, dass der Selektor bewusst ungültig ist.

Widerrufener Schlüssel:
mail2024a._domainkey.beispiel.de.  TXT  "v=DKIM1; p="

Typische Fehler

Die meisten DKIM-Probleme liegen im DNS, nicht auf dem Mailserver. Bevor du auf dem Server suchst, prüfe den veröffentlichten Record mit dem DMARC Checker, der zeigt, ob der Selektor auflösbar und der Schlüssel gültig ist.

• Falsch gesplitteter Schlüssel: Anführungszeichen oder Leerzeichen mitten im p=-Wert, weil der DNS-Editor die 255-Zeichen-Grenze falsch behandelt hat
• Falscher Selektor: Der Server signiert mit s=mail, im DNS steht aber s1._domainkey
• Record am falschen Ort: Der Selektor gehört unter selektor._domainkey.beispiel.de, nicht unter _domainkey.beispiel.de oder auf den Apex
• v=DKIM1 fehlt oder steht nicht am Anfang: Der Tag ist laut RFC empfohlen, wenn er vorhanden ist, muss er zuerst stehen; viele Prüfer erwarten ihn
• Öffentlicher Schlüssel mit Kopfzeilen: Nur der Base64-Block gehört in p=, nicht BEGIN PUBLIC KEY
• CNAME und TXT gleichzeitig auf demselben Namen, was DNS nicht erlaubt
• DKIM im Anbieter-Portal angelegt, aber nie aktiviert, sodass gar nicht signiert wird

Alignment mit DMARC

Für DMARC zählt DKIM nur, wenn die d=-Domain der Signatur zur From-Domain passt. Viele Dienste signieren standardmäßig mit ihrer eigenen Domain, das ergibt DKIM pass, aber DMARC fail. Erst wenn du im Anbieter-Portal eine eigene Sending Domain einrichtest und den zugehörigen Record veröffentlichst, signiert der Dienst mit d=beispiel.de.

Bei relaxed Alignment genügt es, wenn d= eine Subdomain oder die Organisationsdomain ist. Ein Newsletter mit From auf news.beispiel.de und Signatur d=beispiel.de ist aligned. Das erlaubt es, jeden Dienst mit eigenem Selektor unter der Hauptdomain signieren zu lassen, während die Absenderadressen sauber getrennt bleiben.

1. Beim Dienst die Domain hinzufügen und den vorgegebenen Selektor mit Record oder CNAME-Ziel notieren.
2. Record im DNS anlegen, bei TXT auf die korrekte Aufteilung über 255 Zeichen achten.
3. Nach Ablauf der TTL den Selektor mit dem DMARC Checker prüfen.
4. DKIM im Portal des Dienstes aktivieren und eine Testmail an ein Postfach bei Google oder Microsoft senden.
5. Im Header Authentication-Results dkim=pass mit der richtigen Domain kontrollieren.
6. In den DMARC-Reports der nächsten Tage prüfen, ob der Absender jetzt aligned pass liefert.

Häufige Fragen

Brauche ich DKIM, wenn SPF schon passt?

Ja. SPF bricht bei jeder Weiterleitung, und bei vielen Diensten ist SPF-Alignment gar nicht möglich, weil sie ihren eigenen Return-Path verwenden. Für ein stabiles DMARC p=reject ist DKIM bei allen Absendern Pflicht.

Kann ich einen Schlüssel für mehrere Domains verwenden?

Technisch ja, wenn du denselben öffentlichen Schlüssel unter jeder Domain veröffentlichst. Empfehlenswert ist es nicht, weil ein kompromittierter Schlüssel dann alle Domains betrifft. Pro Domain und Dienst ein eigener Schlüssel ist sauberer.

Was bedeutet dkim=neutral oder dkim=policy in den Prüfergebnissen?

neutral heißt meist, dass die Signatur syntaktisch unbrauchbar war oder der Schlüssel im Testmodus steht. policy bedeutet, dass der Empfänger die Signatur aus eigenen Gründen nicht akzeptiert, etwa wegen zu kurzer Schlüssel oder SHA-1. In beiden Fällen lohnt ein Blick auf Schlüssellänge und Record.