DKIM-TXT-Record-Formatierer

DKIM-Records mit korrektem Quoting formatieren

Selector

Domain

Chunk Size

DKIM Record Value

Enter a DKIM record to format and validate

Der DKIM TXT Record Formatter wandelt öffentliche DKIM-Schlüssel in korrekt formatierte DNS-TXT-Records um, die das 255-Zeichen-String-Limit einhalten. Fügen Sie einen base64-kodierten öffentlichen Schlüssel wie einen 2048-Bit-RSA-Schlüssel ein und erhalten Sie einen korrekt aufgeteilten, zonendatei-fertigen Record für einen Selektor wie google._domainkey.example.com.

DKIM-Records verstehen

DKIM ist der E-Mail-Authentifizierungsmechanismus, der beweist, dass eine Nachricht während der Übertragung nicht manipuliert wurde. Wenn Ihr Mailserver eine E-Mail sendet, erzeugt er eine kryptografische Signatur über die Nachrichten-Header und den Body mithilfe eines privaten Schlüssels. Der zugehörige öffentliche Schlüssel wird im DNS veröffentlicht, sodass empfangende Server ihn nachschlagen und die Signatur verifizieren können. Wenn die Signatur gültig ist, weiß der Empfänger, dass die Nachricht tatsächlich von Ihrer Domain gesendet wurde und nicht verändert wurde.

Die Herausforderung bei DKIM ist nicht die Kryptografie -- Ihr Mailserver übernimmt das automatisch. Die Herausforderung besteht darin, den öffentlichen Schlüssel korrekt ins DNS zu bringen. Ein 2048-Bit-RSA-Schlüssel erzeugt einen base64-kodierten String von etwa 392 Zeichen, aber ein einzelner DNS-TXT-Record-String kann nur 255 Zeichen aufnehmen. Wenn Sie den Schlüssel direkt in die meisten DNS-Anbieter-Oberflächen einfügen, wird er entweder stillschweigend abgeschnitten (was die DKIM-Verifizierung bricht) oder der Anbieter lehnt ihn mit einer verwirrenden Fehlermeldung ab. Der Schlüssel muss in mehrere Strings in Anführungszeichen innerhalb eines einzelnen TXT-Records aufgeteilt werden, und die Aufteilung muss korrekt erfolgen, damit DNS-Resolver ihn wieder zusammensetzen können.

Dieser Formatter übernimmt die Aufteilung für Sie. Sie fügen Ihren öffentlichen Schlüssel ein, geben den Selektornamen und optionale DKIM-Tags an, und er erzeugt den vollständigen DNS-Record im korrekten Format -- fertig zum Einfügen in eine BIND-Zonendatei oder die Weboberfläche Ihres DNS-Anbieters. Er verhindert die subtilen Formatierungsfehler, die zu DKIM-Validierungsfehlern führen, die notorisch schwer zu debuggen sind, da die Symptome (E-Mails als Spam markiert oder abgelehnt) nicht offensichtlich auf ein DNS-Formatierungsproblem hindeuten.

So formatieren Sie einen DKIM-TXT-Record

Fügen Sie Ihren öffentlichen DKIM-Schlüssel ein (typischerweise ein 2048-Bit-RSA-Schlüssel in base64-Kodierung)
Geben Sie Ihren Selektor-Namen ein (z. B. google, s1, default)
Wählen Sie den Schlüsseltyp -- RSA ist Standard, Ed25519 ist aufkommend
Konfigurieren Sie optionale DKIM-Tags wie den Testmodus (t=y) oder den Diensttyp (s=email)
Der Formatter teilt den Schlüssel in 255-Zeichen-Strings mit korrekter Syntax auf
Kopieren Sie den formatierten Record für Ihre DNS-Zonendatei oder Anbieter-Oberfläche

Beispiele für DKIM-Record-Formate

Kurzer Schlüssel (1024-Bit RSA) -- Einzelner String

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSma0axspqYK49aE..."

Langer Schlüssel (2048-Bit RSA) -- Multi-String erforderlich

selector._domainkey.example.com. IN TXT (
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2UMfREvlgajdSp3jv1oI"
    "k5LDXFMxqsmSZMTpNEm0MKhDlMlSGbNyERxMnpPQKHlkNPPsFKdXJQsaJFcFP1ab"
    "jCNRQaSwrztEOLGhSV1YlfS0MkIm8v5LqlkFRm0+3kOpE+RSI0E/9IMERJ3v5ggJ"
    "QIDAQAB"
)

BIND-Zonendatei-Format

google._domainkey IN TXT ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
    "...base64data..."
    "QIDAQAB" )

