Wie richtet ein Produktteam DKIM sicher ein?

Alle realen ausgehenden Pfade erfassen, bevor Sie einen Schlüssel erzeugen

Beginnen Sie mit einer Bestandsaufnahme, nicht mit einem DNS-Eintrag. Listen Sie jedes System auf, das E-Mails mit den sichtbaren From-Domains der Organisation senden kann: Anwendungs-Worker, transaktionale Provider, Marketing-Plattformen, Support-Tools, Identitätssysteme, Ticketsysteme, Relays und Notfallpfade. Erfassen Sie für jedes System Eigentümer, Nachrichtenklassen, Envelope-Absender, sichtbare From-Domain, aktuelle DKIM-d=-Domain, Selektor, signierende Komponente und ob ein weiteres Relay die Nachricht später verändert. Ein für einen Provider veröffentlichter DKIM-Schlüssel bewirkt nichts auf einem anderen Pfad, der dessen privaten Schlüssel nie verwendet. Ebenso beweist ein generisches Provider-Dashboard mit einer verifizierten Domain nicht, dass jeder Mandant, jede Region, jeder Stream, jedes Template oder jeder Fallback signiert ist. Verwenden Sie kontrollierte Beispiele von jedem Pfad und bewahren Sie die ursprünglichen Header auf. Entscheiden Sie, welche Pfade autorisiert sind, bevor Sie Signierung aktivieren; DKIM authentifiziert die Verantwortung einer Domain für eine Signatur, nicht Empfängereinwilligung oder den Wahrheitsgehalt des Nachrichteninhalts.

Eine Signaturdomain wählen, die DMARC-Alignment ermöglicht

Das DKIM-Tag d= bezeichnet die signierende Domain. Wählen Sie eine Domain, die die Organisation kontrolliert und über die gesamte Lebensdauer des E-Mail-Streams verwalten kann. Wenn DMARC auf DKIM setzt, muss die Domain in d= nach der jeweils geltenden entspannten oder strikten Alignment-Regel mit der Domain im sichtbaren From-Feld nach RFC 5322 übereinstimmen. Eine Signaturdomain des Providers kann ein gültiges DKIM-Ergebnis liefern und trotzdem nicht mit der From-Domain der Organisation aligned sein. Entscheiden Sie, ob die Apex-Domain oder eine zweckgebundene Subdomain den jeweiligen Stream signieren soll, und berücksichtigen Sie dabei Zuständigkeit, Trennung der Reputation, delegiertes DNS und Isolierung bei Vorfällen. Erfinden Sie keine zusätzlichen Domains, nur um ein Reputations- oder Richtlinienproblem zu umgehen. Dokumentieren Sie die Beziehung zur Organisationsdomain und den vorgesehenen DMARC-Modus. Testen Sie das Alignment anhand der endgültig empfangenen Header; leiten Sie es nie allein aus einer Selektor-Abfrage ab, denn die Nachricht könnte einen anderen d=-Wert verwenden.

Selektoren als betriebliche Identitäten vergeben

Ein Selektor ermöglicht einer Domain, mehrere Schlüssel zu veröffentlichen und zu ändern, ohne einen globalen Eintrag zu ersetzen. Erstellen Sie eine deterministische Selektor-Richtlinie, die Provider oder Signierer und eine Rotationsgeneration bezeichnet, ohne Geheimnisse preiszugeben. product-a-2026q3 kann zum Beispiel klarer als default sein, halten Sie Namen aber innerhalb der DNS-Konventionen und Grenzen Ihrer Tools. Verwenden Sie niemals denselben privaten Schlüssel bei unabhängigen Providern, Umgebungen oder Mandanten nur, um DNS-Einträge zu reduzieren. Führen Sie ein Register mit Selektor, d=-Domain, Zweck, Signierdienst, Eigentümer, Erstellungszeit, Algorithmus, Public-Key-Fingerprint, Deployment-Status, Rotationsfrist und Beleg für Ausmusterung. Prüfen Sie den exakten Selektornamen vor der Veröffentlichung: Der Lookup lautet `selector._domainkey.signing-domain`. Ein versehentlicher Eintrag an der sichtbaren From-Domain, Return-Path-Domain oder in der falschen DNS-Zone verifiziert die beabsichtigte Signatur nicht. Löschen Sie einen alten Selektor erst, wenn verzögerte und damit signierte E-Mails sowie Wiederholungsversuche abgelaufen sind.

