Dkim Record Generator
E-Mail-Authentifizierungssuite

DNS DKIM TXT Record Builder & Selector Helper

Erstellen Sie RFC 6376-konforme DNS-DKIM-TXT-Einträge mit Selektor, Public-Key-Formatierung (v=DKIM1; k=rsa; p=...), 255-Zeichen-Aufteilung und Prüfroutinen.

100% clientseitige Privatsphäre
RFC 1035 255-Byte Safe
Voreinstellungen:
DNS-Hostname:google._domainkey.example.com
RSA 1024-bit (Legacy / Deprecated)
Erweiterte RFC 6376 Parameter
Eintragstyp
TXT
Host / Name
google._domainkey
TTL (Time to Live)
3600 Sekunden
TXT-Eintragswert (Vollständig ungeteilt):352 Zeichen
v=DKIM1; s=email; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3Q2kZ4+jX6s1aL9mB/8uI7fUvX1Q2W3E4R5T6Y7U8I9O0P1A2S3D4F5G6H7J8K9L0M1N2O3P4Q5R6S7T8U9V0W1X2Y3Z4a5b6c7d8e9f0g1h2i3j4k5l6m7n8o9p0q1r2s3t4u5v6w7x8y9z0A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0U1V2W3X4Y5Z6a7b8c9d0e1f2g3h4i5j6k7l8m9n0o1p2q3r4s5t6u7v8w9x0y1z2A3B4C5D6E7F8G9H0I1J2K3L4M5N6O7P8QIDAQAB
RFC 6376 Tag-Aufschlüsselung
TagWert
v=DKIM1
k=rsa
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...
s=email
Selector FQDN
google._domainkey.example.com
Abfrageziel für Mail-Relays
Algorithmus
RSA 1024-bit
RSA 1024-bit (Legacy / Deprecated)
RFC 6376 Compliance
Gültig & Verifiziert
2 strings chunked (<255B)

Zero-Knowledge Lokale Ausführung

Alle Datenverarbeitungen, Parsen und Generierungen laufen streng im lokalen Browserspeicher ab. Keine externen Server-Uploads.

Sub-Millisekunden AST-Engine

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Technische Referenz & Architektur-Leitfaden

DNS DKIM TXT-Eintrag-Generator & Selektor — Referenz-Leitfaden

Erstellen Sie RFC 6376-konforme DNS-DKIM-TXT-Einträge mit Selektor, Public-Key-Formatierung (v=DKIM1; k=rsa; p=...), 255-Zeichen-Aufteilung und Prüfroutinen.

Wichtige Parameter & Steuerelemente

Selektor (s)String (Alphanumerisch/Bindestrich)

Das Selektor-Präfix, das den DNS-Host unter <selector>._domainkey.<domain> bestimmt. Ermöglicht mehrere parallele Signaturschlüssel für E-Mail-Dienstleister und unterbrechungsfreie Schlüsselrotation.

Standard: default
Öffentlicher Schlüssel (p)Base64-String

Der Base64-kodierte ASN.1 DER SubjectPublicKeyInfo-Schlüssel. PEM-Header (-----BEGIN/END PUBLIC KEY-----) und Zeilenumbrüche müssen zwingend entfernt werden. Ein leerer Wert (p=) widerruft den Schlüssel offiziell.

Standard: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
Schlüsselalgorithmus (k)Enum (rsa | ed25519)

Das kryptografische Asymmetrieverfahren. 'rsa' garantiert maximale Kompatibilität mit globalen MTAs; 'ed25519' (RFC 8463) bietet kompakte Signaturen bei exzellenter Performance.

Standard: rsa
Betriebs-Flags (t)Flags (y | s | y:s | Keine)

Steuerungsflags für den Validierungsvorgang. 'y' markiert den Testmodus (Empfänger lehnen fehlerhafte Signaturen nicht ab); 's' untersagt die Gültigkeit für Subdomains und verlangt strikte Domain-Übereinstimmung.

Standard: Keine
Diensttyp (s)Enum (* | email)

Beschränkt den Verwendungszweck des Schlüssels. 'email' limitiert die Gültigkeit auf E-Mail-Nachrichten, während '*' alle Dienste zulässt.

Standard: *

Profi-Tipps & Best Practices

Gemäß RFC 1035 darf eine einzelne

Gemäß RFC 1035 darf eine einzelne Zeichenkette innerhalb eines TXT-Eintrags maximal 255 Oktette umfassen. Ein 2048-Bit-RSA-Schlüssel erzeugt rund 392 Zeichen. In BIND-Zonendateien wird der Wert in Klammern gesetzt und in zwei aufeinanderfolgende Anführungszeichen aufgeteilt: ("v=DKIM1; k=rsa; p=teil1..." "teil2..."). Moderne DNS-Provider führen dies automatisch zusammen.

Branchenstandards von Google

Branchenstandards von Google, Yahoo und der M3AAWG stufen 1024-Bit-RSA-Schlüssel als kryptografisch unzureichend ein. 2048-Bit gilt als Mindeststandard. Vermeiden Sie 4096-Bit-Schlüssel, da übergroße DNS-Antwortpakete das UDP-Limit von 512 Bytes überschreiten und TCP-Fallback-Verzögerungen erzwingen können.

Überschreiben Sie niemals einen

Überschreiben Sie niemals einen bestehenden Produktivschlüssel direkt. Veröffentlichen Sie einen neuen Schlüssel mit zeitbasiertem Selektor (z. B. 2026q4), verifizieren Sie die weltweite DNS-Propagierung via dig, stellen Sie den MTA-Signierdienst um und belassen Sie den alten Selektor für 7-14 Tage im DNS, um verzögerte E-Mails zu validieren.

Sollte ein privater Schlüssel

Sollte ein privater Schlüssel kompromittiert werden, löschen Sie den DNS-Eintrag nicht einfach. Publizieren Sie stattdessen 'v=DKIM1; p=' unter dem betroffenen Selektor. Dieses explizite Widerrufssignal weist empfangende Mailserver an, Signaturen unter diesem Selektor sofort abzuweisen.

Häufige Fallstricke & Fehlerbehebung

Empfänger meldet 'dkim=fail (bad signature)' oder Schlüssel wird nicht gefunden

Überprüfen Sie, ob der DNS-Eintrag exakt unter <selector>._domainkey.<domain> angelegt wurde (der Namensbestandteil '._domainkey' darf nicht fehlen). Stellen Sie sicher, dass keine PEM-Header ('-----BEGIN PUBLIC KEY-----'), Leerzeichen oder Zeilenumbrüche im p=-Wert verblieben sind.

DNS-Webkonsole meldet 'String too long' oder Syntaxfehler beim Speichern

Wenn Ihr DNS-Registrar Strings über 255 Zeichen nicht automatisch teilt, tragen Sie den TXT-Wert in getrennten Anführungszeichen innerhalb von Klammern ein oder wechseln Sie die Zone zu einem DNS-Anbieter mit nativer Multi-String-Verwaltung (z. B. Cloudflare).

DKIM ist einzeln valide, aber DMARC meldet 'dkim=fail (unaligned)'

DMARC verlangt ein Identifier Alignment zwischen der Domain im d=-Tag der DKIM-Signatur und der sichtbaren 'From:'-Adresse. Bei Drittanbietern (z. B. SendGrid) muss ein Custom DKIM mit eigener Subdomain per CNAME eingerichtet werden, anstelle der standardmäßigen Anbieterdomain.

Häufig gestellte Fragen (FAQ)

Worin liegt der fundamentale Unterschied zwischen DKIM, SPF und DMARC?▼

SPF prüft, ob die IP-Adresse des versendenden Mailservers für die Envelope-Sender-Domain (Return-Path) autorisiert ist. DKIM garantiert durch kryptografische Signaturen die Unverfälschtheit von E-Mail-Headern und Body. DMARC verknüpft beide Prüfungen, vergleicht die Domain mit der sichtbaren From-Adresse (Alignment) und weist den Empfänger an, wie mit Verstößen verfahren werden soll (none, quarantine, reject).

Warum ist die Angabe eines Selektors bei DKIM zwingend erforderlich?▼

Der Selektor dient als Unterverzeichnis im DNS (_domainkey), wodurch eine Domain mehrere unterschiedliche kryptografische Schlüsselpaare gleichzeitig verwalten kann. Dies erlaubt die Trennung verschiedener E-Mail-Systeme (z. B. Microsoft 365 und Marketing-Newsletter) und ermöglicht regelmäßige Schlüsselwechsel ohne Systemunterbrechung.

Wie wird ein 2048-Bit-RSA-Schlüssel im DNS-TXT-Eintrag technisch aufgeteilt?▼

Nach RFC 1035 darf kein einzelner String in einem TXT-Eintrag mehr als 255 Zeichen enthalten. Ein 2048-Bit-RSA-Schlüssel (~392 Zeichen) wird im Zonendokument in zwei Strings geteilt: ("v=DKIM1; k=rsa; p=ERSTER_TEIL..." "ZWEITER_TEIL..."). Validierende Resolver fügen diese Teilzeichenketten nahtlos und ohne Zwischenraum wieder zusammen.

Kann Ed25519 (RFC 8463) anstelle von RSA für DKIM eingesetzt werden?▼

Ja, RFC 8463 spezifiziert DKIM-Signaturen mit Ed25519-Elliptic-Curve-Kryptografie. Ein Ed25519-Public-Key ist im Base64-Format nur 44 Zeichen lang und benötigt keine 255-Zeichen-Aufteilung. Da jedoch einige ältere Unternehmens-Gateways Ed25519 noch nicht unterstützen, empfiehlt sich aktuell RSA 2048-Bit oder Dual-Signing (paralleles Signieren mit RSA und Ed25519).

Wie überprüfe ich, ob der DKIM-Eintrag weltweit korrekt im DNS propagiert wurde?▼

Nutzen Sie im Terminal den Befehl 'dig TXT <selector>._domainkey.<domain> +short' oder 'nslookup -type=TXT <selector>._domainkey.<domain>'. Senden Sie zudem eine Test-E-Mail an externe Dienste wie Gmail und analysieren Sie im Original-Header die Zeile 'Authentication-Results: dkim=pass'.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →