Beliebte Tools

Design

DKIM-Check

Der DKIM-Check liest die DKIM-Einträge einer Domain so, wie empfangende Mailserver sie finden, oder testet die Signatur einer eingefügten E-Mail: welche Selektoren antworten, wer signiert, wie stark jeder Schlüssel ist und ob er zu DMARC passt.

Quellen: 140 gängige Selektoren von 67 E-Mail-Anbietern, abgefragt über Google Public DNS (dahinter Cloudflare) · Schlüsselprüfungen nach RFC 6376 und RFC 8301 · E-Mails in Ihrem Browser verifiziert · nichts über Sie wird gespeichert

Fragt die 140 Selektoren ab, die E-Mail-Anbieter verwenden, bei selector._domainkey. plus der Domain, denn das DNS kann Selektoren nicht auflisten

Beispiel

Wie prüfe ich einen DKIM-Eintrag? Der DKIM-Lookup

Geben Sie oben die Domain ein: Der Check fragt die 140 Selektoren ab, die E-Mail-Anbieter verwenden, zeigt jeden gefundenen Schlüssel mit Größe und Anbieter und sagt ehrlich, wenn er keinen findet. Sie kennen den Selektor? Wählen Sie Domain + Selektor, dann wird er zuerst geprüft.

Von Hand brauchen Sie den Selektor, denn das DNS kann sie nicht auflisten: dig +short TXT selector._domainkey.example.com, unter Windows nslookup -type=TXT mit demselben Namen. Der Selektor ist das s= in der DKIM-Signature jeder E-Mail (RFC 6376 §3.6.2.1).

dig zeigt den Text, nicht, was er bedeutet: Es dekodiert nicht die Größe des Schlüssels, folgt nicht dem CNAME des Anbieters und unterscheidet keinen Standby-Platz von einem defekten. Genau das ergänzt dieser DKIM-Eintrag-Checker.

dig +short TXT selector._domainkey.example.com

Jeder TXT-String beim Namen: Fügen Sie sie zusammen, um den Schlüssel zu lesen.

Was dig zeigt und was nicht

Terminal

$ dig +short TXT 20251104._domainkey.google.com 1

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ…" "…k2A8ZfpQIDAQAB"2

$ dig +short TXT 20251104._domainkey.google.com | tr -d '" \n' | sed 's/.*p=//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1 3

Public-Key: (2048 bit)

$ dig +short TXT selector1._domainkey.microsoft.com 4

selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.

  1. 1Der Name ist selector._domainkey.domainOhne Selektor keine Antwort: Das DNS kennt kein „alle Schlüssel auflisten“.
  2. 2Zwei Strings, ein EintragEin TXT-String fasst 255 Bytes, deshalb wird ein 2048-Bit-Schlüssel geteilt; Empfänger fügen ihn ohne Zeichen dazwischen zusammen.
  3. 3Die tatsächliche Größe des Schlüsselsopenssl dekodiert p=: 2048 Bit ist, was RFC 8301 verlangt.
  4. 4Ein CNAME zum AnbieterKein TXT dahinter: der Standby-Platz von Microsoft 365, kein Fehler.
Der Schlüssel von google.com und der selector1 von microsoft.com, wie Cloudflare DNS sie am 25. Oktober 2026 lieferte.

Das Ergebnis lesen: der Selektor-Durchlauf

Die Antwort steht zuerst, als Satz. Darunter wer signiert und der Schlüssel selbst, jedes Tag farbig über seinen genauen Zeichen, mit der Größe des Schlüssels auf der Skala von RFC 8301; auf Marineblau jeder Selektor, den die Prüfung abgefragt hat, damit Sie sehen, was versucht wurde.

Keine Note: Ein stillgelegter Schlüssel oder der leere Standby-Selektor eines Anbieters ist normal, und „nicht unter den gängigen Selektoren gefunden“ heißt nie „kein DKIM“.