Den privaten Schlüssel erzeugen und schützen

Erzeugen Sie das Schlüsselpaar in einem verwalteten Schlüsseldienst oder einem streng kontrollierten Signatursystem, sofern der Provider das unterstützt. Der private Schlüssel darf niemals in öffentliches DNS, die Versionsverwaltung, Browser-Code, CI-Ausgaben, Analysen, gewöhnliche Logs, Tickets, Dokumente, Prompts oder gemeinsame Chats gelangen. Gewähren Sie Signaturzugriff nur der E-Mail-Komponente, die den Schlüssel braucht, trennen Sie den Produktivbetrieb von niedrigeren Umgebungen und protokollieren Sie administrativen Zugriff. RFC 8301 aktualisiert die kryptografischen Anforderungen an DKIM: Signierer müssen RSA-Schlüssel mit mindestens 1024 Bit verwenden und sollten mindestens 2048 Bit verwenden; zugleich weist RFC 8301 auf betriebliche DNS-Einschränkungen bei größeren Schlüsseln hin. Richten Sie sich nach den aktuellen Fähigkeiten und Empfehlungen des gewählten Signierers und der Empfängerlandschaft, statt ein veraltetes Beispiel zu kopieren. Falls Sie Ed25519 in Betracht ziehen: RFC 8463 definiert dessen Einsatz für DKIM, die Interoperabilität muss aber getestet und bei Bedarf eine kompatible Signaturstrategie beibehalten werden. Die Rotation muss möglich sein, ohne den privaten Schlüssel zu exportieren.

Den öffentlichen Schlüssel exakt veröffentlichen

Veröffentlichen Sie einen TXT-Eintrag unter dem exakten Owner-Namen `selector._domainkey.signing-domain`. Der DKIM-Schlüsseleintrag enthält Tags wie v=DKIM1, bei Bedarf einen Schlüsseltyp und p= mit dem Material des öffentlichen Schlüssels ohne Wrapper für private Schlüssel. Befolgen Sie das exakte Eintragsformat des Signierers und das Anführungsverhalten Ihres DNS-Providers. Prüfen Sie vor dem Speichern, ob die DNS-Oberfläche die Zone automatisch anhängt, lange Strings teilt oder Zeichen maskiert. Fragen Sie nach der Veröffentlichung direkt die autoritativen Nameserver ab, dann unabhängige rekursive Resolver, und setzen Sie den vollständigen TXT-Wert wieder zusammen. Mehrere Zeichen-Strings eines TXT-Eintrags werden von DNS-Clients verkettet, konkurrierende Resource Records können dagegen Mehrdeutigkeit erzeugen. Bewahren Sie die vorherige Antwort und TTL für ein Rollback auf. Senken Sie die Sicherheit nicht durch einen breiteren Schlüssel oder ein Test-Flag im Produktivbetrieb, nur um einen Checker ruhigzustellen. Ein sichtbarer Eintrag beweist DNS-Veröffentlichung, nicht die Verwendung des passenden privaten Schlüssels durch den Absender.

Den letzten Signierer und die signierten Felder konfigurieren

