Häufige Probleme beim E-Mail-Empfang aufgrund von falsch konfiguriertem DKIM auf den sendenden Mailservern
In den letzten Wochen erhielten wir vermehrt Anrufe von unseren Kunden mit der Problematik, dass externe Personen ihnen keine E-Mails mehr zustellen können. Mit anderen Worten: Unser Anti-Spam-Gateway stuft eingehende E-Mails von bestimmten Domains plötzlich als bösartig ein und weist sie ab.
Untersuchungen haben ergeben, dass es sich in fast allen Fällen um das gleiche Problem handelt: Falsch konfigurierte oder fehlende DKIM-Schlüssel auf dem Mailserver / DNS des Versandpartners.
Was ist DKIM eigentlich?
DKIM steht für Domain Keys Identified Mail und überprüft wie SPF die E-Mail-Domäne der "Mail from:"-Adresse. Allerdings wird nicht die IP-Adresse des sendenden Servers verglichen, sondern die Nachricht und der Mail-Header werden digital signiert. Dazu verwendet das sendende System den privaten Teil eines asymmetrischen Schlüsselpaares. Das öffentliche Gegenstück wird über einen DNS-Eintrag in der E-Mail-Domäne zugänglich gemacht. So kann jede Gegenstelle die Signatur und damit die Herkunft der Nachrichten verifizieren.
Für eine Mail-Domäne können mehrere solcher Schlüssel erzeugt und gespeichert werden. Sie werden durch einen Namensbezeichner, den "Selektor", voneinander unterschieden. Für jeden Selektor wird ein Eintrag auf dem DNS-Server benötigt, der z.B. so aussieht:
Wobei der Selektor hier nun 'nx' ist.
Wie wird ein solcher Schlüssel erstellt?
Die meisten Mailserver können solche Schlüssel erstellen. Sie erstellen den "privaten Schlüssel", den sie für sich behalten, und den "öffentlichen Schlüssel", der, wie im obigen Beispiel, auf dem DNS-Server installiert werden muss.
Wo liegt also das Problem?
Viele Kunden, interessanterweise oft Office-365-Kunden, scheinen einfach die Option "DKIM aktivieren" zu wählen - weil es an sich eine gute Sache ist. Aber dann vergessen sie, den "Öffentlichen Schlüssel" auf dem DNS-Server selbst einzurichten. Die Office365-Cloud-Server können dies nicht automatisch tun, weil die Domain (DNS) der Kunden sehr oft woanders betrieben wird.
Bis vor ein paar Wochen haben viele Anti-Spam-Gateways diesen Lapsus offenbar toleriert und E-Mails trotzdem weitergeleitet. Nun aber lehnt z.B. unser Antispam-Gateway diese E-Mails mit "ERROR - DKIM Invalid Key" ab.
Wie kann man das prüfen?
Wenn der ‘Selektor’-Name bekannt ist (siehe erweiterter E-Mail-Header), kann z.B. auf https://mxtoolbox.com/dkim.aspx überprüft werden ob die DKIM korrekt eingerichtet ist.
Im obigen Beispiel mit ‘nx’ als Selektor und unserer Domain sieht das wie folgt aus und somit ist alles korrekt:
Ein Beispiel eines nicht existierenden Schlüssels z.B. mit 'gibtesnicht' als Selektor sieht wiefolgt aus:
Dieses Beispiel illustriert, was wir bei den Supportfällen in der letzten Zeit gesehen haben.
Wer ist für die Lösung des Problems verantwortlich?
In erster Linie sind die Mailserver-Administratoren des sendenden Benutzers dafür verantwortlich, dass ihr Mailserver und DNS-Server korrekt konfiguriert sind. Diese müssen die korrekten 'Öffentlichen Schlüssel' auf den entsprechenden Domains im DNS hinterlegen und überprüfen, ob diese korrekt funktionieren. Das Problem liegt also nicht bei uns, respektive beim empfangenden Mailserver oder des Benutzers.
Schnelle Lösung von Seiten nextron
Nichtsdestotrotz haben wir jetzt eine (vorübergehende) Konfigurationsanpassung an unserem Gateway vorgenommen, bei der wir DKIM-Schlüsselfehler nicht als HARD ERROR (die E-Mail wird abgelehnt), sondern als SOFT FAIL (die E-Mail wird mit [SPAM] im Betreff ergänzt und trotzdem zugestellt) klassifizieren.
Nachtrag
Weitere Nachforschungen haben Folgendes ergeben: Microsoft erwartet normalerweise nicht die klassischen DKIM-Einträge für öffentliche Schlüssel, die man im eigenen DNS anlegt, sondern möchte sogenannte CNAME-Einträge (Alias), die auf Microsoft-DNS-Server verweisen.
Nur scheinen diese im Moment überhaupt nicht zu funktionieren: Selbst in unserem eigenen Test mit einer Kundendomain haben wir alles nach Anleitung durchgeführt und selbst Tage später sind die notwendigen Einträge auf dem Microsoft DNS-Server nicht sichtbar oder abrufbar. Es scheint, dass auf Seiten von Microsoft etwas Grundsätzliches nicht funktioniert.
Allerdings haben wir keine Aussagen oder Blogs von Microsoft selbst gefunden, die auf das Problem und eine mögliche Lösung hinweisen würden. Wir können also weiterhin nur abwarten.
