Was der DKIM-Check prüft
DomainKeys Identified Mail (DKIM, spezifiziert in RFC 6376) versieht ausgehende E-Mails mit einer kryptografischen Signatur. Der versendende Server signiert ausgewählte Header-Felder und den Nachrichtentext mit einem privaten Schlüssel und fügt das Ergebnis als Header DKIM-Signature ein. Den passenden öffentlichen Schlüssel veröffentlicht der Domaininhaber als TXT-Eintrag im DNS. Der Empfangsserver ruft ihn ab und prüft damit, ob die Nachricht unterwegs verändert wurde und ob die signierende Domain tatsächlich dahintersteht. Das Verfahren im Detail erklärt der Glossar-Eintrag DKIM.
Der DKIM-Check fragt genau diesen öffentlichen Schlüssel ab. Sie geben Domain und Selector ein, das Tool liest den TXT-Eintrag unter <selector>._domainkey.<domain> per DNS-over-HTTPS direkt im Browser aus und folgt dabei CNAME-Verweisen, wie sie etwa Microsoft 365 für selector1 und selector2 nutzt. Anschließend zerlegt es den Eintrag in seine Tags, ermittelt Schlüsseltyp und Schlüssellänge aus dem Public Key und bewertet das Ergebnis per Ampel. Kennen Sie den Selector nicht, fragt die Schaltfläche „Häufige Selectoren durchprobieren“ eine Liste gängiger Namen nacheinander ab. Ergebnisse lassen sich per URL teilen, zum Beispiel /tools/dkim-check/?domain=beispiel.de&selector=google.
So finden Sie den DKIM-Selector
Anders als SPF liegt DKIM nicht direkt an der Domain, sondern unter einem frei wählbaren Namen, dem Selector. Eine Domain kann beliebig viele Selectoren nutzen, etwa einen pro Versanddienst. Eine Liste aller Selectoren lässt sich per DNS nicht abrufen: Der Empfänger erfährt den Namen ausschließlich aus der Signatur der jeweiligen Mail. Vorschlagsliste und automatisches Durchprobieren decken deshalb nur verbreitete Namen ab, nicht jeden individuell vergebenen Selector.
Zuverlässig ermitteln Sie den Selector im Header einer Mail, die Sie selbst verschickt haben. In Gmail öffnen Sie dazu „Original anzeigen“, in Outlook die Nachrichtenquelle beziehungsweise die Internetkopfzeilen. Suchen Sie dort nach DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=beispiel.de; s=google;
h=from:to:subject:date:message-id;
bh=…; b=…Der Wert hinter s= ist der Selector, der Wert hinter d= die signierende Domain. Finden Sie mehrere Signaturen, hat neben Ihrem Mailsystem auch ein Versanddienst signiert. Für DMARC zählt eine Signatur nur, wenn ihr d= zu Ihrer Absenderdomain passt.
So lesen Sie das Ergebnis
Das Tool zeigt den abgefragten Hostnamen, bei Weiterleitungen das CNAME-Ziel, den Roh-Record sowie Schlüsseltyp und Schlüssellänge. Die Ampel fasst zusammen: Grün steht für einen gültigen Schlüssel ab 2048 Bit. Gelb bedeutet funktionsfähig, aber verbesserungswürdig, etwa bei 1024 Bit oder aktivem Testmodus. Rot heißt unbrauchbar: kein Eintrag unter dem Selector, ein leerer Schlüssel, eine falsche Versionsangabe oder ein RSA-Schlüssel unter 1024 Bit. Die einzelnen Tags erklärt die folgende Tabelle:
| Tag | Bedeutung | Bewertung im Tool |
|---|---|---|
v= | Version, muss DKIM1 lauten | anderer Wert: Fehler |
k= | Schlüsseltyp, rsa (Standard) oder ed25519 | wird ausgewiesen |
p= | öffentlicher Schlüssel in Base64 | leer: Schlüssel widerrufen, Fehler |
t= | Flags: y markiert den Testmodus, s schließt Subdomains aus | t=y: Warnung |
h= | zulässige Hash-Verfahren, etwa sha256 | wird ausgewiesen |
s= | Diensttyp, meist * oder email | wird ausgewiesen |
Zur Schlüssellänge: RFC 8301 verlangt für RSA mindestens 1024 Bit und empfiehlt 2048 Bit; Signaturen mit kürzeren Schlüsseln dürfen Empfänger nicht als gültig werten. Ed25519 (RFC 8463) arbeitet mit deutlich kürzeren Schlüsseln, wird aber nicht von allen Empfangsservern unterstützt und deshalb meist zusätzlich zu einer RSA-Signatur eingesetzt.
Typische DKIM-Fehler und ihre Lösung
Kein Record unter dem Selector
Häufigste Ursache ist ein anderer Selector als vermutet. Prüfen Sie den Mail-Header wie oben beschrieben. Ebenso verbreitet: DKIM wurde beim Anbieter nie aktiviert. In Google Workspace erzeugen Sie den Schlüssel in der Admin-Konsole, tragen ihn ins DNS ein und starten anschließend die Authentifizierung. Bei Microsoft 365 legen Sie die CNAME-Einträge an und aktivieren DKIM danach im Defender-Portal. Ein dritter Klassiker ist ein doppelter Domainname, weil das DNS-Panel die Domain automatisch anhängt. Korrekt sieht es etwa so aus:
google._domainkey.beispiel.de. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…IDAQAB"
selector1._domainkey.beispiel.de. CNAME selector1-beispiel-de._domainkey.beispiel.onmicrosoft.com.Das genaue CNAME-Ziel für Microsoft 365 zeigt Ihnen das Defender-Portal an.
Leerer Schlüssel (p=)
default._domainkey.beispiel.de. TXT "v=DKIM1; k=rsa; p="Ein leeres p= bedeutet laut RFC 6376, dass der Schlüssel widerrufen wurde. Alle Signaturen mit diesem Selector schlagen fehl. Nach einer geplanten Schlüsselrotation ist das gewollt; signiert Ihr System aber noch mit diesem Selector, müssen Sie einen neuen Schlüssel veröffentlichen.
Schlüssel zu kurz
Schlüssel mit 1024 Bit sind noch zulässig, gelten aber nicht mehr als zeitgemäß. Wechseln Sie auf 2048 Bit, am besten über einen neuen Selector: neuen Schlüssel veröffentlichen, das Mailsystem darauf umstellen, den alten Eintrag noch eine Weile stehen lassen, damit unterwegs befindliche Mails prüfbar bleiben, und ihn erst danach widerrufen.
Testmodus vergessen (t=y)
google._domainkey.beispiel.de. TXT "v=DKIM1; k=rsa; t=y; p=MIIBIjANBgkqh…IDAQAB"Nach RFC 6376 dürfen Empfänger Mails eines Absenders im Testmodus nicht anders behandeln als unsignierte Mails. Entfernen Sie t=y, sobald die Einrichtung abgeschlossen ist.
Abgeschnittener oder beschädigter Schlüssel
Ein 2048-Bit-Schlüssel ist länger als die 255 Zeichen, die ein einzelner String in einem TXT-Record fassen kann. Er muss deshalb auf mehrere Strings innerhalb desselben Eintrags verteilt werden. Manche DNS-Oberflächen erledigen das automatisch, andere nicht. Auch beim Kopieren eingeschleppte Zeilenumbrüche oder Anführungszeichen machen den Schlüssel unbrauchbar. Lässt sich der Schlüssel nicht auswerten oder wirkt die ermittelte Länge unplausibel, prüfen Sie den Eintrag auf diese Fehler.
DKIM, DMARC und Cold E-Mail
DKIM ist der robustere Partner von SPF. Die Signatur übersteht Weiterleitungen, solange der Inhalt unverändert bleibt, während SPF bei weitergeleiteten Mails meist scheitert. Für DMARC zählt DKIM jedoch nur, wenn die Domain im d=-Tag zur sichtbaren Absenderadresse passt. Viele Versanddienste signieren standardmäßig mit ihrer eigenen Domain: DKIM ist dann bestanden, hilft Ihrer Domain aber nicht. Richten Sie deshalb in jedem Tool, das in Ihrem Namen versendet, eine eigene DKIM-Signatur mit Ihrer Domain ein. Welche Lösungen das sauber unterstützen, zeigt der Vergleich der besten E-Mail-Outreach-Tools 2026.
Google und Yahoo verlangen seit Februar 2024 von allen Absendern mindestens SPF oder DKIM. Bulk-Sender, bei Google ab 5.000 Mails pro Tag an Gmail-Adressen, brauchen SPF, DKIM und DMARC. Für B2B-Outreach mit mehreren Versanddomains bedeutet das: Jede Domain und jeder angebundene Mailbox-Anbieter braucht einen aktiven Schlüssel, und jede Domain sollte einzeln geprüft werden. Fehlende oder fehlerhafte Signaturen gehören zu den vermeidbaren Ursachen schlechter E-Mail-Deliverability.
Nächste Schritte
- Prüfen Sie mit dem SPF-Check, ob alle Versanddienste autorisiert sind und das Limit von 10 DNS-Lookups eingehalten wird.
- Kontrollieren Sie mit dem DMARC-Check, ob eine DMARC-Policy veröffentlicht ist und wie Reporting und Alignment eingestellt sind.
- Ermitteln Sie mit dem MX-Check, welchen E-Mail-Anbieter Ihre Domain nutzt. Das gibt oft einen Hinweis auf den passenden Selector.
- Klären Sie mit dem Blacklist-Check, ob Ihr Mailserver oder Ihre Domain auf einer gängigen DNS-Blacklist geführt wird.
Häufige Fragen
Wie finde ich meinen DKIM-Selector?
Schicken Sie sich selbst eine Mail an ein externes Postfach und öffnen Sie die vollständigen Kopfzeilen, in Gmail etwa über Original anzeigen. Im Header DKIM-Signature steht hinter s= der Selector und hinter d= die signierende Domain. Per DNS lassen sich Selectoren nicht auflisten. Alternativ zeigt die Admin-Oberfläche Ihres Mailanbieters den verwendeten Selector bei der DKIM-Einrichtung an.
Wie prüfe ich, ob DKIM funktioniert?
Zwei Schritte sind sinnvoll. Erstens prüfen Sie mit dem DKIM-Check, ob unter Ihrem Selector ein gültiger öffentlicher Schlüssel im DNS liegt. Zweitens kontrollieren Sie im Header einer empfangenen Testmail das Feld Authentication-Results: Steht dort dkim=pass und als Domain Ihre eigene, wird korrekt signiert und die Signatur ist für DMARC verwertbar.
Welche DKIM-Schlüssellänge ist empfehlenswert?
Für RSA-Schlüssel sind 2048 Bit der empfohlene Standard. 1024 Bit sind laut RFC 8301 das zulässige Minimum, kürzere Schlüssel werden von Empfängern nicht als gültig gewertet. Schlüssel bis 4096 Bit müssen Empfänger zwar verarbeiten können, sie sind im DNS aber umständlicher zu pflegen. Ed25519 ist eine moderne Alternative, wird aber meist nur ergänzend zu RSA genutzt.
Was ist der Unterschied zwischen SPF und DKIM?
SPF legt fest, welche Server für eine Domain senden dürfen, und prüft dafür die IP-Adresse des einliefernden Servers. DKIM prüft dagegen per Signatur, ob die Nachricht unverändert ist und von der angegebenen Domain verantwortet wird. SPF scheitert häufig bei Weiterleitungen, DKIM übersteht sie in der Regel. Beide Verfahren ergänzen sich, und DMARC baut auf ihnen auf.
Was bedeutet dkim=fail im E-Mail-Header?
Die Signatur konnte nicht bestätigt werden. Häufige Ursachen sind Änderungen an der Mail nach dem Signieren, etwa durch Verteiler, angehängte Fußzeilen oder Sicherheits-Gateways, außerdem ein fehlender, widerrufener oder fehlerhaft eingetragener öffentlicher Schlüssel. Prüfen Sie zuerst mit dem DKIM-Check den Schlüssel unter dem Selector aus dem Header und testen Sie danach eine Mail ohne zwischengeschaltete Dienste.