Konfigurieren Sie die Komponente, die die fertige Nachricht an den ausgehenden Transport übergibt, oder stellen Sie sicher, dass keine spätere Komponente signierte Inhalte verändert. Eine DKIM-Signatur umfasst einen Body-Hash und die in h= genannten Header-Felder. RFC 6376 verlangt für eine gültige Signatur, dass das Header-Feld From signiert wird. Beziehen Sie identitätskritische Header ein, die für das Produkt relevant sind, verstehen Sie, wie wiederholte Header ausgewählt werden, und signieren Sie keine Felder, die ein notwendiges nachgelagertes System umschreiben muss, sofern diese Transformation nicht kontrolliert ist. Wählen Sie die Kanonisierung bewusst. Die Kanonisierung relaxed toleriert definierte Änderungen an Leerzeichen und Header-Formatierung, erlaubt aber keine beliebigen Änderungen am Body. Die Kanonisierung simple ist anfälliger. Eingefügte Footer, umgeschriebene Links, geänderte MIME-Boundaries, eine Konvertierung der Transfer-Kodierung, Betreff-Tags und normalisierte Zeilenenden nach dem Signieren können die Verifizierung scheitern lassen. Signieren Sie die vollständig gerenderte Nachricht nach allen genehmigten Transformationen und verhindern Sie, dass nicht vertrauenswürdige Nutzer d=, s=, Header-Listen oder Schlüssel auswählen.

Empfangene Originalnachrichten Ende-zu-Ende verifizieren

Senden Sie kontrollierte Nachrichten über jeden realen, produktionsnahen Pfad an externe Testpostfächer, die das Team betreibt. Bewahren Sie die rohe Originalnachricht auf, nicht einen kopierten Body oder einen neu serialisierten Ticket-Anhang. Prüfen Sie in DKIM-Signature die Werte d= und s=, die Liste signierter Header, den Body-Hash, den Algorithmus, die Kanonisierung, den Zeitstempel und ein etwaiges Ablaufdatum. Fragen Sie den öffentlichen Schlüssel aus einem unabhängigen Netzwerk ab und führen Sie einen standardkonformen Verifizierer auf den Originalbytes aus. Vergleichen Sie den Header Authentication-Results des vertrauenswürdigen Empfängers mit Ihrem Verifizierer und beachten Sie dabei die Vertrauensgrenzen nach RFC 8601. Testen Sie Plain-Text, multipart/alternative, erwartete Anhänge, Unicode-Betreffzeilen, lange Header, Templates, Tracking-Transformationen, Wiederholungsversuche und Relay-Pfade. Negativtests sollten einen absichtlich geänderten signierten Header in einer Test-Fixture, einen fehlenden Selektor, einen abgelaufenen oder außer Betrieb genommenen Selektor und einen Pfad umfassen, der das Signieren umgeht. Manipulieren Sie niemals echte Kunden-E-Mails, um einen Test zu erzeugen.

DKIM, DMARC und Zustellung als getrennte Ergebnisse bewerten

Ein DKIM-Pass bedeutet, dass der Verifizierer für die identifizierte Signierdomain eine gültige Signatur über die signierten Felder und den Body gefunden hat. Er authentifiziert nicht jeden unsignierten Header, bestätigt keinen menschlichen Autor, beweist keine Empfängereinwilligung, begründet keine Rechtskonformität und garantiert weder Annahme noch Platzierung im Posteingang. DMARC wertet getrennt aus, ob eine bestehende DKIM- oder SPF-Domain mit der sichtbaren From-Domain ausgerichtet ist, und wendet die Richtlinie des Domaininhabers an. Zeichnen Sie für kontrollierte Tests mindestens DKIM-Ergebnis und Grund, d=-Domain, Selektor, sichtbare From-Domain, Alignment-Ergebnis, SPF-Ergebnis, DMARC-Ergebnis, Empfänger und Zeitstempel auf. Halten Sie vollständige Empfängeradressen und Inhalte aus Routine-Metriken heraus. SMTP-Provider-Annahme, Empfänger-Server-Annahme, späterer Bounce, Postfachordner-Platzierung und Engagement sind spätere Zustände. Wenn DKIM besteht, eine E-Mail aber abgelehnt oder gefiltert wird, untersuchen Sie DMARC-Alignment, SPF, IP- und Domainreputation, Beschwerderate, Nachrichtenrichtlinie, Rate und Empfängervorgaben, statt Schlüssel wiederholt zu rotieren.

