E-Mails landen beim Kunden im Spamordner oder werden abgelehnt, aber wieso? DKIM ist doch konfiguriert, SPF ist gesetzt, DMARC läuft. Alles grün im letzten Check, vor sechs Monaten. DKIM sollte schließlich genau dafür sorgen, dass E-Mails kryptografisch signiert werden und weder Absender noch Inhalte manipuliert werden können. Allerdings wurde vor drei Wochen im Zuge einer DNS-Bereinigung ein Selektor entfernt, der „bestimmt nicht mehr genutzt wird“. Tatsächlich hat ihn das CRM-System still und zuverlässig weiterverwendet, und zwar bis zum Tag der Löschung. Jetzt ist DKIM ungültig, SPF bei der Weiterleitung ebenso und DMARC komplett fehlgeschlagen. Dieses Szenario ist kein Einzelfall, sondern die Folge davon, DKIM als einmalige statt als dauerhafte Aufgabe zu behandeln. Was beim Einsatz von DKIM wichtig ist und welche typischen Fehler Sie bei der Einrichtung und Pflege von DKIM vermeiden sollten, erfahren Sie in diesem Blogartikel.
1. Schlüsselerzeugung: Der private Schlüssel gehört ins sendende System
Die sicherste Variante ist immer, dass das sendende System das Schlüsselpaar intern erzeugt und ausschließlich den öffentlichen Schlüssel herausgibt, bis hin zur Veröffentlichung im DNS. So verlässt der private Schlüssel das System zu keinem Zeitpunkt.
Die Alternative ist, den Schlüssel manuell zu generieren und zu importieren. Dies vergrößert die Angriffsfläche allerdings erheblich. Jeder Schritt auf diesem Weg ist ein potenzieller Schwachpunkt: der Rechner, auf dem der Schlüssel generiert wurde, der Übertragungskanal (E-Mail, Ticket, geteiltes Dokument), das Zielsystem beim Import. Ein einmal kompromittierter privater Schlüssel ermöglicht es, E-Mails im Namen der Domäne authentisch zu signieren, und zwar so lange, bis der Schlüssel rotiert wird.
Moderne Mail Transfer Agents (MTAs) und E-Mail-Security-Lösungen unterstützen interne Schlüsselerzeugung in der Regel. Wer diese Wahl hat, sollte sie entsprechend treffen.
Zudem sollte bei dem Versand über mehrere Systeme von derselbem Domäne jedes dieser Systeme seinen eigenen Selektor bekommen. Dadurch lassen sich Signaturen einzelnen Systemen eindeutig zuordnen, etwa in DMARC-Reports oder Logdaten. Einzelne Selektoren können so zudem unabhängig rotiert oder deaktiviert werden, Störungen bleiben auf einzelne Systeme begrenzt, und bei einer Kompromittierung muss nur der betroffene Selektor ersetzt werden.
2. DKIM-Schlüsselrotation: Richtig und vor allem regelmäßig
DKIM-Schlüssel werden in vielen Umgebungen einmal eingerichtet und anschließend über Jahre hinweg unverändert genutzt. Das ist problematisch, da kryptografische Schlüssel regelmäßig rotiert werden sollten, um das Risiko eines langfristigen Missbrauchs kompromittierter Schlüssel zu reduzieren. Wir empfehlen einen Rotationszyklus von sechs bis zwölf Monaten. In sicherheitskritischen Umgebungen oder nach einem Sicherheitsvorfall kann ein kürzerer Zyklus sinnvoll sein.
Die größte Herausforderung bei der Rotation ist DNS-Caching. DNS-Einträge werden von Resolvern und Zwischensystemen entsprechend ihrer Time-to-Live-(TTL-)Angabe zwischengespeichert. Ein bestehender DKIM-Schlüssel kann daher nicht einfach unmittelbar ersetzt werden. Andernfalls könnten E-Mails, die noch mit dem alten Schlüssel signiert wurden, nicht mehr verifiziert werden. Umgekehrt könnten Systeme weiterhin veraltete DNS-Daten verwenden und dadurch Signaturen mit dem neuen Schlüssel nicht korrekt prüfen.
Deshalb erfolgt die Rotation üblicherweise mit zwei parallel verfügbaren Schlüsseln beziehungsweise DKIM-Selektoren. Während der Übergangsphase sind der alte und der neue Schlüssel gleichzeitig im DNS veröffentlicht, bis sichergestellt ist, dass keine Systeme mehr auf gecachte Altinformationen zugreifen.
DKIM-Schlüsselrotation in vier Schritten
Eine saubere DKIM-Schlüsselrotation läuft deshalb überlappend ab:
- Neues Schlüsselpaar und neuen Selektor erzeugen.
- Neuen DNS-Eintrag veröffentlichen und auf dem sendenden System den neuen Selektor einrichten. Beide Selektoren sind dann gleichzeitig aktiv – das ist kein Problem, mehrere DKIM-Signaturen auf einer E-Mail sind explizit erlaubt.
- Prüfen, ob der neue Selektor korrekt verwendet wird und die Signatur valide ist.
- Nachdem die DMARC-Reports bestätigen, dass der neue Schlüssel wie gewünscht funktioniert: entfernen des DNS-Eintrags und der Schlüssel vom E-Mail-System des alten Selektors.
Wer nicht tagelang auf die Rückmeldung durch die DMARC-Reports warten möchte, nutzt am besten Tools wie 25Reports. So ermöglicht 25Reports es, eine Test-E-Mail einzusenden und das Ergebnis direkt einzusehen: welcher Selektor verwendet wurde, ob die Signatur valide ist, welche Fehler aufgetreten sind.
3. Schlüsseltyp und Länge: Ein entscheidender Kompromiss
Für DKIM stehen zwei Verfahren zur Verfügung: Ed25519 und RSA.
Ed25519 ist die kryptografisch modernere Wahl: kleinere Schlüssel, kompaktere Signaturen, stärkere mathematische Eigenschaften. Seit RFC 8463 (2018) ist das Verfahren für DKIM standardisiert. Es gibt aber eine Einschränkung: Die Unterstützung auf Empfängerseite ist nach wie vor uneinheitlich.
Wer auf maximale Kompatibilität angewiesen ist, muss RSA verwenden. Bei RSA gilt eine einfache Faustregel: nicht unter 1024 Bit, nicht über 2048 Bit, aber aus unterschiedlichen Gründen.
1024 Bit gilt nicht mehr als zeitgemäß sicher und sollte für neue Deployments nicht mehr gewählt werden. 2048 Bit ist der praktische Standard, hat aber einen Haken: Die resultierenden DNS-Einträge können das UDP-Limit von 512 Byte überschreiten. Resolver weichen dann auf TCP aus, was grundsätzlich funktioniert. Einige Systeme verarbeiten solche langen TXT-Einträge aber fehlerhaft. 4096 Bit klingt sicherer, ist es in der Praxis auch marginal, erzeugt aber signifikant mehr Kompatibilitätsprobleme.
Das Fazit ist leider: Es gibt keinen universell optimalen Schlüssel. RSA 2048 Bit ist der pragmatische Standard; Ed25519 ist die bessere Wahl in Szenarien, in denen die eigene Infrastruktur und die der relevanten Empfänger es zuverlässig unterstützen.
4. DKIM-Selektoren: Immer den Überblick behalten
Eines der größten Praxisprobleme bei der DKIM-Rotation ist der fehlende Überblick darüber, welche Selektoren tatsächlich noch verwendet werden.
In gewachsenen E-Mail-Umgebungen ist die Annahme „dieser Selektor wird nicht mehr genutzt“ häufig falsch. Alte Konfigurationen, Subsysteme oder externe Versanddienste können einen Selektor noch lange nach einer Migration weiterverwenden. Wird der zugehörige DNS-Eintrag entfernt, schlagen DKIM-Prüfungen für genau diese Nachrichten fehl.
Das ist besonders kritisch, weil DKIM in vielen Szenarien der einzige verbleibende Mechanismus für eine erfolgreiche DMARC-Prüfung ist. SPF scheitert beispielsweise häufig bei Weiterleitungen oder bei Drittanbietern wie Newsletter- und CRM-Systemen, wenn kein sauberes Alignment vorliegt.
Deshalb sollte vor dem Entfernen eines Selektors geprüft werden, ob dieser tatsächlich nicht mehr verwendet wird. Dabei helfen insbesondere DMARC Reports. Sie zeigen, welche DKIM-Selektoren im realen E-Mail-Flow tatsächlich auftauchen und ob die zugehörigen Signaturen erfolgreich validiert werden konnten.
Zusätzlich können Monitoring-Tools wie 25Reports bei der Analyse der Selektor-Nutzung helfen. Gefundene Selektoren und deren letztes Auftauchen werden gesammelt in einer Liste angezeigt, und es können Alarme konfiguriert werden, die auf das Auftauchen von neuen oder Änderungen an bestehenden Selektoren hinweisen. Bei häufigem Spoofing und dadurch immer wieder vermeintlich neu auftauchenden Selektoren können die entsprechenden Alarme angepasst werden, um die Frequenz der Alarmierungen zu steuern. Letzteres ist sinnvoll, da insbesondere bei starkem Spoofing-Aufkommen auch Fehlalarme auftreten können.
5. Alignment: die häufig unterschätzte Fehlerquelle
DMARC verlangt nicht nur, dass DKIM valide ist. Es verlangt, dass DKIM aligned ist: Die Domäne in der DKIM-Signatur (das ‚d=‘-Feld im ‚DKIM-Signature‘-Header) muss mit der ‚From:‘- Domäne der E-Mail übereinstimmen oder eine autorisierte Subdomäne davon sein.
DMARC unterscheidet dabei zwei Modi:
Relaxed Alignment (Standard)
Subdomänen sind erlaubt. ‚d=mail.beispiel.de‘ ist aligned zu ‚From: @beispiel.de‘.
Strict Alignment
Nur exakte Übereinstimmung. ‚d=mail.beispiel.de‘ wäre in diesem Modus nicht aligned zu ‚@beispiel.de‘.
Die meisten Umgebungen nutzen Relaxed, weil dedizierte Versand- Subdomänen damit problemlos funktionieren. Das eigentliche Problem entsteht aber meistens nicht bei Subdomänen, sondern bei völlig verschiedenen Domänen. Das klassische Szenario: Ein Drittsystem – CRM, Marketing-Plattform, Ticketsystem – signiert ausgehende E-Mails mit DKIM, aber mit seiner eigenen Domäne. Der ‚From:‘-Header zeigt ‚absender@kundenbeispiel.de‘, die Signatur hat ‚d=crm-plattform.com‘. Die Signatur ist valide. Alignment schlägt trotzdem fehl, und deshalb auch DMARC.
Solange p nicht auf „reject“ steht, werden solche E-Mails nur still schlechter bewertet – und in einigen Fällen unter Umständen auch als Spam eingestuft. Sobald die Umstellung auf „p=reject“ erfolgt ist, können diese E-Mails DMARC nicht bestehen, falls SPF dies nicht doch noch verhindert.
DMARC-Reports zeigen für jede Nachricht getrennt das DKIM-Validierungsergebnis und das Alignment-Ergebnis. Eine Kombination aus ‚dkim=pass‘ und ‚dkim_alignment=fail‘ ist kein Widerspruch, sondern exakt das beschriebene Problem. Wer DMARC-Reports auswertet, findet solche Konfigurationsfehler, bevor sie größeren Schaden anrichten. Auch hier ist ein entsprechendes Monitoring sinnvoll, um frühzeitig über auftretende Probleme informiert zu sein.
Fazit
DKIM, SPF und DMARC sind kein Baukastensystem, bei dem jede Komponente unabhängig bewertet werden kann. Sie bilden ein Gesamtsystem; ein Defekt an einer Stelle kann die anderen Mechanismen wirkungslos machen.
DKIM bedeutet andauernden Betrieb – mit allen Implikationen: regelmäßige Rotation, aktives Monitoring, explizite Validierung nach Änderungen. DMARC-Reports liefern ein genaues Bild davon, was im realen E-Mail-Flow passiert. Wer sie auswertet, erfährt mehr über die eigene E-Mail-Infrastruktur als jede statische Konfigurationsprüfung leisten kann.
Wer den fünf in diesem Blogartikel genannten Prinzipien folgt und ein entsprechendes DMARC-Monitoring nutzt, kann mit wenig Aufwand für sicheren und funktionierenden E-Mail-Verkehr sorgen. So verbessern sich auch die Zustellraten und die Fähigkeit, auf Sicherheitsvorfälle schnell und gezielt zu reagieren.
Damit Ihr E-Mail-Verkehr sicher und reibungslos funktioniert: Mit unserem Praxisleitfaden und 25Reports sind Sie optimal aufgestellt.
Laden Sie sich jetzt unseren kostenfreien Praxisleitfaden mit Schritt-für-Schritt-Anleitungen zum Thema “SPF, DKIM und DMARC” herunter. Mit unserem DMARC Monitoring Tool NoSpamProxy 25Reports wird DMARC endlich einfach. Der Service übernimmt das komplette DMARC Monitoring für Sie – automatisiert, grafisch aufbereitet und DSGVO-konform. Jetzt 30 Tage kostenfrei testen!
