DKIM ist eine digitale Unterschrift, die dein Mailserver unter jede ausgehende Nachricht setzt. Der empfangende Server holt sich den passenden öffentlichen Schlüssel aus deinem DNS und rechnet nach. Stimmt die Unterschrift, weiß er zweierlei: Die Nachricht kommt tatsächlich von deinem Server, und unterwegs hat niemand etwas daran verändert.
Der entscheidende Unterschied zu SPF: DKIM übersteht Weiterleitungen. Wenn ein Empfänger deine Rechnung an die Buchhaltung weiterleitet, versendet ab diesem Moment ein fremder Server – SPF schlägt dann fehl. Die DKIM-Unterschrift reist dagegen in der Nachricht mit und gilt weiter. Bei Verteilern, weitergeleiteten Angeboten und automatisch archivierter Post ist DKIM oft das Einzige, was noch trägt.
Das ist keine Schwäche dieses Prüfers, sondern eine Eigenart des Verfahrens, und du solltest sie kennen.
Der Schlüssel liegt nicht unter einem festen Namen im DNS, sondern unter einem frei gewählten – dem Selektor. Er steht in jeder verschickten Nachricht in der Kopfzeile, aber nirgends im DNS. Von außen lässt sich also nicht nachschlagen, welche Selektoren eine Domain benutzt; man kann nur bekannte Namen durchprobieren.
Genau das tut dieser Check: Er erkennt an MX-Einträgen, SPF und Nameservern, welcher Anbieter im Spiel ist, fragt dessen übliche Selektoren gezielt ab und probiert zusätzlich rund neunzig verbreitete Namen durch. Trifft keiner, lautet der Befund „nicht gefunden" – nicht „nicht vorhanden". Der Unterschied ist wichtig genug, dass er im Befund ausdrücklich dasteht.
Bei Amazon SES und HubSpot ist Raten von vornherein aussichtslos: Diese Dienste vergeben zufällige Selektoren, die für jede Domain anders lauten. Dort führt nur der Weg über Selektor oder Kopfzeile.
Der öffentliche Schlüssel steht als TXT-Eintrag unter <selektor>._domainkey.<deine-domain>:
selector1._domainkey.beispiel.de
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…v=DKIM1 – Kennzeichnung als DKIM-Schlüsselk=rsa – das Verfahren; verbreitet ist RSA, seltener ed25519p=… – der öffentliche Schlüssel selbst. Ist er leer, wurde der Schlüssel zurückgezogen.Viele Anbieter legen statt eines TXT-Eintrags einen Verweis (CNAME) an, der auf ihre eigene Infrastruktur zeigt. Das hat einen guten Grund: So kann der Anbieter den Schlüssel wechseln, ohne dass du etwas tun musst.
Bei IONOS heißen die Selektoren s1-ionos und s2-ionos – nicht s1 oder ionos1, wie man vermuten würde. Die Einträge sind Verweise auf s1.dkim.ionos.com beziehungsweise s2.dkim.ionos.com.
Liegt deine DNS-Zone bei IONOS, legt IONOS sie automatisch selbst an, sobald DKIM für die Domain aktiv ist – du musst nichts eintragen. Liegt die Zone bei einem anderen Anbieter, musst du die Verweise dort von Hand nachtragen; die genauen Ziele stehen im IONOS-Kundenkonto.
Im Microsoft-Defender-Portal unter E-Mail und Zusammenarbeit → Richtlinien → DKIM die Domain auswählen und aktivieren. Microsoft nennt dir zwei CNAME-Einträge für die Selektoren selector1 und selector2, die auf den eigenen Mandanten bei onmicrosoft.com zeigen. Die trägst du in deiner DNS-Zone ein und schaltest DKIM danach im Portal scharf.
Achtung: Ohne die beiden CNAME-Einträge lässt sich die Signierung nicht aktivieren – Microsoft prüft deren Vorhandensein.
In der Admin-Konsole unter Apps → Google Workspace → Gmail → E-Mail authentifizieren. Dort erzeugst du einen Schlüssel – wähle 2048 Bit, nicht die kleinere Voreinstellung –, trägst den angezeigten TXT-Eintrag unter dem Selektor google in deine DNS-Zone ein und klickst anschließend auf „Authentifizierung starten". Der letzte Schritt wird gern vergessen; ohne ihn signiert Google nicht.
Jeder Dienst, der in deinem Namen verschickt, braucht seinen eigenen Schlüssel – DKIM lässt sich nicht teilen. Mailchimp, Brevo, SendGrid, Postmark und die anderen zeigen dir bei der Domain-Verifizierung die nötigen Einträge an, meist als CNAME. Zwei Hinweise dazu:
Bei Plesk, cPanel, Mailcow oder einem eigenen Postfix erzeugst du den Schlüssel im jeweiligen Werkzeug und veröffentlichst ihn als TXT-Eintrag. Üblicher Selektor: default oder mail. Erzeuge grundsätzlich 2048 Bit.
Unter keinem der geprüften Selektoren liegt ein Schlüssel. Das heißt nicht zwingend, dass kein DKIM eingerichtet ist – siehe den Abschnitt oben.
Was zu tun ist: Trage den Selektor ein oder füge die Kopfzeilen einer echten Nachricht ein, dann prüft der Check eindeutig. Kommt auch dann nichts, ist DKIM tatsächlich nicht eingerichtet: beim Postfach-Anbieter einschalten, wie oben beschrieben.
Der Eintrag existiert, enthält aber keinen Schlüssel mehr (p= ist leer). So stellt man einen alten Selektor nach einem Wechsel still, ohne den Eintrag zu löschen – ein sauberes Vorgehen, kein Fehler.
Was zu tun ist: Nichts, solange ein anderer Selektor einen gültigen Schlüssel trägt. Ist der Wechsel lange abgeschlossen, kann der Eintrag weg.
Kein auffindbarer Selektor trägt noch einen Schlüssel. Deine ausgehende Post wird damit nicht mehr signiert – und fällt bei DMARC durch, sobald SPF nicht greift, etwa bei jeder Weiterleitung.
Was zu tun ist: Beim Postfach-Anbieter einen neuen Schlüssel erzeugen und veröffentlichen. Das ist dringend, wenn DMARC auf quarantine oder reject steht.
Der Schlüssel hat weniger als 1024 Bit. Solche Schlüssel gelten als unsicher; mehrere große Anbieter werten die Unterschrift gar nicht mehr aus – die Nachricht ist dann faktisch unsigniert.
Was zu tun ist: Neuen Schlüssel mit 2048 Bit erzeugen und den alten nach dem Wechsel stilllegen.
Wird noch akzeptiert, ist aber nicht mehr zeitgemäß; 2048 Bit ist der heutige Standard. Häufig ein Altbestand aus der Zeit, als manche DNS-Oberflächen mit längeren Werten nicht umgehen konnten.
Was zu tun ist: Bei nächster Gelegenheit wechseln. Kein Notfall, aber es gehört auf die Liste.
Das Kennzeichen t=y sagt Empfängern ausdrücklich: Behandle eine fehlgeschlagene Unterschrift so, als wäre nichts gewesen. Für die Einführungsphase gedacht – als Dauerzustand hebt es den Schutz auf.
Was zu tun ist: Nach erfolgreichem Test t=y aus dem Eintrag entfernen.
Unter dem Selektor steht etwas, das sich nicht als Schlüssel auswerten lässt. Fast immer ein Kopierfehler: ein Zeilenumbruch mitten im Schlüssel, ein verlorenes Zeichen, oder die DNS-Oberfläche hat den langen Wert falsch zerlegt.
Was zu tun ist: Den Eintrag beim Anbieter neu abrufen und in einem Stück einsetzen – ohne Leerzeichen und Umbrüche innerhalb von p=. Danach hier erneut prüfen.
Nein, und es wäre auch nicht sinnvoll. Der private Schlüssel liegt beim jeweiligen Anbieter und verlässt ihn nicht. Jeder Dienst bekommt seinen eigenen Selektor – beliebig viele nebeneinander sind kein Problem.
Ja. SPF und DKIM prüfen verschiedene Dinge, und SPF überlebt keine Weiterleitung. DMARC verlangt, dass mindestens eines von beiden passt – mit nur einem von beiden ist jede Weiterleitung ein Risiko.
Weil der andere Prüfer einen Selektor auf der Liste hat, der hier fehlt – oder weil du ihm den Selektor genannt hast. Hilf mit: Selektor eintragen oder Kopfzeile einfügen, dann ist das Ergebnis eindeutig.
Schick dir selbst eine E-Mail und lass dir den Quelltext anzeigen. In der Zeile DKIM-Signature: steht s=… – das ist der Selektor, und d=… ist die Domain, für die signiert wurde.
Grafikdesigner & Programmierer. Seit über 25 Jahren in der Werbung zuhause – heute mit Fokus auf Websites, 3D, SEO und KI-Automation für Agenturen und Unternehmen.
Unverbindlich und auf Augenhöhe – ich sage dir ehrlich, was sinnvoll ist.
Termin vereinbaren → oder Kontaktdaten ansehen