DKIM-Check von github.com: zwölf Schlüssel von sechs Anbietern, der Selektor-Durchlauf und die Schlüsselgrößen-AnzeigeDKIM-Check von github.com: zwölf Schlüssel von sechs Anbietern, der Selektor-Durchlauf und die Schlüsselgrößen-AnzeigeDas UrteilEin Satz: wie viele Schlüssel es gibt und was zu tun ist.Wer signiertEine Karte pro Anbieter, erkannt am CNAME oder an einem dokumentierten Selektor. Jeder Selektor-Chip öffnet seinen Schlüssel.Der SchlüsselJedes Tag farbig über seinen Zeichen und die Größe des Schlüssels auf der Skala von RFC 8301.Der Selektor-DurchlaufJeder abgefragte Name, beleuchtet, sobald er antwortet: grün ein Schlüssel, bernsteinfarben 1024 Bit, gestrichelt ein Standby-Platz.DMARC-AlignmentOb ein Schlüssel mit d= dieser Domain zur DMARC-Richtlinie passt.
Ein DKIM-Check von github.com: das Urteil, wer signiert, der in seine Tags zerlegte Schlüssel mit seiner Größe und auf Marineblau jeder Selektor, den die Prüfung abgefragt hat. Wählen Sie eine Zahl, um zu sehen, was jeder Teil zeigt.

Was ist DKIM?

DKIM (DomainKeys Identified Mail) ist eine Signatur, die ein sendender Server jeder Nachricht hinzufügt und die Empfänger mit einem öffentlichen Schlüssel prüfen, den die Domain im DNS veröffentlicht (RFC 6376). Eine gültige Signatur beweist zweierlei: Die Domain in d= hat signiert, und die signierten Teile haben sich seitdem nicht verändert.

Der Absender hasht den Body in bh= und signiert die gewählten Header plus diesen Hash mit seinem privaten Schlüssel in b=. Der Empfänger liest d= und s=, ruft den Schlüssel bei s._domainkey.d ab und rechnet beides nach. Ein verändertes Byte im Body oder in einem signierten Header, und sie fällt durch.

DKIM sagt nichts darüber, was bei einem Fehlschlag zu tun ist, und jede Domain kann signieren. Das ist Aufgabe von DMARC: Es verlangt eine bestandene Signatur, deren d= zur From:-Domain passt.

Eine Nachricht, beim Absender signiert und beim Empfänger geprüft

Server von example.comsigniert mit seinem privaten Schlüssel
die Nachricht, mit ihrer DKIM-Signature
Der EmpfängerGmail, Outlook.com, Yahoo…

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=dnsrobot-sample; h=from:from:to:subject:…; bh=fohb/a+auh1W9cUN…; b=fF0aMr3Uo+mbgG…

dnsrobot-sample._domainkey.example.com TXT?"v=DKIM1; k=rsa; p=MIIBIjANBgkq…"RSA 2048

Die Nachricht wie gesendet

  • Body-Hash stimmt mit bh= überein
  • Header-Signatur wird verifiziert

dkim=pass header.d=example.com

Dieselbe Nachricht, ihr Subject unterwegs verändert

  • Body-Hash stimmt mit bh= überein
  • Header-Signatur wird nicht verifiziert

dkim=fail (signature-mismatch)

Beide Ergebnisse stammen von der Engine, aus der Beispiel-E-Mail dieser Seite und derselben E-Mail mit nach dem Signieren geändertem Subject. RFC 6376 §3.7, RFC 8301.

Was ist ein DKIM-Selektor, und wie finde ich meinen?

Ein Selektor ist der Name eines DKIM-Schlüssels: das s= in einer Signatur und das erste Label des DNS-Namens, unter dem der Schlüssel liegt (s1._domainkey.github.com). Eine Domain kann beliebig viele haben: einen pro Anbieter, pro Server, pro Jahr (RFC 6376 §3.1).

