MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

DMARC-Fail vrbank.de

Wenn sie Inhaber einer Domain sind und einen DMARC-Eintrag veröffentlichen, dann sollten Sie es richtig machen und nicht wie die vrbank.de am 5 Mail 2026

Ich hoffe, dass der Inhaber von vrbank.de seine Konfiguration noch korrigiert aber dch Seite soll zeigen, dass es nicht immer die kleinen Firmen mit weniger spezialisierten Dienstleistern oder IT-Abteilungen sind, die eine fehlerhafte Konfiguration bereitstellen.

Diese Seite beschreibt eine reale Konfiguration am 17.5.2026. Sie soll nicht als Pranger missverstanden werden sondern eher als deutlichen Weckruf

Phishing Mail mit vrbank.de

Am 5 Mail hat sich mal wieder eine Phishing-Mail in mein Postfach verirrt. Normalerweise landet sowas automatisch im Spam-Ordner oder wird gelöscht aber die Absenderdomain "vrbank.de" hat mich irritiert. Warum wurde so eine Mail nicht direkt abgelehnt?

Ich bin nun kein Kunde einer Volksbank und wer sich den Link hinter "Zugang jetzt erneuern" anschaut, dann verweist er auf eine andere Webseite und sollte schon so nicht angeklickt werden.

Header Analyse

Ein Blick in den Header hat schnell ergeben, dass hier wirklich "vrbank.de" verwendet wurde und nicht irgendwelche kyrillische oder ähnliche Zeichen.

Hinter "vrbank.de" verbirgt sich auch wirklich eine Volksbank. Hier ist es die "VR Bank Rhein-Neckar eG".

Soweit ich dem MTA von IONOS glaube, wurde die Mail also von 70.32.96.105 eingeliefert

SPF-Pass oder Fail?

Daher habe ich mir zuerst den SPF-Record angeschaut.

nslookup -q=TXT vrbank.de

Die beiden "includes" der Fiducia enthalten folgende IP-Netzwerke:

ip4:194.149.246.0/23 ip4:195.200.34.0/24 ip4:195.200.46.0/26 ip4:195.35.89.0/26 
ip4:195.200.32.16/28 ip4:83.136.79.186/31 ip4:62.116.129.216 ip4:20.79.64.145 
ip4:9.141.130.76 ip4:131.189.171.177 
ip4:195.200.34.57 ip4:195.200.34.58 ip4:195.200.46.5 ip4:195.200.46.6 
ip4:195.200.46.7 ip4:195.200.46.8 ip4:195.200.44.24/29
include:spf.protection.outlook.com -all"

Interessant finde ich hier, dass z.B. die IP-Adressen 195.200.34.57 und 195.200.34.58 explizit noch einmal aufgeführt sind, obwohl sie im Subnetz 195.200.34.0/24 eigentlich enthalten sind. Gleiches gilt für ip4:195.200.46.5 ip4:195.200.46.6 und das Subnetz ip4:195.200.46.0/26

Allerdings ist hier die "70.32.96.105" definitiv nicht enthalten und das "-all" sollte solche Mails direkt ablehnen können. Leider protokolliert IONOS im Header nicht das SPF-Ergebnis.

Ein SPF-Check hätte hier aber auf jeden Fall einen SPF = FAIL geliefert.

DKIM - natürlich nicht

Der Absender hat sich natürlich nicht die Mühe gemacht, eine DKIM-Signatur zu addieren. Das könnte er aber auch nicht, da er hoffentlich nicht einen privaten Schlüssel zu einem DKIM-Selector hat. Daher verwundert es natürlich nicht, dass diese Mail keine DKIM-Signatur hat.

DMARC Fail

Wer sich nun mit Spamfilterung und Domain Reputation auskennt, kann die wahre Ursache schon nennen. Es ist wieder mal ein falsche Verständnis von DMARC. Der entsprechende Eintrag sieht am 17. Mai 2026 wie folgt aus:

