Empfänger sagt, dass DKIM-Signatur ungültig ist, bei nur einem Absender und einem Empfänger

    Hallo zusammen,

    ich kann mir ein Problem gerade logisch nicht erklären.

    Gegeben ist ein David-System, das ausschließlich über den Provider (Strato) arbeitet. Empfang via Catchall, Senden per Smarthost. Klappt alles prima, und bei Strato sind die üblichen Einstellungen auf Default gelassen worden. Sende ich eine Mail als beliebiger User an z. B. einen Dienst wie mail-tester[punkt]com, dann erhalte ich eine tolle Reputation, insbesondere SPF, DKIM und DMARC werden als gültig und sauber angezeigt. Beim Versand über smtp.strato.de setzt der Provider diese Einträge ja automatisch.

    Es gibt aber eine Applikation, die wir mit dem David-Postman nicht zum Laufen bekommen haben, konkret wurden PDF-Anhänge "verwurstet". Kurzerhand haben wir für diese Applikation also bei Strato ein separates Postfach eingerichtet und die passenden Einträge gemacht. Das Programm sendet nun "an David vorbei" direkt über smtp.strato.de.

    Problem: Der Empfänger beklagt sich (nur bei diesem Absender) über eine fehlerhafte DKIM-Signatur und lehnt die Mail ab.

    Hä? DKIM und Co. sind doch via DNS für die gesamte Domain gültig - wie kann es dann sein, dass alle David-Mails problemlos ihre Empfänger erreichen, diese Mails aber nicht? Das Programm ist leider alt und lässt keine Diagnose zu (z. B. Test-Mails an beliebige Empfänger), es ist aber alles sauber/aktuell konfiguriert, also smtp.strato.de als Ausgangsserver, SSL, Port 465.

    Ich merke gerade, das Thema hat mit David nur bedingt zu tun, da es sich ja speziell um das eine Postfach handelt, das nicht mit David bearbeitet wird. ;) Vielleicht hat trotzdem jemand eine Idee? Ich versteh's nicht wirklich.

    Ich füge unten mal das an, was der Kunde als Bounce-Nachricht zurück bekommt - und hoffe, alles korrekt anonymisiert zu haben.

    zieladresse@empfaenger.invalid ist der Empfänger
    quelladresse@versender.invalig der Sender.

    Auffällig ist natürlich z. B. dieses hier: "Received-SPF: Fail (protection.outlook.com: domain of versender.invalid does
    not designate 195.185.212.45 as permitted sender)" - damit hat das System im Prinzip ja Recht, ich weiß allerdings spontan nicht, wo diese IP herkommt. Es scheint sich nicht um einen Strato-Server zu handeln.

    Ist es denkbar, dass das erwähnte Programm trotz der korrekten Hinterlegung des Strato-SMTPs noch über eigene Server verschickt? Das wäre ja ein ziemlicher Klops.

    Also ich habe mal kurz mit meinem Kollegen (KI) gesprochen der sagt:

    Der entscheidende Fehler ist hier:

    Zitat

    550 5.7.509 Access denied, sending domain versender.invalid does not pass DMARC verification and has a DMARC policy of reject.

    Das bedeutet:

    • Die Empfängerseite (Microsoft 365 / Outlook) hat die Mail wegen fehlgeschlagener DMARC-Prüfung abgelehnt.
    • Obwohl die Mail ursprünglich bei Strato offenbar korrekt signiert war, ist die Authentifizierung unterwegs kaputtgegangen.

    Die relevanten Zeilen sind:

    • ursprünglich bei Strato:
      • spf=pass
      • dkim=pass
      • dmarc=pass

    aber später bei Microsoft:

    • spf=fail
    • dkim=fail (body hash did not verify)
    • dmarc=fail
    • compauth=fail

    Das zeigt ziemlich klar:
    Die Mail wurde nach dem DKIM-Signieren verändert oder über einen Server geleitet, der die Authentifizierung beschädigt hat.

    Wichtig ist diese Kette:

    Code
    smtp.strato.de