Um Ihren zu finden, öffnen Sie eine beliebige E-Mail, die die Domain gesendet hat, und sehen Sie sich das Original an: In Gmail listet Mehr (⋮) › Original anzeigen die DKIM-Signature auf, und ihr s= ist der Selektor. Oder fügen Sie die E-Mail oben unter E-Mail verifizieren ein.

Die meisten Anbieter verwenden feste Namen, deshalb findet ein Durchlauf sie. Amazon SES, Postmark, SparkPost und HubSpot erzeugen einen Namen pro Konto, den nur eine E-Mail oder das Dashboard des Anbieters verrät.

Von der Signatur zum Schlüssel, und die Namen der Anbieter

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=s1; …

s1._domainkey.github.comCNAME s1.domainkey.u51742174.wl175.sendgrid.netRSA 2048

Google Workspacegoogleder Admin kann das Präfix ändern
Microsoft 365selector1 · selector2CNAMEs in den Tenant; einer aktiv, einer im Standby
Twilio SendGrids1 · s2CNAMEs auf u<id>.wl<n>.sendgrid.net
Mailchimpk2 · k3CNAMEs auf dkim2/dkim3.mcsv.net
Fastmailfm1 · fm2 · fm3drei CNAMEs, immer einer gefüllt
Proton Mailprotonmail · 2 · 3CNAMEs auf domains.proton.ch
Amazon SES3 zufällige Tokensje 32 Zufallszeichen: nicht zu erraten
Postmark20240101000000pmein Datum und „pm“: nicht zu erraten
SparkPostscph + MMYYscph und der Monat der Schlüsselerstellung
HubSpoths1-<HubID>Ihre Kontonummer
Der s1 von github.com, wie Cloudflare DNS ihn am 25. Oktober 2026 lieferte. Namen der Anbieter aus deren eigener Dokumentation (67 Anbieter, 140 Selektoren im Durchlauf).

Aufbau eines DKIM-Eintrags: jedes Tag erklärt

Ein DKIM-Eintrag ist ein TXT-Eintrag aus tag=value-Paaren, durch Semikolons getrennt; erforderlich ist nur p=, der öffentliche Schlüssel. v=DKIM1 ist optional, muss aber, wenn vorhanden, an erster Stelle stehen (RFC 6376 §3.6.1).

k= nennt den Schlüsseltyp (rsa, sofern nicht ed25519 dasteht), t= trägt Flags (y Test, s strikt), h= begrenzt Hashes und s= Dienste. Ein leeres p= widerruft den Schlüssel absichtlich.

Tag-Namen unterscheiden Groß- und Kleinschreibung, und ein wiederholtes Tag macht den Eintrag ungültig. Unbekannte Tags werden ignoriert.

Der Eintrag, Tag für Tag

v=DKIM1; k=rsa; t=s; h=sha256; p=MIIBIjANBgkqhkiG9w…IDAQAB

TagLegt festWerteStandardHinweis
v=VersionDKIM1DKIM1empfohlen; zuerst, falls vorhanden
k=Schlüsseltyprsa · ed25519rsaunbekannte Typen: Schlüssel ignoriert
p=Öffentlicher Schlüssel (base64)der Schlüssel oder leererforderlichleer = widerrufen
t=Flagsy Test · s striktkeiney: als unsigniert behandelt
h=Erlaubte Hashessha256 (sha1 verboten)allesha1 allein fällt durch (RFC 8301)
s=Diensttyp* · email*nur andere Dienste: ignoriert
n=Notizen für Menschenbeliebiger Text–wird von Software nie gelesen

Wie lang p= ist und wie viele TXT-Strings es braucht

RSA 1024216 Zeichen · 1 TXT-String
RSA 2048392 Zeichen · 2 TXT-Strings
RSA 3072564 Zeichen · 3 TXT-Strings
RSA 4096736 Zeichen · 3 TXT-Strings
Ed2551944 Zeichen · 1 TXT-String

Grenzen der 255-Byte-TXT-Strings (gezählt ab „v=DKIM1; k=rsa; p=“)

