Was ist DKIM und warum ist es 2026 wichtig
DKIM (DomainKeys Identified Mail) ist ein E-Mail-Authentifizierungsstandard, definiert in RFC 6376, der einer sendenden Domain erlaubt, ausgehende Nachrichten kryptografisch zu signieren. Der Empfänger holt den passenden öffentlichen Schlüssel aus dem DNS, berechnet die Signatur neu und bestätigt, dass die Nachricht vom Domain-Inhaber autorisiert war und unterwegs nicht verändert wurde. Ohne DKIM kann ein Spoofer deine From-Adresse fälschen, deiner Sender-Reputation schaden und Antworten unbemerkt auf ähnlich aussehende Domains umleiten — ein Problem, das die meisten Teams erst bemerken, wenn die Zustellbarkeit zusammenbricht.
2026 ist DKIM nicht mehr optional. Die Bulk-Sender-Regeln von Gmail und Yahoo — durchgesetzt seit Februar 2024 und 2025 verschärft — verlangen von jeder Domain, die mehr als 5.000 Nachrichten pro Tag verschickt, gültige SPF, DKIM und DMARC. Microsoft 365 hat eine entsprechende Durchsetzung für Versender mit hohem Volumen angekündigt. Ein fehlschlagendes DKIM senkt nicht mehr nur die Inbox-Rate; es löst harte Rejects aus, dmarc=fail-Reports, und in vielen Fällen die Entfernung von der Allow-List des Empfängers. DKIM wöchentlich zu validieren ist die günstigste Zustellbarkeits-Versicherung, die du kaufen kannst.
Wie DKIM funktioniert — Public-/Private-Key-Kryptografie
DKIM basiert auf klassischer asymmetrischer Kryptografie. Wenn du DKIM einrichtest, generiert deine Mail-Plattform ein RSA-Schlüsselpaar: einen privaten Schlüssel, den sie auf dem Sende-Server behält, und einen öffentlichen, den du im DNS veröffentlichst. Jede ausgehende Nachricht wird gehasht (Body + ausgewählte Header), der Hash mit dem privaten Schlüssel verschlüsselt, und das Ergebnis als DKIM-Signature-Header angehängt. Der Empfänger holt deinen öffentlichen Schlüssel aus dem DNS, entschlüsselt die Signatur, berechnet den Hash der empfangenen Nachricht neu und vergleicht beide. Stimmen sie überein, besteht DKIM; tun sie es nicht, ist die Signatur kaputt und die Nachricht wird als verdächtig behandelt.
Der DKIM-Signature-Header trägt die Metadaten, die Empfänger zur Verifikation brauchen: v= (Version), a= (Algorithmus, normalerweise rsa-sha256), d= (Signing-Domain), s= (Selector), c= (Kanonisierung, normalerweise relaxed/relaxed), h= (signierte Header), bh= (Body-Hash) und b= (die Signatur). Zusammen sagen sie dem Empfänger genau, welchen DNS-Record er holen muss und welche Bytes abgedeckt waren.
Example DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=google;
h=from:to:subject:date:message-id;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=KX5vRn3...truncated...Was ist ein DKIM-Selector?
Ein DKIM-Selector ist ein kurzes Label, das einer einzelnen Domain erlaubt, mehrere DKIM-Schlüssel gleichzeitig zu veröffentlichen. Empfänger finden den öffentlichen Schlüssel, indem sie Selector und Signing-Domain zu einem DNS-Namen der Form selector._domainkey.domain.com kombinieren. Zum Beispiel nutzt Google Workspace google._domainkey.example.com, während eine Mailgun-signierte Nachricht nach k1._domainkey.example.com sucht. Selectors sind entscheidend, weil sie dir Schlüsselrotation, parallelen Betrieb verschiedener Sende-Plattformen (transactional, marketing, sales) und das Staging neuer Schlüssel vor der Stilllegung alter erlauben — ohne dass jemals zwei Records kollidieren. Es gibt keinen Wildcard oder Fallback bei _domainkey.domain.com selbst; der Selector ist Pflicht.
Example DNS record format:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."5 häufige DKIM-Fehler und wie du sie behebst
DNS-Lookup gibt nichts zurück
Der Empfänger hat selector._domainkey.deinedomain.com abgefragt und NXDOMAIN bekommen. Der häufigste DKIM-Fehlschlag. Ursachen: Der TXT-Record wurde nie veröffentlicht, unter dem falschen Selector veröffentlicht, oder am Apex (deinedomain.com) statt an der Selector-Subdomain hinzugefügt. Behebe es, indem du den exakten Namen, den dein Provider angegeben hat (z. B. google._domainkey), als TXT-Record neu veröffentlichst und mit dig TXT selector._domainkey.deinedomain.com oder erneutem Lauf dieses Checkers die Propagierung prüfst. Plane bis zu 48 Stunden für globale Propagierung ein.
Öffentlicher Schlüssel ungültig
DNS gibt einen Record zurück, aber der p=-Wert ist fehlerhaft, abgeschnitten oder vom Empfänger abgelehnt. Häufigste Ursache: ein 2048-Bit-Schlüssel, der über mehrere TXT-Strings aufgeteilt und falsch wieder zusammengesetzt wurde — viele DNS-UIs fügen verirrte Anführungszeichen, Leerzeichen oder Zeilenumbrüche hinzu. Behebe es, indem du den öffentlichen Schlüssel exakt so kopierst, wie ihn deine Mail-Plattform exportiert hat, ihn als einzelnen TXT-Wert einfügst (die meisten Provider splitten an der 255-Byte-Grenze automatisch) und bestätigst, dass der Record v=DKIM1; k=rsa; p=BASE64KEY ohne Whitespace im Base64-Block enthält.
Body-Hash-Mismatch
DKIM hat bh=ABC signiert, aber der Empfänger hat bh=XYZ aus dem empfangenen Body berechnet, also schlägt die Verifikation fehl. Das heißt, irgendetwas hat die Nachricht nach der Signierung verändert. Häufige Verdächtige: ein nachgelagertes Gateway (Anti-Virus, DLP, Mailing-Liste) schreibt Links um oder fügt einen Footer hinzu, ein SMTP-Relay re-encodiert Zeilenenden, oder ein Forwarder entfernt Anhänge. Behebe es, indem du mit relaxed/relaxed-Kanonisierung signierst (toleriert Whitespace-Änderungen), die umschreibende Middleware entfernst, oder — für Mailing-Listen — ARC implementierst, damit das ursprüngliche DKIM über Hops hinweg erhalten bleibt.
Signaturverifikation fehlgeschlagen
Der Body-Hash hat gestimmt, aber die kryptografische Signatur passt nicht zum öffentlichen Schlüssel. Ursachen: Der Sende-Server hat mit einem privaten Schlüssel signiert, der nicht mehr zum veröffentlichten öffentlichen passt (häufig nach einer Schlüsselrotation, bei der das DNS aktualisiert wurde, aber der Cache des Mail-Servers nicht), der öffentliche Schlüssel im DNS wurde editiert und korrumpiert, oder der Signing-Algorithmus in a= passt nicht zum Schlüsseltyp. Behebe es, indem du den öffentlichen Schlüssel von der sendenden Plattform neu exportierst, wortwörtlich neu veröffentlichst und den Mail-Service neu startest, damit er seinen privaten Schlüssel neu lädt.
Selector nicht gefunden / falsch
Dein Mail-Server signiert mit Selector s1, aber im DNS ist nur s2 veröffentlicht, oder du hast den Provider gewechselt und der alte Selector wurde stillgelegt. Behebe es, indem du das s=-Tag im DKIM-Signature-Header einer echten ausgehenden E-Mail prüfst (die meisten Clients lassen dich vollständige Header anzeigen), bestätigst, dass exakt unter diesem Selector ein TXT-Record existiert, und alle veralteten Selectors entfernst, die keinen passenden privaten Schlüssel mehr haben — alte Selectors mit leerem p=-Wert führen zu harten Fails.
Schritt-für-Schritt-DKIM-Setup
- 1
Schlüssellänge wählen (1024 vs 2048 Bit)
Wähle 2026 immer 2048-Bit-RSA. 1024-Bit-Schlüssel werden von den meisten Empfängern noch akzeptiert, aber Gmail, Yahoo und Microsoft markieren sie inzwischen aktiv als schwach in DMARC-Reports, und Security-Teams scheitern routinemäßig bei Audits, die 1024-Bit-DKIM in Produktion finden. Der einzige Grund, auf 1024 zu gehen, ist ein alter DNS-Provider, der keinen TXT-Record über 255 Bytes speichern kann — und auch von denen unterstützen heute fast alle Multi-String-TXT-Splitting. 2048-Bit-Schlüssel fügen ungefähr zwei Millisekunden Signing-Zeit hinzu, was für jeden Produktions-Mail-Server vernachlässigbar ist.
- 2
Schlüsselpaar generieren
Die meisten Plattformen generieren Schlüssel für dich — Google Workspace, Microsoft 365, Mailgun, SendGrid, Postmark und Amazon SES bieten alle eine One-Click-DKIM-Setup-Seite, die beide Hälften erzeugt und dir den öffentlichen Schlüssel zur Veröffentlichung zeigt. Wenn du deinen eigenen Server betreibst (Postfix + OpenDKIM, Exim oder Haraka), nutze opendkim-genkey -b 2048 -d deinedomain.com -s s1, was s1.private (geheim halten) und s1.txt (veröffentlichen) schreibt. Verwende einen Schlüssel niemals über Domains oder Plattformen hinweg erneut.
- 3
Öffentlichen Schlüssel als TXT-Record hinzufügen
Erstelle einen TXT-Record bei selector._domainkey.deinedomain.com — zum Beispiel s1._domainkey.example.com — mit dem Wert v=DKIM1; k=rsa; p=MIIBIjANBgkq..., aus der .txt-Datei eingefügt, die dein Generator erzeugt hat. Viele DNS-Provider splitten den Wert automatisch in 255-Byte-Chunks; das ist okay, Empfänger setzen sie wieder zusammen. Setze TTL während des Tests auf 3600 Sekunden und erhöhe auf 86400, sobald der Record stabil ist. Übernimm die umgebenden Anführungszeichen aus der Generator-Ausgabe nicht in den Wert.
- 4
Mail-Service zum Signieren mit dem privaten Schlüssel konfigurieren
Auf gehosteten Plattformen ist das automatisch, sobald du den DNS-Record veröffentlichst und auf Verify klickst. Auf selbst gehosteten Servern zeigst du deinen Milter (OpenDKIM, Rspamd) auf die .private-Datei, setzt den Selector passend zum DNS-Record und startest den Mail-Prozess neu. Schick eine Testnachricht an eine Gmail-Adresse und sieh dir den Quelltext an — du solltest einen Authentication-Results: dkim=pass header.d=deinedomain.com-Header sehen. Siehst du dkim=none, signiert der Server noch nicht; bei dkim=fail passen die Schlüssel nicht zusammen.
- 5
Mit einem kostenlosen DKIM-Checker testen
Nutze diesen DKIM-Checker, um die DNS-Veröffentlichung zu bestätigen, dann schick eine echte Testnachricht an mail-tester.com oder ein Gmail-Konto, das du kontrollierst, und prüfe die Header. Erwartet: Authentication-Results zeigt dkim=pass und der Selector passt zu deinem veröffentlichten Record. Teste nach jeder Schlüsselrotation, jeder neuen Sende-Plattform und mindestens einmal pro Quartal neu. Füge den Check zu deinem Monitoring-Tool hinzu, damit ein stiller DKIM-Fehler die Zustellbarkeit nicht wochenlang lahmlegen kann.
Häufige DKIM-Selectors nach Provider
Verschiedene E-Mail-Plattformen wählen jeweils ihre eigene Selector-Konvention. Die Konvention zu kennen macht Troubleshooting deutlich schneller — wenn du eine Nachricht von Google Workspace bekommst und DKIM kaputt ist, weißt du schon, dass du google._domainkey nachschlagen musst, bevor du fünfzig Alternativen scannst. Hier die Selectors, die die wichtigsten Provider 2026 nutzen:
Google Workspace — google._domainkey.deinedomain.comMailgun — k1._domainkey.deinedomain.com (manchmal mta._domainkey)SendGrid — s1._domainkey.deinedomain.com und s2._domainkey.deinedomain.com (CNAME-basiert)Mailchimp — k1._domainkey.deinedomain.com und k2._domainkey.deinedomain.comMicrosoft 365 — selector1._domainkey.deinedomain.com und selector2._domainkey.deinedomain.comPostmark — pm._domainkey.deinedomain.com (oder 20XXXXXXX.pm._domainkey)Amazon SES — eigene zufällige Selectors wie abc123._domainkey.deinedomain.com (CNAME-basiert)Mandrill (von Mailchimp) — mandrill._domainkey.deinedomain.comConstant Contact — ctct1._domainkey.deinedomain.com und ctct2._domainkey.deinedomain.comConvertKit — ck._domainkey.deinedomain.comMailjet — mailjet._domainkey.deinedomain.comBrevo (vormals Sendinblue) — mail._domainkey.deinedomain.com
Der DKIM-Checker von Nova Uptime scannt alle oben genannten Selectors plus 38 weitere parallel, du musst also nicht im Voraus wissen, welchen dein Provider nutzt.
Gmail- und Yahoo-Anforderungen 2026
Seit Februar 2024 setzen Gmail und Yahoo strengere Authentifizierung für jede Domain durch, die mehr als 5.000 Nachrichten pro Tag an ihre Nutzer schickt. Die Regeln: Jede Nachricht muss mit einem gültigen DKIM-Record (2048-Bit empfohlen) signiert sein, SPF muss mit der From-Domain ausgerichtet sein und eine DMARC-Policy muss veröffentlicht sein — minimal p=none — mit erreichbarer rua=-Reporting-Adresse. Im Lauf von 2025 und in 2026 haben beide Provider die Volumenschwelle gesenkt und angefangen, Nachrichten direkt abzuweisen (5.7.26), statt sie in Spam zu routen. Microsoft 365 hat im Mai 2025 mit entsprechender Durchsetzung begonnen. Praktischer Effekt: Ein einziger kaputter DKIM-Record führt jetzt zu Hard-Bounces, nicht nur zu Inbox-Placement-Problemen, und die Wiederherstellung dauert Tage, weil DMARC-Reports 24 Stunden nachhängen. Kontinuierliches Monitoring ist nicht mehr optional.