Das "p=none" hebelt direkt das "SPF -all" aus, wenn der Empfänger nur nur einen einfachen SPF-Check macht, sondern DMARC unterstützt und sich daran hält, dann wird die Mail eben nicht als Fälschung eingestuft. Was mich noch irritiert, dass es keinen RUF/RUA-Eintrag gibt. Die vrbank.de will also gar keine Berichte einsammeln, wer in ihrem guten Namen Mails versendet. Das ist doch die erste Einstellung, wenn man unsicher über alle Versendet ist und irgendwann ein "P=Quarantine"

Daher ist "DMARC p=none" aus meiner Sicht eine Fehlkonfiguration, die den Schutz sogar verringert und ich ohne aktivierte Report-Funktion sogar als Planlos bezeichnen würde. Ein "None" für wenige Wochen mit aktiviertem Reporting kann man als Restrisiko noch durchgehen lassen. Aber so?

Und der Spammer?

Von dem Angreifer wissen wir eigentlich nur, dass er von der IP-Adresse "70.32.96.105" und vermutlich mit einem Postfix eine Mail mit der Domain "cynergynetworks.org" gesendet hat. Ein Blick auf die IP-Adresse per HTTP liefert eine rudimentäre Plesk-Seite.

Ein Zugriff über den Namen samt HostHeader dann eine Apache Testing Seite

nicht konfigurierten Apache Server. Die IP-Adresse gehört zu einem Godaddy-Netzwerk

70.32.96.0/24 IP Range
https://ipinfo.io/ips/70.32.96.0/24  

https://www.abuseipdb.com/whois/70.32.96.105
Data Center/Web Hosting/Transit

Mit einer Antwortzeit von ca 150ms auf einen PING dürfte der Server auch nicht  in Europa stehen. USA scheint plausibel

Auf Port 25 lieft ein Postfix, der zumindest auf den ersten Blick zumindest kein offenes Relay ist.

Dann hätten wir aber auch weitere "Received:"-Header gefunden. Es sieht also alles so aus, als ob dort ein Angreifer einen virtuellen Server gemietet und seine Payload versendet hat. Ob Godaddy hier den "Inhaber" ermitteln kann, ist zu bezweifeln. Dazu gibt es viele geklaute Kreditkarten. Das ist aber das Problem von GoDaddy.

Einschätzung

Die Domain "vrbank.de" ist natürlich aufgrund ihres Namens schon etwas besonders und ich bin doch irritiert, dass die Inhaber so nachlässig bei der Absicherung ihrer Domain sind. Gerade als Bank sollte man alle Möglichkeiten nutzen und die eigene Domain gegen Missbrauch abzusichern. Hätte die vrbank.de nur einen SPF-Eintrag und im Gegenzug auf dem DMARC-Eintrag verzichtet, wären so einfach Fälschungen schon blockiert worden. Leider weiß ich nicht, ob "vrbank.de" seine Mails auch per DKIM signiert aber das würde mit der DMARC-Policy auch nichts helfen.

Solche Falschkonfigurationen fordern es geradezu heraus, diese Domain zu missbrauchen und Spamfilter könnten auf den Gedanken kommen, ein "DMARC p=none" direkt zu ignorieren oder solche Domains abzustrafen. Selbst das BSI hat entsprechende Empfehlungen herausgegeben.

Gerade eine Bank sollte sich an den "anerkannten Stand der Technik" orientieren. Vor kurzem wurde wohl mal eine Volksbank zum Schadenersatz verurteilt, weil der Phishing-Anruf sehr gut gemacht wurde und die Bank nicht genug zum Schutz getan hat. Ist das eigentlich schon eine Meldung an die BaFin oder BSI wert, denn ein "DMARC p =none" ist für mich schon fast Vorsatz, diese Domain für Phishing zu missbrauchen. So leicht sollte es eine Bank-IT nicht machen.

Ich habe leider keine Liste aller Banken. Aber vielleicht sollte der IT-Dienstleister Fiducia seine "Kunden" auf  solche Unstimmigkeiten hinweisen. Der MX-Record für vrbank.de geht nämlich auf deren Server und die Fiducia-Server sind im SPF-Record hinterlegt.

Weitere Links