Die Längen von p= sind gemessene SubjectPublicKeyInfo-Schlüssel. yahoo.com veröffentlicht seinen 2048-Bit-Schlüssel in 4 Strings: Jede Aufteilung funktioniert, da Empfänger sie ohne Zeichen dazwischen zusammenfügen (RFC 6376 §3.6.2.2).

DKIM-Schlüssel mit 1024 vs. 2048 Bit, und wie oft man DKIM-Schlüssel rotiert

Verwenden Sie 2048-Bit-RSA. RFC 8301 verlangt von Verifizierern weiterhin, 1024-Bit-Schlüssel zu akzeptieren, von Signierern aber mindestens 2048, und weist Verifizierer an, Schlüssel unter 1024 Bit abzulehnen. M3AAWG nennt 1024 Bit „am Rand der Angreifbarkeit“ und berichtet von einem 512-Bit-Schlüssel, der in etwa 72 Stunden für etwa 75 $ geknackt wurde.

Ein Ed25519-Schlüssel ist klein (44 Zeichen p=), und aus Gründen der Abwärtskompatibilität erlaubt RFC 8463 Signierern, daneben eine RSA-Signatur hinzuzufügen: zwei Selektoren, zwei Signaturen (RFC 8463).

Rotieren Sie, indem Sie den neuen Schlüssel bei einem neuen Selektor veröffentlichen, das Signieren umstellen, den alten Schlüssel 7 bis 30 Tage für Mails in Zustellung behalten und dann sein p= leeren. M3AAWG empfiehlt alle sechs Monate. Anbieter wie Fastmail und Microsoft 365 erledigen das mit Standby-Selektoren für Sie.

Wo echte Schlüssel auf der Skala von RFC 8301 liegen

Fällt durchGültig, auf 2048 rotierenGutKann bei manchen Empfängern scheitern
  • microsoft.com · selector2
  • github.com · k1
  • google.com · 20251104
  • fastmail.com · fm2
  • archlinux.org · dkim-rsa
  • archlinux.org · dkim-ed25519 (Ed25519)

Rotation ohne Lücke (M3AAWG)

  1. Tag 0Neuen Schlüssel bei einem neuen Selektor veröffentlichen
  2. Tag 1+Das Signieren darauf umstellen
  3. +7–30 TageDen alten Schlüssel für Mails in Zustellung behalten
  4. DanachDas alte p= leeren; den Namen nicht wiederverwenden
fastmail.comfm1leeres p=fm22.048fm3leeres p=drei CNAMEs, einer gefüllt: Die Rotation ist bei Fastmail eine DNS-Änderung
Schlüsselgrößen, am 25. Oktober 2026 aus dem DNS gelesen und aus jedem p= dekodiert. RFC 8301 §3.2; M3AAWG DKIM Key Rotation Best Common Practices (2019).

Warum schlägt DKIM fehl? Body-Hash, Weiterleitung und Mailinglisten

DKIM schlägt fehl, wenn sich die signierten Bytes verändert haben, wenn der Schlüssel nicht zu finden ist oder wenn der Schlüssel nicht zur Signatur passt. Weiterleiten, das die Nachricht unverändert lässt, lässt DKIM intakt (anders als SPF); Mailinglisten brechen es meist, weil sie Footer anhängen oder den Betreff markieren.

Der Verifizierer auf dieser Seite prüft Body-Hash und Header-Signatur getrennt, deshalb kann er einen unterwegs angehängten Footer von einer Fälschung unterscheiden.

Body-Hash wurde nicht verifiziert

Eine Mailingliste hat einen Footer von 153 Byte angehängt. Die Header werden weiterhin mit dem Schlüssel von project.example verifiziert, also ist das keine Fälschung.

Lösung Listen, die den Body intakt lassen, oder ARC (RFC 8617), damit spätere Empfänger das ursprüngliche Ergebnis sehen.

body-hash-mismatch

