Gib eine Domain und einen DKIM-Selector ein, um den Public-Key-TXT-Eintrag nachzuschlagen, der unter <selector>._domainkey.<domain> veröffentlicht ist, und seine Tags zu lesen. Kostenlos, läuft sofort in deinem Browser über DNS-over-HTTPS, ohne Anmeldung und ohne dass etwas gespeichert wird.
Erstelle ein kostenloses Unspam-Konto, um deine Ergebnisse zu speichern und diese Checks jederzeit zu wiederholen. So fällt dir ein kaputtes Setup auf, bevor es dich etwas kostet. Ohne Kreditkarte.
Mit DKIM (DomainKeys Identified Mail) hängt ein sendender Server jeder Nachricht eine kryptografische Signatur an. Der passende Public Key wird im DNS als TXT-Eintrag unter <selector>._domainkey.<domain> veröffentlicht, wobei der Selector ein Label ist, das der Absender wählt, um mehrere Schlüssel gleichzeitig zu betreiben. Ein empfangender Server liest den Selector aus dem DKIM-Signature-Header der Nachricht, holt sich diesen Public Key und verifiziert die Signatur, um zu bestätigen, dass die Nachricht unterwegs nicht verändert wurde und wirklich von der signierenden Domain stammt. Eine gültige DKIM-Signatur ist außerdem eine der Möglichkeiten, wie sich eine Nachricht mit DMARC ausrichten und es bestehen kann. Mailbox-Provider wie Gmail und Yahoo erwarten, dass Massenversender sich mit DKIM authentifizieren, ein veröffentlichter, korrekter Eintrag gehört also dazu, um in den Posteingang zu gelangen.
DKIM wird pro Selector veröffentlicht, nicht pro Domain, du musst also einen angeben. Finde ihn in einer Nachricht, die du von der Domain erhalten hast: öffne die Rohheader und lies das s=-Tag in der DKIM-Signature-Zeile. Wenn du keinen Header sehen kannst, probiere gängige Selectors wie google (Google Workspace), selector1 und selector2 (Microsoft 365), k1 (Mailgun), s1 und s2 (SendGrid), k1, k2 und k3 (Mailchimp), default oder dkim.
Das Versions-Tag. Es sollte v=DKIM1 lauten und, wenn vorhanden, das erste Tag im Eintrag sein. Alles andere bedeutet, dass der Eintrag kein gültiger DKIM-Schlüssel-Eintrag ist.
Der Schlüsseltyp. Die meisten Einträge nutzen k=rsa; einige moderne Setups nutzen k=ed25519. Wird k= weggelassen, gilt standardmäßig rsa, ein fehlendes k-Tag ist also normal.
Der base64-codierte Public Key. Er ist der Kern des Eintrags. Leerraum darin ist zulässig, weil RFC 6376 umgebrochenes base64 erlaubt und ein verifizierender Server ihn vor dem Dekodieren entfernt; ein Zeichen, das kein base64 ist, ist es nicht. RFC 8301 legt für RSA ein Minimum von 1024 Bit fest, und 2048 Bit ist die aktuelle Empfehlung.
Wenn der Eintrag existiert, aber p= leer ist (p=), wurde der Schlüssel gemäß RFC 6376 absichtlich widerrufen. Das unterscheidet sich von gar keinem Eintrag: ein leeres p= signalisiert verifizierenden Servern, jede Signatur mit diesem Selector als ungültig zu behandeln.
Die Abfrage gibt nichts zurück, weil der Selector falsch ist oder der Schlüssel nie veröffentlicht wurde. Bestätige den genauen Selector aus dem s=-Tag in einem echten DKIM-Signature-Header und prüfe dann erneut. Jeder Selector ist eigenständig, der richtige Schlüssel kann also unter einem anderen Selector liegen.
Der Eintrag ist vorhanden, aber der p=-Wert ist leer, was RFC 6376 als widerrufenen Schlüssel definiert. Empfänger lassen jede mit diesem Selector signierte Signatur durchfallen. Veröffentliche den Eintrag erneut mit dem aktuellen Public Key oder richte deine Versandplattform auf einen Selector aus, der noch einen gültigen p=-Wert hat.
Der p=-Wert wurde über mehrere Strings verteilt eingefügt oder enthält versehentliche Leerzeichen und Zeilenumbrüche. Das ist zulässig: RFC 6376 Abschnitt 3.6.1 erlaubt umgebrochenes base64, und ein verifizierender Server entfernt den Leerraum vor dem Dekodieren. Was einen Schlüssel wirklich kaputt macht, ist ein Zeichen, das kein base64 ist, oder ein Wert, den dein DNS-Host stillschweigend gekürzt hat, und beides liest sich hier als korrupter Schlüssel und nicht als fehlender. Einen langen TXT-Eintrag in zitierte Teile aufzuteilen, ist ebenfalls in Ordnung.
Wenn der Eintrag nicht mit v=DKIM1 beginnt, können Parser ihn ablehnen. Stelle sicher, dass das Versions-Tag vorhanden und an erster Stelle ist und die Tags durch Semikolons getrennt sind.
Ein 1024-Bit-RSA-Schlüssel erfüllt das Minimum aus RFC 8301, aber 2048 Bit ist die aktuelle Empfehlung, und ein t=y-Tag sagt Empfängern, Mail mit diesem Schlüssel als unsigniert zu behandeln, statt nur bei Fehlschlägen nachsichtig zu sein, sodass DKIM nicht für DMARC ausgerichtet werden kann, solange es da ist. Für den Produktivbetrieb nutze einen 2048-Bit-Schlüssel und entferne t=y, sobald du bestätigt hast, dass das Signieren funktioniert.
Beim Schlüsselwechsel ist bereits unterwegs befindliche Post noch mit dem vorherigen Selector signiert. Wer den Eintrag sofort löscht, lässt diese Nachrichten an der Prüfung scheitern. Lass den alten Selector veröffentlicht, bis die Warteschlange leer ist.
Alle Daten und Zahlen, die Unspam zu den Absenderanforderungen veröffentlicht, stehen hier und werden gegen die Dokumentation des jeweiligen Anbieters geprüft. Zuletzt gelesen am 16. August 2026.
| Anbieter | Was | Wert | Gilt für |
|---|---|---|---|
| Regeln für Massenversender in Kraft seit Quelle | Februar 2024 erforderlich | Mails an persönliche Gmail-Adressen | |
| Verschärfung der Durchsetzung seit Quelle | November 2025 beobachtet Google beschreibt das als schrittweise und fortlaufend, nicht als Schalter, der an einem Datum umgelegt wurde. | Mails an persönliche Gmail-Adressen | |
| Gilt als Massenversender ab Quelle | 5.000 erforderlich Das ist die Zahl von Google. Yahoo veröffentlicht bewusst keine. | Mails an persönliche Gmail-Adressen | |
| Obergrenze der Spam-Beschwerdequote Quelle | 0,3 % erforderlich Google beschreibt die Wirkung als gestuft und nicht als Grenzwert: oberhalb des empfohlenen Werts leidet die Zustellung bereits, an der Obergrenze stärker. | alle Absender an Gmail, nicht nur Massenversender | |
| Angestrebte Spam-Beschwerdequote Quelle | 0,1 % empfohlen Postmaster Tools teilt Beschwerden nicht durch alles, was Sie gesendet haben. Gemessen wird gegen DKIM-signierte Nachrichten, die den Posteingang eines aktiven Empfängers erreicht haben, ein bereits gefilterter Absender sieht daher eine künstlich niedrige Quote. | alle Absender an Gmail, nicht nur Massenversender | |
| Yahoo | Regeln für Massenversender in Kraft seit Quelle | Februar 2024 erforderlich | Mails an Yahoo, AOL und die übrigen Yahoo-Postfächer |
| Gilt als Massenversender ab Quelle | nicht veröffentlicht Yahoo erklärt, keinen Volumenschwellenwert zu nennen, es lässt sich also keine Zahl zuschreiben. | Mails an Yahoo, AOL und die übrigen Yahoo-Postfächer | |
| Obergrenze der Spam-Beschwerdequote Quelle | 0,3 % erforderlich | Mails an Yahoo, AOL und die übrigen Yahoo-Postfächer | |
| Outlook.com | Regeln für Massenversender in Kraft seit Quelle | Mai 2025 erforderlich | Outlook.com und die übrigen Verbraucherpostfächer von Microsoft, nie ein Microsoft-365-Tenant |
| Gilt als Massenversender ab Quelle | 5.000 erforderlich Die Regel gilt für jede Domain, die den Schwellenwert jemals überschritten hat, sie greift also auch an einem ruhigeren Tag. | Outlook.com und die übrigen Verbraucherpostfächer von Microsoft, nie ein Microsoft-365-Tenant | |
| Was mit fehlschlagenden Mails passiert Quelle | 550 5.7.515 beobachtet Nicht konforme Mail wird während der SMTP-Verbindung abgewiesen, statt im Spam-Ordner abgelegt zu werden. Die Postmaster-Richtlinienseite von Microsoft beschreibt den Junk-Ordner weiterhin als ersten Schritt, ein Versender kann also beides erleben, planen sollte er aber mit der Abweisung. | Outlook.com und die übrigen Verbraucherpostfächer von Microsoft, nie ein Microsoft-365-Tenant | |
| SPF und DKIM müssen beide bestehen, nicht nur DMARC Quelle | erforderlich Strenger als DMARC allein. DMARC gilt als bestanden, sobald SPF oder DKIM ausgerichtet ist, und Outlook.com verlangt zusätzlich, dass beide Prüfungen bestehen. | Outlook.com und die übrigen Verbraucherpostfächer von Microsoft, nie ein Microsoft-365-Tenant | |
| Apple | Regeln für Massenversender in Kraft seit Quelle | Februar 2025 erforderlich | Mails an iCloud Mail, me.com und mac.com |
| ARC-Header bei weitergeleiteten Mails Quelle | erforderlich Apple ist der Einzige der vier, der das verlangt, und das ist der ehrliche Grund, sich ARC überhaupt anzusehen. | Mails an iCloud Mail, me.com und mac.com |
Unspam liest all das allein aus Ihrem Domainnamen.
Keine DNS-Abfrage erreicht das. Dafür braucht es eine echte Nachricht oder echte Sendehistorie, und genau dafür ist ein Inbox-Placement-Test da.