DKIM-Record-Tags-Referenz

Tag	Erforderlich	Beispiel	Beschreibung
`v`	Empfohlen	`v=DKIM1`	Versionskennung
`k`	Optional	`k=rsa`	Schlüsseltyp (Standard: rsa)
`p`	Erforderlich	`p=MIIBIj...`	Base64-kodierter öffentlicher Schlüssel
`t`	Optional	`t=y`	Testmodus -- Verifizierer sollen bei Fehlern nicht eingreifen
`s`	Optional	`s=email`	Diensttyp (Standard: `*` für alle)
`h`	Optional	`h=sha256`	Akzeptierte Hash-Algorithmen

Wann Sie den DKIM-Formatter verwenden sollten

Einrichtung der DKIM-Signierung für eine neue Domain, bei der der öffentliche Schlüssel im DNS veröffentlicht werden muss
Rotation von DKIM-Schlüsseln von 1024-Bit auf 2048-Bit RSA für verbesserte Sicherheit
Hinzufügen neuer Selektoren für verschiedene E-Mail-Streams (Marketing, Transaktionen, Unternehmen)
Migration von DNS-Anbietern, bei der DKIM-Records in einem anderen Oberflächenformat neu eingegeben werden müssen
Fehlerbehebung bei DKIM-Fehlern, die durch fehlerhafte TXT-Record-Formatierung oder Abschneidung verursacht werden
Bereitstellung mehrerer Signaturschlüssel, wenn verschiedene Dienste (Google, SendGrid, Postmark) jeweils ihren eigenen Selektor benötigen

Wie DKIM-DNS-Records funktionieren

Selektor- und Domain-Struktur

Öffentliche DKIM-Schlüssel werden an einem bestimmten DNS-Speicherort nach folgendem Muster veröffentlicht:

<selector>._domainkey.<domain>

Wenn Ihr Selektor beispielsweise google und Ihre Domain example.com ist, befindet sich der Record bei google._domainkey.example.com. Der Selektor ermöglicht mehrere DKIM-Schlüssel pro Domain -- einen für jede Signierquelle.

Das 255-Zeichen-String-Limit

DNS-TXT-Records speichern Daten in einzelnen Strings von bis zu 255 Zeichen. Ein öffentlicher 2048-Bit-RSA-Schlüssel in base64-Kodierung umfasst etwa 392 Zeichen allein für die Schlüsseldaten, plus die DKIM-Tags. Der gesamte Record überschreitet leicht 255 Zeichen, sodass der Wert auf mehrere Strings in Anführungszeichen aufgeteilt werden muss.

DNS-Resolver verketten automatisch mehrere Strings in einem TXT-Record zu einem einzelnen Wert. Die Trennpunkte können überall in den Daten liegen -- sogar mitten im Wort -- da die Verkettung auf Byte-Ebene und nicht semantisch erfolgt.

Überlegungen zur Schlüsselgröße

Schlüsselgröße	Base64-Schlüssellänge	Multi-String nötig?
1024-Bit RSA	~216 Zeichen	In der Regel nicht
2048-Bit RSA	~392 Zeichen	Ja
4096-Bit RSA	~736 Zeichen	Ja, mehrfache Aufteilung
Ed25519	~44 Zeichen	Nein

2048-Bit RSA ist der aktuelle Industriestandard. Schlüssel kürzer als 1024 Bit gelten als unsicher und können von Empfängern abgelehnt werden. Ed25519-Schlüssel sind deutlich kürzer, werden aber noch nicht universell unterstützt.

DKIM-Schlüsselverwaltung in der Praxis

Der häufigste DKIM-Bereitstellungsfehler ist, den Schlüssel falsch zu veröffentlichen und ihn nicht zu überprüfen. Nachdem Sie den TXT-Record zum DNS hinzugefügt haben, sollten Sie ihn immer bestätigen, indem Sie den Record mit einem Tool wie dig oder nslookup abfragen und den zurückgegebenen Wert mit dem ursprünglichen öffentlichen Schlüssel vergleichen. Die DNS-Propagierung kann je nach Ihren TTL-Einstellungen Minuten bis Stunden dauern, warten Sie also entsprechend vor dem Testen. Eine schnelle Prüfung ist dig TXT selector._domainkey.example.com und die Überprüfung, dass der vollständige base64-Schlüssel ohne Abschneidung in der Antwort erscheint.