Signatur wurde nicht verifiziert

Ein signierter Header wurde nach dem Signieren verändert (eine Liste, die ihren Namen in den Betreff setzt), oder der Selektor enthält jetzt einen anderen Schlüssel.

Lösung Signierte Header nicht umschreiben; veröffentlichen Sie einen neuen Schlüssel bei einem neuen Selektor, statt einen zu ersetzen.

signature-mismatch

Kein Schlüssel zur Signatur

s=2023old._domainkey.shop.example ist NXDOMAIN: Der Selektor wurde gelöscht, während damit signierte Mails noch unterwegs waren.

Lösung Alte Schlüssel nach dem Umstellen 7–30 Tage veröffentlicht lassen; p= leeren, statt zu löschen.

key-not-found

Weiterleitung: Ein Weiterleiter, der die Nachricht unverändert weitergibt, lässt DKIM gültig, weshalb DMARC eine Weiterleitung meist über DKIM übersteht, auch wenn SPF durchfällt.

DKIM vs. SPF vs. DMARC

SPF sagt, welche Server für eine Domain senden dürfen, DKIM beweist, dass eine Domain die Nachricht signiert hat und sie nicht verändert wurde, und DMARC verknüpft beides mit der From:-Adresse und legt fest, was bei einem Fehlschlag geschieht.

Sie beantworten verschiedene Fragen, deshalb brauchen Sie alle drei: Gmail und Yahoo verlangen von Massenversendern SPF und DKIM sowie einen DMARC-Eintrag, und RFC 9989 verlangt von Domains mit p=reject, mit DKIM zu signieren, statt sich auf SPF zu verlassen.

Drei Einträge, drei Fragen

Drei Einträge, drei FragenSPFDKIMDMARC
Was es beweistDieser Server darf für die MAIL-FROM-Domain sendenDomain d= hat signiert; signierte Teile unverändertFrom: passt zu einer Domain, die SPF oder DKIM bestanden hat
Wo es liegtTXT bei github.comTXT bei s1._domainkey.github.comTXT bei _dmarc.github.com
github.com heutev=spf1 … ~all12 Schlüssel, 6 Anbieterp=quarantine; sp=reject
Übersteht WeiterleitungNein: Die IP des Weiterleiters ist nicht gelistetJa, wenn die Nachricht unverändert ankommtJa, über einen DKIM-Pass mit Alignment
Bricht, wennein neuer Versanddienst nicht im Eintrag stehtder Body oder ein signierter Header sich ändertkeines von beiden für die From:-Domain besteht

SPF-Eintrag-CheckerDMARC-Check

Die Einträge von github.com, am 25. Oktober 2026 gelesen.

So lesen Sie den DKIM-Signature-Header in einer E-Mail

Öffnen Sie die Original-Nachricht und suchen Sie den DKIM-Signature-Header: d= ist, wer signiert hat, s= welcher Schlüssel, h= listet die signierten Header auf, und bh= und b= sind die beiden Hashes, die ein Empfänger prüft.

Das Urteil des Empfängers steht in einem eigenen Header, der bei Ankunft hinzugefügt wird: Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample. Die Seite „Original anzeigen“ von Gmail fasst es (auf Englisch) zusammen als „DKIM: 'PASS' with domain example.com“.

Eine Nachricht kann mehrere Signaturen tragen, eine pro Signierer (Ihre Domain und Ihr E-Mail-Dienst oder eine Mailingliste). Eine einzige bestandene Signatur, deren d= zur From:-Domain passt, genügt für DMARC.

Die Signatur der Beispiel-E-Mail, Tag für Tag

