DKIM-Key-Tester — Selektor-Validierung und Schlüssellängenschätzung

Drei zuverlässige Wege. Erste Möglichkeit: Senden Sie sich eine Testnachricht von der zu prüfenden Domain, dann zeigen Sie den Rohnachrichten-Quelltext an (in Gmail: „Original anzeigen"; in Outlook: „Quelltext anzeigen"). Finden Sie den DKIM-Signature-Header und suchen Sie das s=-Tag — sein Wert ist der Selektor. Zweite Möglichkeit: Prüfen Sie die Admin-Konsole des Versanddienstes: Google Workspace zeigt den Selektor unter Admin → Apps → Google Workspace → Gmail → E-Mail authentifizieren; Microsoft 365 nutzt selector1 und selector2 als Default; die meisten ESPs dokumentieren ihre Selektoren in Setup-Anleitungen. Dritte Möglichkeit: Wenn Sie mehrere Versanddienste haben und alle finden wollen, führen Sie den Tester gegen die häufigen Ihres Stacks aus: Google Workspace nutzt google, Microsoft 365 nutzt selector1 und selector2, Mailchimp nutzt k1 oder k2, SendGrid nutzt s1 und s2.

2048-Bit. Der Fall für 4096-Bit ist auf dem Papier real — mehr Entropie, längerer Zeithorizont gegen Fortschritte in Kryptoanalyse — aber in der operativen Praxis sprechen zwei Dinge dagegen. Zum einen erzeugt ein 4096-Bit-Schlüssel einen Public-Key-Record von etwa 736 Base64-Zeichen; mit den umgebenden Tags und unter Berücksichtigung des 255-Zeichen-TXT-String-Limits liegen Sie zuverlässig über der Schwelle, ab der manche DNS-Anbieter und manche Receiver den Multi-String-TXT-Record inkonsistent behandeln. Zum anderen ist die marginale Sicherheitsverbesserung von 4096 gegenüber 2048 für kein Bedrohungsmodell, das DKIM adressiert, tragend — DKIM signiert an der Grenze des E-Mail-Transits, wo das relevante Angriffsfenster Stunden bis Tage sind, nicht die Jahrzehnt-Überlegungen, die anderswo 4096 motivieren.

Die praktische Antwort: 2048-Bit für alles, außer Sie haben eine konkrete Compliance-Anforderung, die 4096 vorschreibt. Rotieren Sie alle 6-12 Monate, und die Rotationskadenz leistet mehr für die Sicherheit als die zusätzlichen Schlüssel-Bit jemals würden.

Die exakte RSA-Moduluslänge zu berechnen, erfordert das Decodieren des Base64 zu ASN.1 DER und das Parsen des BIT STRING. Der Tester läuft vollständig im Browser ohne ASN.1-Parser im Bundle, also schätzt er die Schlüsselgröße aus der Base64-String-Länge: RSA-1024-Bit-Schlüssel erzeugen ~216 Base64-Zeichen (plus/minus einige für den ASN.1-Header), 2048-Bit erzeugen ~392, 4096-Bit erzeugen ~736. Das Mapping ist innerhalb der standardisierten RSA-Schlüsselgrößen präzise; die Schätzung sagt Ihnen korrekt, ob Sie bei 1024, 2048 oder 4096 sind, auch wenn sie nicht sagen kann, ob der Modulus exakt 2048 oder 2080 Bit hat. Für praktische Zwecke — die Frage ist „1024 oder 2048?", nicht „ist es exakt 2048?" — ist diese Präzision die nötige.

Vorsichtig, mit Dual-Signing als Sicherheitsnetz. RFC 8463 definierte Ed25519 für DKIM 2018, und die Kryptografie ist genuin stark — Ed25519-Schlüssel sind 256 Bit (viel kleiner als RSA), Signaturen sind 64 Byte, und Verifikation ist schneller. Das Problem ist der Receiver-Support: nicht jede MTA, jeder Spamfilter, jedes Legacy-Enterprise-Gateway weltweit hat aufgeholt. Manche Receiver behandeln eine nur mit Ed25519 signierte Nachricht immer noch als DKIM-Fail, weil ihre Software nicht weiß, wie sie zu verifizieren ist. Das funktionierende Deployment-Muster: signieren Sie mit beidem, RSA-SHA256 (unter einem Selektor) und Ed25519 (unter einem anderen). Receiver, die beides verstehen, validieren das stärkere; Receiver, die nur RSA kennen, validieren RSA und ignorieren Ed25519. Sie bekommen die Vorteile neuerer Kryptografie ohne Fehlerfall für ältere Receiver.

DMARC-Alignment verlangt, dass die Signing-Domain (das d=-Tag im DKIM-Signature-Header) zur From-Header-Domain passt — exakt unter strenger Ausrichtung (adkim=s in Ihrem DMARC-Record) oder organisatorisch unter relaxter Ausrichtung (adkim=r, Default, wo mail.beispiel.de mit beispiel.de aligned). DKIM kann kryptografisch bestehen, während DMARC-Alignment scheitert, wenn die Nachricht von einer völlig anderen Domain signiert wird — häufig, wenn ein Drittanbieter (eine Newsletter-Plattform, ein CRM, das in Ihrem Namen sendet) mit seiner eigenen Domain statt Ihrer signiert. Der Fix: diesen Sender Ihre Domain signieren lassen — die meisten modernen transaktionalen ESPs und Marketing-Plattformen unterstützen einen „mit Ihrer Domain signiert"-Modus, oft „Branded Sending" oder „signed-by-customer DKIM" genannt.

Wann immer der Schlüssel ohnehin zur Sprache kommt — beim Initial-Setup, vor und nach jeder Schlüsselrotation, beim Onboarding eines neuen Versanddienstes mit eigenem Selektor und vierteljährlich als Wartungscheck, um stille Fehler zu fangen. Der häufigste Grund, warum ein zuvor funktionierender DKIM-Record aufhört zu funktionieren, ist eine DNS-Migration: das Team verschiebt DNS zu einem neuen Anbieter, dessen Oberfläche lange TXT-Records anders als die alte handhabt, und der Record wird beim Import abgeschnitten oder fehlerhaft quotiert. Ein vierteljährlicher DKIM-Check über jeden genutzten Selektor fängt die Regression in Wochen statt nach zwei Monaten DMARC-Spam-Berichten.