Ohne Verifizierungslücke rotieren

Verwenden Sie überlappende Selektoren. Erzeugen Sie zuerst einen neuen geschützten Schlüssel und veröffentlichen Sie dessen öffentlichen Eintrag unter einem neuen Selektor. Prüfen Sie autoritatives und rekursives DNS, konfigurieren Sie den Signierer für den neuen Selektor und senden Sie kontrollierte Tests über jeden Pfad. Überwachen Sie den Anteil der Signaturen mit altem und neuem Selektor und deren Verifizierungsergebnisse. Halten Sie den alten öffentlichen Schlüssel über das maximale Alter von Nachrichten in der Warteschlange, das Retry-Fenster und die DNS-Cache-Dauer hinaus verfügbar, zuzüglich einer ausdrücklichen Sicherheitsreserve. Beenden Sie dann jedes Signieren mit dem alten Selektor, bestätigen Sie, dass keine aktive Konfiguration mehr darauf verweist, und nehmen Sie seinen Eintrag gemäß Richtlinie außer Betrieb. Ein Notfall-Widerruf nach Offenlegung des privaten Schlüssels kann eine schnellere Entfernung, eine Versandpause, die Rotation der Provider-Zugangsdaten und Kommunikation zum Vorfall erfordern; dokumentieren Sie diese Abwägung im Voraus. Überschreiben Sie bei einer routinemäßigen Rotation keinen Selektor an Ort und Stelle, denn zwischengespeicherte alte öffentliche Schlüssel können dann bei Nachrichten, die mit dem neuen privaten Schlüssel signiert wurden, zu Verifizierungsfehlern führen.

Fehler von der Signatur ausgehend diagnostizieren

Fehlt eine Signatur, ermitteln Sie, ob die Nachricht einen unsignierten Stream, eine nicht autorisierte From-Domain, ein Fallback-Relay oder einen bestimmten Template-Pfad genutzt hat. Wird der Schlüssel nicht gefunden, prüfen Sie die genaue Abfrage aus s= und d=, die Delegierung der Zone, die autoritative Antwort, DNSSEC- oder Resolver-Fehler und die Propagierung. Weicht der Body-Hash ab, vergleichen Sie das rohe MIME vor dem Signieren mit dem empfangenen, um Transformationen nach dem Signieren zu finden. Passt die Signatur nicht, prüfen Sie, ob der veröffentlichte öffentliche Schlüssel zum aktiven privaten Schlüssel passt, und untersuchen Sie Kanonisierung und signierte Header. Besteht DKIM, aber DMARC schlägt fehl, bewerten Sie das Alignment mit der sichtbaren From-Domain. Unterscheiden Sie vorübergehende DNS-Abfragefehler von dauerhaften Konfigurationsfehlern und nutzen Sie begrenzte Wiederholungsversuche beim Transport nur, wenn die SMTP-Antwort auf einen vorübergehenden Fehler hinweist. Pausieren Sie den betroffenen Stream bei domainübergreifendem Signieren, unbekannten Schlüsseln, weit verbreiteten Verifizierungsfehlern oder Verdacht auf Offenlegung eines Schlüssels. Bewahren Sie datensparsame Nachweise auf und ändern Sie pro kontrolliertem Wiederholungstest nur eine Variable.

Verwenden Sie die DKIM-Dokumentation Ihres Versandsystems

Richten Sie DKIM in den tatsächlichen Versandsystemen und der DNS-Autorität ein, validieren Sie ursprüngliche empfangene Nachrichten und stützen Sie sich auf aktuelle IETF-Standards und Provider-spezifische Dokumentation.

Häufig gestellte Fragen

Quellen

• RFC 6376: DomainKeys Identified Mail Signatures — RFC-Editor
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM – RFC Editor
• RFC 8463: A New Cryptographic Signature Method for DKIM – RFC Editor
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC-Editor
• RFC 8601: Message Header Field for Indicating Message Authentication Status – RFC Editor
• RFC 5321: Simple Mail Transfer Protocol — RFC-Editor