1. Versandquellen und Absender festhalten
DKIM versieht eine E-Mail mit einer digitalen Signatur. Der private Schlüssel bleibt im Versandsystem, der öffentliche Schlüssel ist über DNS abrufbar. Eine gültige Signatur ordnet die Nachricht einer Domain zu und schützt die signierten Bestandteile vor unbemerkten Änderungen. Sie verschlüsselt den Inhalt nicht.
Beginnen Sie mit den Systemen, nicht mit dem DNS-Formular. Ein Shop kann Bestellbestätigungen selbst versenden, Newsletter über einen zweiten Dienst und Supportnachrichten über einen dritten. Für jede Quelle brauchen Sie eine eigene Testnachricht und einen Ansprechpartner.
| Quelle | Sichtbarer Absender | Gewünschte DKIM-Domain | Verantwortlich |
|---|---|---|---|
| Newsletter | news@example.com | news.example.com oder example.com | Marketing und Versanddienst |
| Shop | bestellung@example.com | example.com oder eigene Shop-Subdomain | Shop-Team |
| Mitarbeiterpostfach | service@example.com | example.com | IT / Mailadministration |
Die DKIM-Domain steht später im Parameter d=. Für DMARC muss eine erfolgreich geprüfte DKIM- oder SPF-Domain zur sichtbaren From-Domain passen. Stimmen Sie diese Wahl ab, bevor mehrere Teams unabhängig Subdomains anlegen.
2. Die Einträge im richtigen Anbieter abrufen
Nutzen Sie die Werte aus Ihrem tatsächlichen Konto. Ein Beispiel aus einer Anleitung enthält weder Ihren Schlüssel noch das richtige Ziel für Ihren Mandanten. Ein Dienst kann TXT verlangen, ein anderer CNAME. Bei CNAME verwaltet der Dienst den dahinterliegenden Schlüssel.
| Dienst | Wo beginnen? | Was in DNS gehört |
|---|---|---|
| Google Workspace | Admin-Konsole: Apps > Google Workspace > Gmail > E-Mail authentifizieren. Domain auswählen und neuen Eintrag erzeugen. | Ein TXT-Eintrag mit öffentlichem Schlüssel. Danach die Authentifizierung in Google starten. |
| Microsoft 365 | DKIM-Konfiguration der eigenen Domain in Microsoft Defender aufrufen. | Zwei CNAME mit den im Mandanten gezeigten Zielwerten. Danach DKIM aktivieren. |
| Mailchimp | Eigene Domain verifizieren, dann die Domain-Authentifizierung öffnen. | Bei manueller Einrichtung zwei DKIM-CNAME. Einen bestehenden DMARC-Eintrag prüfen, bevor Sie einen neuen anlegen. |
| HubSpot | Einstellungen > Content > Domains & URLs > Email Sending > Domain verbinden. | Zwei DKIM-CNAME; weitere angezeigte SPF-/DMARC-Anforderungen separat prüfen. |
| Brevo | Authentifizierung der Versanddomain im eigenen Konto öffnen. | Je nach Kontokonfiguration zwei DKIM-CNAME oder ein DKIM-TXT. Brevo-Code und DMARC sind zusätzliche Einträge. |
Bei Google wählen Sie, sofern Ihr DNS-Anbieter das unterstützt, einen RSA-Schlüssel mit 2048 Bit. Bei Microsoft übernehmen Sie die CNAME-Ziele besonders sorgfältig: Seit Mai 2025 gibt es für neu eingerichtete Domains ein anderes Format. Alte Internetbeispiele sind dafür kein verlässlicher Ersatz.
Shopify und Klaviyo haben eigene Abläufe. Auch dort liefert immer das tatsächlich sendende Konto die verbindlichen DNS-Werte. Prüfen Sie diese Quellen getrennt von Ihrem normalen Mitarbeiterpostfach.
3. Hostnamen und Record-Typ prüfen
Beispiel einer DKIM-Zuordnung. Der gekürzte Schlüssel ist absichtlich nicht verwendbar.
Typ: TXT
Hostname: news2026._domainkey.example.com
Wert: v=DKIM1; k=rsa; p=GEKUERZTER_OEFFENTLICHER_SCHLUESSEL
news2026 ist der Selector. Er ermöglicht mehrere Schlüssel unter derselben Domain, etwa für verschiedene Dienste oder einen Schlüsselwechsel. Wenn Ihr DNS-Formular die Zone example.com bereits anhängt, tragen Sie dort nur news2026._domainkey ein. Kontrollieren Sie anschließend den vollständigen Namen. Ein versehentliches example.com.example.com ist ein häufiger Fehler.
Erstellen Sie keinen TXT-Eintrag, wenn Ihr Anbieter CNAME vorgibt. Am selben Hostnamen darf ein CNAME nicht mit einem zusätzlichen TXT-Schlüssel konkurrieren. Bestehende Selector anderer Versandquellen bleiben erhalten. Private Schlüssel gehören weder in DNS noch in eine Supportnachricht.
Nur lesende DNS-Prüfung in PowerShell. Ersetzen Sie Domain und Selector durch die Angaben aus Ihrem Konto.
Resolve-DnsName -Name news2026._domainkey.example.com -Type TXT
# Wenn der Versanddienst CNAME vorgibt:
Resolve-DnsName -Name news2026._domainkey.example.com -Type CNAME
Die Abfrage muss den vorgesehenen Record am richtigen Namen finden. Nach einer Änderung können Resolver noch alte Werte aus dem Cache liefern. Notieren Sie die bisherige TTL und prüfen Sie erneut, sobald dieser Zeitraum abgelaufen ist. Ein grüner DNS-Status ersetzt den Versandtest nicht.
4. Signierung aktivieren und eine echte E-Mail prüfen
- Die Domainprüfung im Versanddienst abschließen und die Signierung aktivieren.
- Eine Nachricht aus dem normalen Versandprozess an ein externes Testpostfach schicken. Eine technische Testfunktion kann einen anderen Weg nutzen als die echte Kampagne.
- Im empfangenen Postfach „Original anzeigen“, „Nachrichtenquelle“ oder die entsprechende Headeransicht öffnen.
- Das DKIM-Ergebnis des empfangenden Systems und die tatsächlich signierende Domain prüfen. Für jede Versandquelle wiederholen.
Vereinfachter Ausschnitt einer erfolgreichen Prüfung, kein vollständiger oder signierbarer E-Mail-Header.
From: Beispielshop <news@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
s=news2026; ...
Authentication-Results: mx.example.net;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.com
Der Header DKIM-Signature zeigt nur, dass eine Signatur mitgeschickt wurde. Entscheidend ist dkim=pass im Ergebnis Ihres vertrauenswürdigen Empfangssystems. Fremde, früher eingefügte Authentication-Results-Zeilen können täuschen. Vergleichen Sie header.d mit Ihrer geplanten Domain und header.from mit dem sichtbaren Absender.
5. Fehler gezielt eingrenzen
| Beobachtung | Mögliche Ursache | Nächster Schritt |
|---|---|---|
| Keine eigene DKIM-Signatur | Signierung noch aus; falsche Versandquelle getestet | Im Dienst Aktivierung und tatsächlichen Versandweg prüfen. |
| Schlüssel nicht auffindbar | Falscher Selector, Hostname oder Record-Typ | s= und d= aus der empfangenen Mail zur DNS-Abfrage zusammensetzen. |
| Signatur ungültig trotz richtigem Schlüssel | Nachträgliche Inhaltsänderung oder falsches Schlüsselpaar | Gateway, Disclaimer und Weiterleitung prüfen; eine direkt zugestellte Nachricht vergleichen. |
| DKIM besteht, DMARC scheitert | Signaturdomain passt nicht zur From-Domain | Eigene Versanddomain statt alleiniger Dienstleisterdomain aktivieren und erneut testen. |
Bewahren Sie pro Quelle einen datensparsam bereinigten Test-Header, Domain, Selector und Prüfdatum auf. Nach einem Dienstwechsel oder neuen Versandweg wiederholen Sie den Test. Für trustedDialog wird zusätzlich geprüft, welche konkreten Quellen und Domains freigegeben werden. DKIM allein schaltet die Kennzeichnung nicht ein.
Schlüsselwechsel ohne unbeabsichtigte Unterbrechung
Ein Schlüsselwechsel ist ein eigener Betriebsablauf. Überschreiben Sie den öffentlichen Schlüssel eines aktiven Selectors nicht unabhängig vom sendenden System. Sonst können Nachrichten mit dem bisherigen privaten Schlüssel gegen einen bereits ausgetauschten öffentlichen Schlüssel geprüft werden.
- Neuen Schlüssel im zuständigen Versandsystem erzeugen und einen neuen Selector verwenden, sofern der Dienst den Wechsel so vorsieht.
- Neuen DNS-Eintrag veröffentlichen und dessen Auflösung prüfen, während der bisherige Eintrag weiter verfügbar bleibt.
- Nach dem vorgesehenen DNS-Übergang die neue Signierung aktivieren. Bei verwalteten Diensten deren eigenen Rotationsablauf verwenden.
- Eine neue reguläre Nachricht prüfen: neuer Selector, erwartete Domain und gültiges Empfangsergebnis.
- Alten öffentlichen Schlüssel erst nach dem geplanten Übergang entfernen. Noch wartende oder verzögert zugestellte Nachrichten berücksichtigen.
Es gibt dafür keine für jeden Versand passende pauschale Wartezeit. DNS-TTL, Warteschlangen und der Betriebsablauf des Dienstes bestimmen den Übergang. Dokumentieren Sie, wer Schlüssel wechseln darf und wie eine Störung erkannt wird.
Wenn nur bestimmte Nachrichten DKIM nicht bestehen
Vergleichen Sie eine direkt zugestellte Nachricht mit einer betroffenen Nachricht derselben Quelle. Ein nachträglich angehängter Disclaimer oder ein verändernder Weiterleitungsdienst kann signierte Bestandteile verändern. Ein anderes Versandkonto kann außerdem einen anderen Selector oder eine andere Domain verwenden.
| Muster | Nächster Vergleich |
|---|---|
| Nur weitergeleitete Nachrichten scheitern | Direkter Empfang gegen Weiterleitung; Inhalts- und Headeränderungen durch den Zwischenweg prüfen. |
| Nur ein Flow scheitert | Versandart, Absender und DKIM-Domain dieses Flows gegen eine funktionierende Kampagne vergleichen. |
| Fehler beginnen beim Schlüsselwechsel | s= aus betroffener Mail, tatsächlich abrufbaren Schlüssel und Zeitpunkt der Umschaltung zusammen betrachten. |
| Mehrere DKIM-Signaturen vorhanden | Für jede Signatur Ergebnis und Domain getrennt lesen. Ein Pass einer fremden Domain beweist noch kein passendes DMARC-Alignment. |
Bei externen Prüfdiensten beachten Sie, welche Informationen Sie durch das Hochladen einer vollständigen Nachricht weitergeben. Für eine erste gemeinsame Diagnose reichen oft ein bereinigter Header, die betreffende Domain und ein datierter DNS-Befund. Der private Schlüssel wird dabei nie benötigt.
Häufige Fragen
Was brauche ich, um DKIM einzurichten?
Sie brauchen die DKIM-Werte Ihres Versanddienstes und Zugriff auf die DNS-Einstellungen Ihrer Domain. Jeder tatsächlich genutzte Versandweg muss mit seiner eigenen Konfiguration berücksichtigt werden.
Wie prüfe ich, ob DKIM funktioniert?
Senden Sie eine echte Nachricht aus dem jeweiligen Versandsystem an ein externes Testpostfach. Prüfen Sie im Nachrichtenheader das DKIM-Ergebnis und die signierende Domain. Ein vorhandener DNS-Eintrag allein bestätigt noch keine gültig signierte E-Mail.