→ mo4-p00-ob.smtp.rzone.de
→ mail.ispmail.de
→ Microsoft 365

    Der problematische Hop ist sehr wahrscheinlich:

    Code
    mail.ispmail.de (195.185.212.45)

    Denn dort schlägt plötzlich SPF fehl und DKIM wird ungültig.

    Mögliche Ursachen

    1. Mailserver verändert den Body (sehr wahrscheinlich)

    DKIM meldet:

    Code
    dkim=fail (body hash did not verify)

    Das passiert typischerweise wenn:

    • Disclaimer angehängt werden
    • MIME-Struktur verändert wird
    • Attachments umcodiert werden
    • Zeilenumbrüche geändert werden
    • Antivirus/Spamfilter Inhalte modifizieren

    Rspamd/Postfix-Gateways sind dafür bekannte Kandidaten.

    2. Falscher SMTP-Relay

    SPF sagt:

    Code
    domain of versender.invalid does not designate 195.185.212.45 as permitted sender

    Das heißt:

    • Der empfangende Server sieht mail.ispmail.de als tatsächlichen Sender.
    • Diese IP steht aber offenbar nicht im SPF der Domain.

    Wenn mail.ispmail.de ein eigenes Relay/Gateway ist, muss dessen IP entweder:

    • im SPF stehen
      oder
    • die Mail unverändert weiterleiten und DKIM intakt lassen.

    Momentan passiert beides nicht.

    3. ARC-Kette ungültig

    Zusätzlich:

    Code
    arc=fail (47)

    ARC sollte eigentlich Authentifizierungsergebnisse „retten“ bei Weiterleitungen. Funktioniert hier aber ebenfalls nicht.

    Wahrscheinlich ist die ARC-Implementierung auf dem Zwischenserver fehlerhaft oder unvollständig.

    Was du prüfen solltest

    Wenn mail.ispmail.de dein eigener Server ist

    Dann:

    A) Keine Mailmodifikation nach DKIM

    Prüfen:

    • Disclaimer deaktivieren
    • MIME-Rewriting deaktivieren
    • Antivirus/Spamfilter testen
    • Rspamd-Milter prüfen

    Insbesondere:

    • mime modification
    • add footer
    • force reencode

    B) SPF erweitern

    Die IP:

    Code
    195.185.212.45

    muss ggf. in den SPF der Domain aufgenommen werden.

    Beispiel:

    Code
    v=spf1 ip4:195.185.212.45 include:_spf.strato.com -all

    (abhängig vom tatsächlichen Setup)

    C) DKIM nach dem letzten verändernden Hop signieren

    Falls mail.ispmail.de Inhalte verändert, muss:

    • dort neu DKIM-signiert werden
    • mit d=versender.invalid

    Wenn das nur ein Weiterleitungsserver ist

    Dann solltest du:

    • SRS (Sender Rewriting Scheme) aktivieren
    • ARC korrekt konfigurieren
    • möglichst keine Inhaltsänderungen durchführen

    Warum es früher evtl. funktioniert hat

    Microsoft 365 ist seit 2024/2025 deutlich strenger geworden bei:

    • DMARC reject
    • SPF alignment
    • ARC validation
    • CompAuth

    Besonders bei:

    • Weiterleitungen
    • Mailinglisten
    • Relayservern
    • selbst betriebenen Gateways

    Kurzdiagnose

    Die Mail war beim Versand korrekt authentifiziert, wurde aber auf mail.ispmail.de so verändert oder weitergeleitet, dass:

    • DKIM ungültig wurde
    • SPF nicht mehr passte
    • dadurch DMARC scheiterte
    • Microsoft die Mail wegen p=reject endgültig abgelehnt hat

    Der wahrscheinlichste Fix:

    • keine Veränderung der Mail auf mail.ispmail.de
      oder
    • dort korrekt neu DKIM-signieren + SPF sauber konfigurieren.

    Das erste "Receive", von unten aus gesehen, sollte die Übergabe der Mail an den Strato SMTP sein:

    Zitat von nordtech

    Received: from 2018-03-13 by smtp.strato.de (RZmta 55.0.1 AUTH)

    Den weiteren Weg bis zu dem angeblich ungebührlichen SMTP kannst du mit jedem "Receive" weiter nach oben verfolgen. Das müsste man dann mal mit einer Mail vergleichen die über David verschickt wird.
    Hast du für David selbst auch ein DKIM aktiviert? DMARC und SPF DNS Eintrag überprüft?

    2018-03-13 ist der Client-PC, der die Mail auf den Weg bringt. Der "spricht" direkt mit dem Strato-SMTP. Die 195.185.212.45 scheint ja zu einem Laden zu gehören, der z. B. Cloud-Telefonanlagen betreut. Ich weiß nach wie vor nicht, was der da für Aktien drin hat bzw. wo der herkommt.

    Was mir gerade einfällt: Kann das eine Firewall sein? Die stammt beim Kunden von einem Drittanbieter, wird nich durch uns betreut. Wäre ja möglich, dass die Firewall den David-Server ausgehend in Ruhe lässt, aber bei einem normalen Client, der plötzlich direkt Mails versenden will, "reingrätscht"?

    Zitat von Wizzard

    Hast du für David selbst auch ein DKIM aktiviert? DMARC und SPF DNS Eintrag überprüft?

    Für David direkt ist kein DKIM etc. eingerichet. Muss ja aber (wenn ich das richtig sehe) nicht, da wir ausschließlich per Smarthost senden. Die Mails aus dem David erhalten z. B. bei mail-tester[punkt]com eine Reputation 10/10: DKIM und SPF einwandfrei, alles mit Standard-Werten von Strato.

    OK, Firewall kann ich ausschließen, in der Regel des David-Servers ist auch der fragliche PC enthalten.

    Die 195.185.212.45 ist schlicht die MX-Adresse des Empfängers, da scheint also ein Archivsystem, Malware-Filter o. ä. vorgeschaltet zu sein. Wie Ritana s KI korrekt rausgefummelt hat, ist die DKIM-Signatur beim Verlassen des Strato-Servers offenbar intakt, bei Ankunft auf dem Empfängersystem aber nicht mehr. Vermutlich wird da also etwas verwurstet. Wodurch sich auch erklärt, dass Testmails an andere Empfänger als einwandfrei eingestuft wurden.

    Was mich nun noch verwirrt, ist, dass der Kunde angibt: Beim Versand via David soll alles klappen, auch zu diesem spezifischen Empfänger. Das kann ich leider nicht testen - eine Mail vom Versender an ein anderes Exchange-System (ohne vorgeschalteten Spezial-MX) sieht gut aus. Aber der Logik nach müsste es ja beim "Problem-Empfänger" auch via David zu Schwierigkeiten kommen, da beide über den gleichen SMTP der gleichen Domain versenden. Zwar über ein anderes Postfach, aber das "merkt" der Empfänger doch gar nicht. :-/

    Alles etwas seltsam. Ich mach jetzt erstmal Pause und schlage dem Kunden ggf. vor, es mit einer Test-Absenderdomain z. B. bei Hetzner zu versuchen. Tritt das Phänomen dort identisch auf, wissen wir zumindest, dass das Strato-Hosting nicht ursächlich ist. Derweil behelfen wir uns mit einer DMARC-Policy "p=none" in der Hoffnung, dass die Mails dann trotz DKIM-Salat durchrutschen.

    Danke euch allen für die gedankliche Unterstützung! :)

    also
    195.185.212.45 gehört nicht zu Strato, ebenso wie die Domain mail.ispmail.de
    Beides gehört zu NetLeaders GmbH & Co. KG
    Was eine Bude ist die unter anderem auch Mailserverdienste für Kunden betreibt.

    Kurzum, ich gehe davon aus das der Fehler im Verantwortungsbereich des Empfängers auftritt.

    Da wird wohl wer seine bisherige Mailserver Lösung auf Microsoft Exchange Online umgestellt haben und das ganze nicht per MX, sondern per aktiver Weiterleitung realisiert haben.

    Nicht übel, das ist exakt die Antwort, die ich inzwischen vom Betreiber des MX-Servers erhalten habe (an der Stelle großes Lob an NetLeaders - das ging sehr schnell und präzise, ganz klassisch per E-Mail. Ist ja inzwischen leider selten geworden). :) In der Tat hat der Empfänger auf diesem Postfach (und nur diesem, das erklärt, warum andere Mails an irgendwas@empfaenger.invalid durchgehen) eine Weiterleitung eigerichtet. Und der Server von Netleaders bringt die Original-Mail mit dem Original-Absender auf den Weg, nur passen dann natürlich SPF und DKIM nicht mehr.

    Eigentlich ganz einfach. Wenn man denn drauf kommt.

    Im Sinne dieses Forums bleibt demnach festzuhalten: Der Absender ist nicht Schuld, Strato ist nicht Schuld, David aber definitiv auch nicht. ;) Bzw. macht David wie angenommen beim Versand via Provider-SMTP das Gleiche wie normale Mailprogramme. Es lag alles nur an der speziellen Konstellation.

    Nochmal danke in die Runde, wir werden das nun dem Empfänger so mitteilen und hoffen, dass das DMARC p=none bis dahin zumindest die Zustellung erlaubt.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden