Mal wieder aus gegebenem Anlass: Ich bekam ein E-Mail mit u.a. folgenden Header-Zeilen:
Return-Path: <www-data@dekra.de>
Received: from mein.email.server
by mein.email.server with LMTP
id UBgqHTxRdmiuTAEAnigj0g
(envelope-from <www-data@dekra.de>); Tue, 15 Jul 2025 15:01:48 +0200
Envelope-to: meine@email.adresse
Delivery-date: Tue, 15 Jul 2025 15:01:48 +0200
Authentication-Results: mein.email.server;
iprev=fail smtp.remote-ip=107.150.20.200;
spf=fail smtp.mailfrom=dekra.de;
dmarc=skipped
Received: from [107.150.20.200] (helo=hosthatch.com)
by mein.email.server with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384
(Exim 4.96.2)
(envelope-from <www-data@dekra.de>)
id 1ubfI4-000Oct-0Q
for meine@email.adresse;
Tue, 15 Jul 2025 15:01:48 +0200
Received: by hosthatch.com (Postfix, from userid 33)
id 4CF1E40C7A; Tue, 15 Jul 2025 13:01:39 +0000 (UTC)
Date: Tue, 15 Jul 2025 13:01:21 +0000
To: meine@email.adresse
From: noreply@elster.de
Subject: =?UTF-8?Q?Einkommensteuer-R=C3=BCckzahlung:_Kontoinformationen_best?=
=?UTF-8?Q?=C3=A4tigen?=
[...]
Wieso wird so ein E-Mail übermittelt? Wer kann bzw. muss seinen Server wie konfigurieren, damit die offensichtlich auf Betrug hindeutenden Authentication-Results beachtet werden, um so ein E-Mail schon bei erstbester Gelegenheit aus dem Verkehr zu ziehen?
Das muss der Betreiber des Mailservers, der die Mail empfangen hat, konfigurieren.
SPF Fail = 1 Indiz, es gibt daneben noch dkim records. Diese scheint auch im header zu fehlen.
Dann noch dmarc und sowas wie abuse.ch als Blocking.
Theoretisch kann jeder von irgendwo einfach ne domain hinknüppeln und ne Mail im Namen anderer versenden. Die Protokolle, wie oben erwähnt, dienen zu Sicherstellung der Echtheit des Absenders. Das Mail Protokoll ist alt, darum kamen so Dinge irgendwann hinzu.
Man kann den Mailserver so konfigurieren, dass bei fehlendem oder falschen SPF geblockt wird. Da dies wie auch DKIM gemäß Specs keine Pflicht ist, wird man dann auch gelegentlich legitime Zusendungen ablehenen.
Besser ist es, für E-Mail mit diesen „Mängeln“ den SPAM-Score entsprechend hochzusetzen.
Wem gehört denn der Server mein.email.server? Ist das dein eigener Server? Abgesehen davon, dass der sendende Mailserver von hosthatch.com die E-Mail versendet hat, hat der empfangende Mailserver mein.email.server die E-Mail trotz mehrerer Warnsignale angenommen. Der sendende Server verschickt die E-Mail einfach. Er führt keine SPF- oder RDNS-Checks auf seine eigene Verbindung durch.
naja, der scheinbare Sender ist auch mitverantwortlich. dekra.de hat zwar einen SPF-Record aber keinen DMARC-Record, der den Empfänger instruieren könnte, was mit Fälschungen passieren soll.
Falls Du Kunde bei dekra bist, kannst Du denen ja mal das Problem schildern und meine Artikel auf https://blog.lindenberg.one/TopicEmailSicherheit empfehlen.
Den eigenen Server kann man je nach Spamfilter konfigurieren, dass korrektes SPF oder DKIM oder etwas schärfer DKIM erwartet wird, das senkt die Spamrate aber oft nur geringfügig, denn auch Fälscher können DKIM. Erst mit DMARC wird erwartet, dass envelope-from und header-from übereinstimmen.
Im hier geschilderten Fall ist das nicht der Fall.
Der spf-Eintrag von dekra.de enhält als Policy -all (alle Mails ablehnen, die nicht über die gelisteten IP-Adresse versandt werden).
Eine zusätzliche dmarc-Policy ist, in diesem Fall, überflüssig, da kein DKIM verwendet wird und die SPF-Policy bereits alle, für den Empfänger relevanten, Angaben enthält.
spf und dmarc sind außerdem nur deklarativ.
Die Entscheidung, wie mit eingehenden E-Mails verfahren wird, liegt ausschließlich beim empfangenden Mailserver.
Nach meiner Einschätzung gibt es keine allgemeingültige Antwort auf diese Frage.
Es hängt wie so oft vom individuellen Sachverhalt ab.
Die Angaben bzgl. SPF, DKIM, DMARC, usw. müssen von den Administratoren der Domain umgesetzt werden. Dies können andere Stellen / Personen sein als diejenigen, die für Webseiten und Shops zuständig sind. Auch bei seriösen Akteuren können die in diesem Fall notwendigen Absprachen zwischen den Teams warum auch immer unterbleiben.
D.h. Mailteam setzt Restriktionen, Webteam lässt Webserver und Anwendungen munter E-Mail von Webservern versenden, von deren Anmietung das Mailteam nichts weiss.
Wenn nun der Empfänger entscheidet, derartige E-Mail-Zusendungen abzulehnen, kann es zu unerwünschter Ablehnung legitimer E-Mail führen. Entsprechend ist es aus Empfängersicht günstiger, die Nachricht anzunehmen und mit hohem Score zu taggen.
Mit Deutschland hat das nach meiner Einschätzung nicht viel zu tun. Man kann das weltweit beobachten. In welchem Kontinent / Land spielt das denn eine größere Rolle bzw. wo wird denn etwas anderes durchgesetzt?
Mir ging es auch nicht darum, irgendetwas zu beurteilen.
Was aber hoffentlich klar zu verstehen ist:
Es kommt letztlich nur auf eigene Bedürfnisse, Erwartungen von Dritten aufgrund von Vetragsgestaltungen und jeweils gesetzliche Anforderungen an.
Was soil es einen Händler oder eine Anbieter von Dienstleistungen für diese interessieren, was sich Akteure von Firmen und Aktivisten ausserhalb deren Kosmos wünschen?
Dahingegen kann ein Admin eines ausschließlich für eigene / private Zwecke betriebenen Mailservers ganz anders verfahren und alles direkt blocken.
ich hab das geschrieben, weil mir aus anderen Ländern keine Einschätzung vorliegt oder nur Bruchstücke, wie DNSSEC ist in den USA bei der Verwaltung deutlich verbreiteter als in Deutschland und in den Niederlanden und Schweden auch. Über DMARC, SPF oder DKIM weiß ich das nicht.
Eigentlich verlangt die DSGVO den Stand-der-Technik, und da würde ich nicht nur SPF, DKIM und DMARC sondern auch SMTP-DANE und MTA-STS drunter verstehen, und auch das BSI schreibt das im Grundschutz-Kompendium. Aber wir haben halt 0 Durchsetzung davon, und bei Behörden noch weniger als bei anderen Organisationen.
Auch ich blocke nicht alles, zu aufwendig die Konfiguration von Mailcow zu tunen. Aber immerhin verwende ich quarantine und reject nur deswegen nicht, weil damit einige Mailinglisten nicht klarkommen.
Solche Mails (from elster.de, envelope-from dekra.de) habe ich bei uns in der Nachrichtenverfolgung die Tage auch gesehen - allerdings sind diese bei uns gar nicht erst angenommen worden. Scheint jedenfalls in gewissem Umfang versendet worden zu sein.
Dass die Dekra keinen DMARC-Record hat, ist unschön - mit diesen wäre die Mail vermutlich abgelehnt worden. Es steht aber auch jedem empfangenden Mailserver frei, Mails alleine aufgrund des SPF-fail bereits abzulehnen.
Hast du deinen Mailprovider mal gefragt, warum die das annehmen?
Ich setze dabei auch voraus, dass die DEKRA die üblichen DNS-einträge ordentlich und vollständig eingetragen hat. Weil das macht man ja aus Eigeninteresse → Reputation schützen.
Von außen betrachtet sehe ich das Problem bei deinem Mailprovider.
Naja, genau das hat sie ja nicht. Mit entsprechendem DMARC-Record wäre die Mail von den meisten Mailservern vermutlich abgelehnt worden. Ob SPF-Fail alleine reicht, um Mails vollständig abzulehnen, kann man sich wohl streiten. Aber ja, der empfangende Mailserver hätte auf dieser Basis die Mail ablehnen können.