Schlüsselrotation ist ein weiterer Bereich, in dem Administratoren oft stolpern. Best Practice ist, ein neues Schlüsselpaar mit einem neuen Selektor zu generieren, den neuen öffentlichen Schlüssel im DNS zu veröffentlichen, auf die Propagierung zu warten, Ihren Mailserver auf die Signierung mit dem neuen privaten Schlüssel umzustellen und erst dann den alten öffentlichen Schlüssel aus dem DNS zu entfernen. Wenn Sie den alten Schlüssel entfernen, bevor alle in Übertragung befindlichen Nachrichten zugestellt und verifiziert wurden, werden diese Nachrichten die DKIM-Prüfung nicht bestehen. Ein guter Ansatz ist, den alten Schlüssel mindestens eine Woche nach dem Selektorwechsel veröffentlicht zu lassen, damit zwischengespeicherte Nachrichten Zeit haben, zugestellt zu werden.

Wenn Sie DKIM zum ersten Mal einrichten, verwenden Sie zunächst das t=y-Testflag. Dies teilt empfangenden Servern mit, dass Ihre Domain im DKIM-Testmodus ist und sie bei Verifizierungsfehlern keine Maßnahmen ergreifen sollten. Sobald Sie bestätigt haben, dass die Signierung korrekt funktioniert, indem Sie DMARC-Aggregatberichte prüfen, entfernen Sie das t=y-Flag, um die vollständige Durchsetzung zu aktivieren. Wenn t=y dauerhaft belassen wird, wird der Sicherheitswert von DKIM untergraben, da Empfänger Fehler ignorieren.

Häufig gestellte Fragen

Warum schlägt mein DKIM-Record nach dem Einfügen ins DNS bei der Validierung fehl?

Die häufigste Ursache ist eine fehlerhafte String-Aufteilung. Wenn Ihr DNS-Anbieter keine Multi-String-TXT-Records unterstützt oder lange Werte abschneidet, sind die öffentlichen Schlüsseldaten unvollständig und die DKIM-Verifizierung schlägt fehl. Verwenden Sie diesen Formatter, um eine korrekte Aufteilung sicherzustellen, und überprüfen Sie dann, ob der veröffentlichte Record mit dem erwarteten Wert übereinstimmt, indem Sie dig TXT selector._domainkey.ihredomain.com verwenden.

Kann ich mehrere DKIM-Records für eine Domain haben?

Ja. Anders als bei SPF unterstützt DKIM mehrere Schlüssel durch verschiedene Selektoren. Jedes E-Mail-System (Google Workspace, SendGrid, Mailchimp) verwendet seinen eigenen Selektor, sodass ihre Schlüssel nicht kollidieren. Zum Beispiel koexistieren google._domainkey.example.com und sendgrid._domainkey.example.com problemlos.

Was bewirkt t=y (Testmodus)?

Wenn t=y gesetzt ist, sollten empfangende Mailserver DKIM-Verifizierungsfehler so behandeln, als wäre die Domain nicht signiert. Dies ermöglicht es Ihnen, einen DKIM-Schlüssel zu veröffentlichen und E-Mails zu signieren, ohne das Risiko von Zustellfehlern, während Sie die Konfiguration überprüfen. Entfernen Sie t=y, sobald die Tests abgeschlossen sind, um die vollständige DKIM-Durchsetzung zu aktivieren.

Sollte ich 2048-Bit- oder 4096-Bit-RSA-Schlüssel verwenden?

2048-Bit RSA ist der aktuelle Standard und wird von allen großen E-Mail-Anbietern akzeptiert. Obwohl 4096-Bit-Schlüssel stärkere Sicherheit bieten, erzeugen sie sehr lange TXT-Records, die einige DNS-Anbieter nur schwer verarbeiten können, und sie vergrößern die DKIM-Signatur-Header in jeder E-Mail. Die Sicherheitsverbesserung gegenüber 2048-Bit ist für E-Mail-Authentifizierungszwecke marginal. Verwenden Sie 2048-Bit, es sei denn, Ihre Sicherheitsrichtlinie erfordert ausdrücklich längere Schlüssel.

Was ist Ed25519 und sollte ich es verwenden?

Ed25519 ist ein Algorithmus auf Basis elliptischer Kurven, der deutlich kürzere Schlüssel (~44 Zeichen) und Signaturen als RSA erzeugt, wodurch DNS-Records und E-Mail-Header kleiner werden. Allerdings ist die Ed25519-DKIM-Unterstützung bei empfangenden Mailservern noch nicht universell. Wenn Sie Ed25519 einführen, veröffentlichen Sie sowohl einen Ed25519-Schlüssel als auch einen 2048-Bit-RSA-Schlüssel unter verschiedenen Selektoren und signieren Sie mit beiden. Empfänger, die Ed25519 unterstützen, werden es verwenden; andere fallen auf RSA zurück.