v=11; a=rsa-sha2562; c=relaxed/relaxed3; d=example.com4; s=dnsrobot-sample5; t=17928331206; h=from:from:to:subject:date:message-id:mim…7; bh=fohb/a+auh1W9c…8; b=fF0aMr3Uo+mbgG…9

  1. 1Version v=immer 1
  2. 2Algorithmus a=rsa-sha256 (oder ed25519-sha256)
  3. 3Kanonisierung c=relaxed toleriert neues Umbrechen
  4. 4Signaturdomain d=für DMARC mit From: verglichen
  5. 5Selektor s=der Schlüssel bei s._domainkey.d
  6. 6Signiert um t=Unix-Zeit: 24.10.2026, 09:12
  7. 7Signierte Header h=from doppelt = übersigniert
  8. 8Body-Hash bh=SHA-256 des kanonischen Bodys
  9. 9Signatur b=über die h=-Header und dieses Feld

Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=dnsrobot-sample

Die erfundene Beispiel-E-Mail, die diese Seite lädt (example.com, ein dafür erzeugter Schlüssel), von der Engine verifiziert.

DKIM-Check: häufig gestellte Fragen

Was ist ein DKIM-Eintrag?

Ein DKIM-Eintrag ist ein TXT-Eintrag, der den öffentlichen Schlüssel einer Domain bei selector._domainkey.domain veröffentlicht, etwa google._domainkey.example.com. Er enthält tag=value-Paare: p= ist der base64-Schlüssel und erforderlich, k= der Schlüsseltyp, t= Flags. Empfänger rufen ihn ab, um die DKIM-Signature eingehender Mails zu prüfen. Eine Domain kann viele veröffentlichen, einen pro Selektor, meist einen pro Versanddienst.

Wie finde ich meinen DKIM-Selektor?

Öffnen Sie eine beliebige E-Mail, die die Domain gesendet hat, lassen Sie sich die Original-Nachricht anzeigen und suchen Sie den DKIM-Signature-Header: Der Wert nach s= ist der Selektor, d= die Domain. In Gmail: Mehr (⋮) › Original anzeigen; in Outlook im Web: View › View message source. Oder fügen Sie die E-Mail oben unter E-Mail verifizieren ein, das liest s= und d= für Sie aus.

Warum findet der Check keinen Schlüssel, obwohl meine Mail signiert ist?

Weil das DNS keine Selektoren auflisten kann: Ein Schlüssel wird nur gefunden, wenn man seinen genauen Namen abfragt. Der Check fragt die 140 Namen ab, die Anbieter verwenden; signiert Ihre Domain mit einem anderen (Amazon SES und Postmark erzeugen einen pro Konto), sieht ihn der Durchlauf nicht. Ergänzen Sie den Selektor aus dem s= einer E-Mail, dann wird er zuerst geprüft, oder verifizieren Sie stattdessen eine E-Mail.

Ist ein 1024-Bit-DKIM-Schlüssel noch in Ordnung?

Er funktioniert noch: RFC 8301 verlangt von Verifizierern, RSA-Schlüssel von 1024 bis 4096 Bit zu akzeptieren, und Gmail und Yahoo setzen 1024 Bit als Minimum. Aber RFC 8301 verlangt von Signierern mindestens 2048 Bit, und M3AAWG nennt 1024 am Rand der Angreifbarkeit. Planen Sie eine Rotation: Microsoft 365 und Google Workspace bieten beide 2048-Bit-Schlüssel an. RFC 8301 weist Verifizierer an, Schlüssel unter 1024 Bit abzulehnen.

Was bedeutet ein leeres p=?

Ein leeres p= bedeutet, dass der Schlüssel widerrufen ist: Signaturen mit diesem Selektor fallen durch, genau als fehlte der Schlüssel. Meist ist das Absicht. Google hält seine alten datierten Selektoren so, und Fastmail und Microsoft 365 halten leere Standby-Selektoren vor, in die sie rotieren. Ein Problem ist es nur, wenn es der Selektor ist, mit dem Ihre Mail heute signiert wird.

Was bedeutet t=y in einem DKIM-Eintrag?

t=y kennzeichnet den Schlüssel als Test: Empfänger sollen damit signierte Mail wie unsignierte behandeln, auch wenn die Signatur verifiziert wird. Gedacht ist es für die erste Einrichtung, und es wird oft vergessen. t=s ist etwas anderes: Es bedeutet strikt, das i= in Signaturen muss also genau die Signaturdomain sein, keine Subdomain. Manche E-Mail-Dienste setzen t=s bei ihren Schlüsseln; die SendGrid-Schlüssel für github.com tragen es.

Warum schlägt DKIM mit „body hash did not verify“ fehl?

Der Body, den der Empfänger gehasht hat, passt nicht zum bh=-Wert der Signatur, der Body hat sich also nach dem Signieren verändert. Mailinglisten, die einen Footer anhängen, Sicherheits-Gateways, die Links umschreiben, und von einem Server hinzugefügte Disclaimer verursachen das. Wird die Header-Signatur weiterhin verifiziert, ist die Nachricht echt, aber verändert; der Verifizierer dieser Seite prüft beides getrennt.

Übersteht DKIM das Weiterleiten von E-Mails?

Meist ja. Ein Weiterleiter, der die Nachricht unverändert weitergibt, lässt die Signatur gültig, denn DKIM signiert den Inhalt, nicht den Weg. Darin unterscheidet es sich von SPF, das bei der IP-Adresse des Weiterleiters durchfällt. Weiterleiter, die die Nachricht verändern, etwa Mailinglisten mit Footern oder Betreff-Tags, brechen DKIM; ARC lässt sie für das ursprüngliche Ergebnis bürgen.

Brauche ich DKIM, wenn ich schon SPF habe?

Ja. SPF bricht beim Weiterleiten von Mails und deckt nur die verborgene MAIL-FROM-Adresse ab, während DKIM das Weiterleiten übersteht und zur From:-Domain passen kann, die DMARC prüft. Gmail und Yahoo verlangen von Massenversendern beides, Outlook.com seit Mai 2025, und RFC 9989 verlangt von Domains mit p=reject, ihre Mails mit DKIM zu signieren.

Wie oft sollte ich DKIM-Schlüssel rotieren?

M3AAWG empfiehlt mindestens alle sechs Monate. Veröffentlichen Sie den neuen Schlüssel bei einem neuen Selektor, stellen Sie das Signieren darauf um, lassen Sie den alten Schlüssel 7 bis 30 Tage veröffentlicht, damit Mails in Zustellung noch verifiziert werden, und leeren Sie dann sein p=, statt es zu löschen. Verwenden Sie einen Selektornamen nie wieder. Gehostete Anbieter mit CNAME-Selektoren rotieren die Schlüssel für Sie.

Wird meine E-Mail hochgeladen, wenn ich sie hier verifiziere?

Nein. Dieser DKIM-Validator prüft die E-Mail in Ihrem Browser: Das öffentliche DNS wird nur nach den Namen der Schlüssel gefragt (s._domainkey.d), und dnsrobot.net nur nach der DMARC-Richtlinie der From-Domain und der Signaturdomains. Die eine Ausnahme ist eine Ed25519-Signatur, die ein Browser nicht prüfen kann: Die Seite fragt dann, bevor sie die E-Mail einmal an unseren Server sendet, der sie im Arbeitsspeicher prüft und nichts speichert.

Kann ich einen Ed25519-DKIM-Schlüssel verwenden?

Ja. RFC 8463 definiert ihn und verlangt von Verifizierern, ihn zu unterstützen. Aus Gründen der Abwärtskompatibilität veröffentlichen Sie ihn bei einem eigenen Selektor neben einem RSA-Schlüssel und signieren Sie jede Nachricht doppelt, wie archlinux.org es mit dkim-ed25519 und dkim-rsa tut: Empfänger, die Ed25519 nicht verifizieren können, haben noch die RSA-Signatur. Microsoft 365 und Google Workspace bieten nur RSA-Schlüssel an.

Fehlt Ihnen etwas?Funktion oder neues Tool vorschlagen

Verwandte E-Mail- und DNS-Tools