MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

DMARC-Fail vrbank.de  p=none

Am 5. Mai hat mich eine Phishing-Mails der Domain "vrbank.de" erreicht. Ich bin kein Kunde einer Volksbank aber mich hat gewundert, dass der IONOS-Spamschutz diese Mail nicht direkt abgelehnt hat und daher habe ich mir die SPF/DKIM/DMARC-Details zur Mails und der verwendeten Domain einmal angeschaut.

Kurzfassung

Wer nicht die ganze Seite lesen will, dem macht vielleicht die Kurzfassung neugierig:

  • Ich behaupte: Die vrbank.de macht es Spammern einfach, ihre Domain zu missbrauchen
    Es gibt eine DMARC-Policy, die aber mit "p=none" nur im Monitoring-Mode konfiguriert ist. Das ist für eine Übergangszeit ok, um Reports zu sammeln und dann auf "p=quarantäne" oder "p=reject" zu stellen. Dazu müsste man die Reports auch anfordern und verarbeiten. Bei vrbank.de gab es am 17. Mai aber keinen "RUA"-Eintrag.
  • IONOS scheint keinen SPF-Check zu machen?
    Zumindest scheint es so, wenn man den "Authentication-Results"-Header anschaut. Ohne aktive DMARC-Alignment erleichtert das natürlich den Versand von gefälschten Mails. Das sollte eine Bank heute so nicht mehr zulassen.

Auf Basis der ersten Version dieser Seite, wurde ich per Mail vom E-Mail-Management von Atruvia auf Unstimmigkeiten und falschen Annahmen hingewiesen, und habe die Seite entsprechend korrigiert. Vielen Dank für die ausführlichen Hinweise ich gehe weiter unten darauf noch detaillierter ein.

Der wichtige Grund, dass viele Banken einen DMARC-Eintrag angelegt haben, sind die Vorgaben von Google, outlook.com, Yahoo etc. nur nach eine begrenzte Anzahl von Mails pro Zeiteinheit zuzulassen, wenn die Absenderdomain nicht einen Mindeststandard hinsichtlich SPF/DKIM/DMARC bereitstellt. Ohne DMARC-Eintrag können Sie maximal 5000 Mail/Tag an GMail-Konten senden. Für B2C-Firmen, wie es Banken nun mal sind, ist damit ein DMARC-Eintrag Pflicht. Eine Policy "p=none" soll aber verhindern, dass Mails aufgrund eines DMARC-Fail abgewiesen werden.

Ich vertrete weiter die Meinung, dass Sie gerne mit einer DMARC-Policy p=none starten können aber auch einen RUA-Eintrag für die Reports brauchen und nach einigen Wochen und Korrekturen bei ihrem Versand dann die Policy auf quarantine/reject stellen.

Diese Seite beschreibt eine reale Konfiguration am 17.5.2026. Sie soll nicht als Pranger missverstanden werden sondern eher als Weckruf für alle Domaininhaber, die mit einer DMARC-Policy "p=none" ihren Versand an Gmail und Co. sicherstellen wollen aber indirekt ihre Domain für Phishing-Missbrauch freigeben.

Wenn Sie nun noch interessiert sind, dann können Sie die Details lesen:

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.


Auszug des Headers

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

Der Header sagt aber noch mehr aus, was wir für weitere Analysen verwenden können:

  • Return-Path: "<notification-ere@vrbank.de>"
    Die meisten Mailserver hinterlegen hier die Adresse, die vom SMTP-Server im Envelope-"MAIL-FROM" gesendet wurde. Diese Domain wird auch für SPF-Checks verwendet, wenn der Empfänger kein DMARC unterstützt. Hier hat der Spammer also die vrbank.de verwendet und darauf gehofft, dass Empfänger diesen Versuch nicht gleich beim SPF-Check ablehnen.

Hier muss ich sagen, dass der Phisher sogar dumm ist. Solange eine Domain eine Policy p=none hat, würde ich besser eine eigene Absenderdomain verwenden, zu der ich den SPF-Eintrag auch passend machen kann. Dann kommen meine Mail zumindest bei rückständigen Mailservern an, die kein DMARC können und nur einen einfachen SPF-Check durchführen.

  • Received: from cynergynetworks.org (70.32.96.105) by mx-kundenserver.de
    Diese Zeile wird vom Empfänger addiert und kann nicht durch den Absender gefälscht werden. Die IP-Adresse 70.32.96.105 ist also der einliefernde Host.
  • Keine DKIM-Signatur
    Ich habe im kompletten Header keine DKIM-Signatur gefunden. Das ist aber nicht überraschend, da ein Spammer sowieso keine gültige DKIM-Signatur für die Absender-Domain addieren kann.
  • From-Header
    Der für den Anwender sichtbare Header ist in klassischer Phishing-Manier ein möglichst passender Name, der vom Empfänger wiedererkannt wird.
  • Authentication-Results
    Für einfache Fehlersuchen haben sich Mailserver angewöhnt, ihre Ergebnisse von SPF, DKIM, DMARC mit in den Header zu schreiben. Hier sehen wir, dass "kundenserver.de" anscheint nur ein "dkim=none" berechnet hat. Bei anderen Firmen sehe ich da oft noch ein SPF-Ergebnis. Sollte das bedeuten, das IONOS gar keinen SPF-Check macht?
  • X-Spam-Flag
    Allerdings wurde die Mail dann wohl von der Text-Analyse von IONOS als Spam klassifiziert. Sie wurde aber nicht beim SMTP-Empfang abgelehnt, sondern in den Spam-Ordner verschoben, wo sie nach einigen Wochen automatisch gelöscht wird. Aus meiner Sicht ein zweifelhaftes Verhalten, da False-Positive damit gelöscht werden, von denen der Absender aber nachweisen kann, dass Sie zugestellt wurden.

SPF-Pass oder Fail?

Daher habe ich mir zuerst den SPF-Record angeschaut.

nslookup -q=TXT vrbank.de

Die beiden "includes" der Domain "Fiduciagad.de" 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"

Sie werden direkt aufgelöst und sind nicht weiter verschachtelt. Damit haben wir auch kein Problem mit mehr als 10 DNS-Aufrufen, die ein Limit wären. Auch das "-all" am Ende ist vorbildlich. Damit können Empfänger eine Mail der vrbank.de als Envelope-From-Adresse direkt ablehnen, wenn Sie von einer anderen IP-Adresse kommt oder Mails von diesen Adresse als legitim ansehen. Spam/Phishing-Filter könne ja in beide Richtungen prüfen.

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. Das ist aber durchaus RFC-konform und die paar DNS-Bytes mehr sind zu vernachlässigen
Laut Atruvia sind die beiden Einträge "net1" und "net2" zwei eigene Mailservices, die aber ein paar Adressen gemeinsam nutzen.

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 liefern müssen.

Aber hier ist vrbank.de ein Lob auszusprechen. Ein  "SPF -all" ermöglichst es Mailservern zumindest Fälschungen beim RFC5321.MailFrom abzulehnen.

DKIM - natürlich nicht

Der Phishing-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. Das DKIM-Ergebnis kann daher auch kein PASS sein.

Ich habe in meinem Postfach auch ein paar legitime Mails einer Volksbank gesehen und im gekürzten Header dort ist schön zu sehen, dass natürlich eine DKIM-Signatur aufgebracht wird.

# Header aus einer legitimen Mail mit DKIM-Signatur, der von IONOS auch mit einem PASS bewertet wurde

Return-Path: <bounce.mailversand@atruvia.de>
Authentication-Results:  kundenserver.de; dkim=pass header.i=@volksbank-dr.de
Received: from rmail11c.gadmail.de ([195.200.34.240]) by mx.kundenserver.de
 (mxeue102 [217.72.192.67]) with ESMTPS (Nemesis) id 1MV3OS-1vRZ7y1hBO-00SRnN
 for <vrbank@carius.de>; Wed, 31 Dec 2025 19:20:36 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=volksbank-dr.de; q=dns/txt; s=rzdka; t=1767205236;
  x=1768414836;
  h=date:from:reply-to:to:message-id:subject:mime-version;
  bh=VXf.....=;
  b=i9IB....==;
MIME-Version: 1.0
From: =?UTF-8?Q?Volksbank_Delbr=C3=BCck-Rietberg_eG?= <info@volksbank-dr.de>
Reply-To:  <noreply.info@volksbank-dr.de>
To:  <vrbank@carius.de>
Envelope-To: <vrbank@carius.de>

Die Phishing Mail hatte aber keine DKIM-Signatur und konnte daher auch kein DKIM=Pass daraus ziehen. Gehen wir weiter zum nächsten Punkt

Offen: Frage an IONOS zu SPF/DKIM/DMARC-Filterung

Bei der Analyse der Header ist mir noch etwas aufgefallen. Die meisten Mailserver addieren die Ergebnisse ihrer SPF/DKIM/DMARC-Analysen als zusätzlichen Header in der Mail. Wenn der Mailserver ARC - Authenticated Received Chain unterstützt, dann werden die Ergebnisse sogar noch digital signiert. In den Mail von IONOS finde ich aber nur die Information über DKIM

# Phishing Mail
Authentication-Results:  kundenserver.de; dkim=none

# Gute Mail
Authentication-Results:  kundenserver.de; dkim=pass header.i=@volksbank-dr.de

Keine Spur von einer kompletten Auswertung mit "Authentication Result" und auch keine Information über SPF.  Bei anderen Server, die nur SPF machen, habe ich oft folgenden Header gefunden

Received-SPF: Pass (protection.outlook.com: domain of......

Ich habe daraufhin versucht zu ermitteln, wie IONOS eingehende Mails analysiert. Gefunden habe ich aber nur sehr viele Artikel, wie man selbst einen SPF/DMARC-Eintrag setzt, damit der eigene Versand besser funktioniert.

Aber keine Informationen, wie IONOS eingehende Mails selbst bewertet und filtert. Es gibt in der Verwaltung nur eine Einstellung zwischen

Bei IONOS gibt es aber unter "https://postmaster-contact.ionos.de/" eine Möglichkeit, Fragen zu Mails zu senden. Ich warte hier noch auf eine Antwort.

DMARC Fail mit p=none

SPF ist mit einem "-all" sauber, auch wenn IONOS das anscheinend nicht so streng sieht und eine gültige DKIM-Signatur konnte der Spammer nicht aufbringen. Warum ist dann die Mail nicht abgelehnt worden?. Hier kommen wir dann zu DMARC. Mit diesem DNS-Eintrag teilt der Inhaber einer Domain der Welt mit, wie die empfangenden Spamfilter damit umgehen sollen. Von den verschiedenen Einstellungen möchte auch auf drei eingehen

  • RUA=mailadresse | url
    Damit weise ich DMARC-taugliche Empfänger an, mich per Mai oder HTTPS-Aufruf über die Ergebnisse zu informieren. Als Absender sollte ich immer mal wieder prüfen, ob legitime Mails wirklich zugestellt werden, ich kann sehen, wer eine Fälschung versucht aber insbesondere sollte ich die legitimen Mails finden, die irrtümlich abgewiesen werden (False Politive).
  • Policy p=none | quarantine | reject
    Mit dieser Einstellung teile ich der Welt mit, wie mit Mails umgegangen wird, die die DMARC-Validation nicht bestehen. Ein "none" wird als Monitoring-Mode bezeichnet, d.h. das DMARC-Ergebnis soll nicht bewertet werden. Sie können sich selbst überlegen, wie sinnvoll dann eine DKIM-Signatur ist, wenn sie nicht bewertet werden darf. Wenn Sie DMARC einführen, sollten Sie mit none starten und nach einer Auswertung ablehnen.
  • Alignment adkim=r | s und aspf = r | s
    Die große Änderung von DMARC betrifft den SPF-Check. Über das Alignment wird die Domain der RFC5321.MailFrom-Adresse (Envelope/P1) mit der RFC5322.From-Adresse (Header-From/P2) verglichen. Sie muss exakt (strict) oder eine Subdomain (relaxed) sein. Im Grunde wird damit der SPF-Check auf die Domain im Header statt des Envelope umgestellt.

Die DMARC-Eintrag der Domain "vrbank.de" am 17. Mai 2026 sah wie folgt aus:

Die vrbank.de sagt den Phishing/Spamfiltern der Welt, dass Sie gerne eine SPF/DKIM-Prüfung anhand der DMARC-Richtlinie machen können aber das Ergebnis nicht zum Ablehnen der Mail führen darf. Ich habe einfach selbst eine Phishing-Mail als "vrbank.de" an ein Testpostfach von learndemarc.com per TELNET gesendet. Hier das Transcript.

LearnDMARC hat die Mail empfangen und ausgewertet. Die Kurzfassung ist:

Das ist natürlich erwartet: DMARC schreibt ein p=none vor und  daher werden die Ergebnisse nicht gewertet. Da ist es dann auch egal, dass im Bereich DMARC sowohl der SPF als auch der DKIM-Test einen Fail ausweisen. Wir sehen aber auch, das der reine SPF-Check sich hier auf den RFC5321.MailFrom bezieht. Hier kommt wie auch bei der echten Phishing-Mail ein Fail. mit dem "SPF -all" hätte jeder halbwegs sinnvoll konfigurierte Spamfilter die Mail direkt abgewiesen. Anscheinend hat der Postmaster von IONOS aber hier eine Ansicht und nimmt diese Mails an.

Vielleicht erspart er sich dadurch einfach viele Supportticket, wenn Sender oder Empfänger sich über abgewiesene Mails beschweren und den Fehler im SPF-Record des Absender nicht erkennen.

Was bedeutet aber ein p=none für alle Firmen die einen Spamfilter mit DMARC-Support haben? Sie nutzen beim SPF-Check den RFC5321.From aus dem Envelope und den kann ein Spammer/Phisher sehr einfach gültig setzen. Der Empfänger sieht diese falsche Adresse im Normallfall nie und ins Alignment wird sie aufgrund der DMARC-Policy nicht einbezogen.

Heute ist es leider so, dass Phishing über einen einfachen SPF-Check quasi keinen Nutzen mehr hat, denn Spammer/Phisher können diese Hürde einfach nehmen. Erst mit einem DMARC-Eintrag "p=Quarantäne | Reject" aktiviert auch das Alignment, so dass die Domain im Envelope mit dem Header abgeglichen wird und Fälschungen der Absenderdomain beim DMARC-tauglichen Empfänger auch blockiert werden.

Eine DMARC-Policy "p=none" ist also nicht falsch aber heute nicht mehr ausreichend. Das ist sicher auch ein Grund, dass große Provider einen DMARC-Eintrag beim Absender erwarten und ansonsten eine Drosselung einsetzen.

Es könnte also sein, dass viele Firmen erst mal schnell einen "DMARC p=none"-Eintrag setzen, um die Anforderungen von Google und Co zu erfüllen aber nicht weiter gedacht haben. Dazu passt dann auch, dass eine Domain keinen RUF/RUA-Eintrag hat. 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" einstellen will.

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.

Das sieht nach einem virtuellen Server für Webhosting auf, auf dem ein nicht weiter konfigurierter Apache Server auf Anfragen wartet. Die IP-Adresse gehört zu einem Godaddy-Netzwerk.

Mit einer Antwortzeit von ca. 150ms auf einen PING dürfte der Server auch nicht  in Europa stehen. USA scheint ein plausibler Standort zu sein.

Auf Port 25 lieft ein Postfix, der am 17. Mai zumindest auf den ersten Blick zumindest kein offenes Relay ist und ich habe auch keine weiteren "Received:"-Header gefunden. Entweder das der Besitzer dies so konfiguriert oder der Hoster hat zumindest hier ein besseres Default-Setup.

Es sieht also alles so aus, als ob dort ein Angreifer einen virtuellen Server gemietet,  ein Postfach mit Anmeldung angelegt 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. Der SPF-Eintrag mit dem "-all" ist gut und korrekt und man muss IONOS fragen, warum deren Mailserver solche "SPF:HardFail" nicht ablehnt, sondern annimmt und in Quarantäne stellt. Aber wie so oft gilt hier: "Mein Haus, meine Hausordnung". Ohne eine DMARC-Policy mit "Quarantine | reject" nimmt man aber modernen Empfängern mit DMARC-Verständnis einen Weg die Mails entsprechend zu behandeln.

Ich warte eigentlich schon darauf, dass Google und Co nicht nur eine DMARC-Eintrag erwarten, sondern gleich noch eine strengere Policy und DKIM-Signierung. Getreu "Mein Haus, meine Hausordnung"

Leider weiß ich nicht, ob "vrbank.de" seine Mails auch per DKIM signiert. Einige andere Volkbanken tun dies, aber das würde ein DMARC-Policy "p=none" 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.

Angeblich weißt Atruvia seine Kunden auf die Notwendigkeit eines DMARC-Eintrag für Google und Co hin. Ob dort auch über Reporting und p=reject informiert wird, kann ich nicht sagen.

Atruvia/Fiducia

Vielen Lesen wird bekannt sein, dass nicht jede kleine Volks- und Raiffeisenbank ihr eigenes RZ betreibt, sondern man sich eines Dienstleisters bedient, Wie bei Aldi Süd/Nord gab es früher die Fiducia im Karlsruhe und die GAD in Münster, die sich im Sommer 2025 zur Atruvia AG zusammengeschlossen haben. Wer den MX-Record für die verschiedenen VR-Banken abfragt, erkennt die zentrale Funktion z.B. für den Empfang per SMTP.

Auch an anderer Stelle erscheinen die drei Namen Atruvia, Fiducia und GAD immer mal wieder, z.B. im SPF-Eintrag

Das sind aber einfach die normalen Altlasten. Sie finden selbst in Teams immer noch Hinweise auf "OCS" und das war der Office Communication Server, ehe er zu Lync und dann Skype for Business umbenannt wurde. Selbst in neuen Produkten wie Azure erscheint auch noch der frühere Codename Reddog und Azure DHCP. Das hat keinen Einfluss auf die Funktion.

Atruvia hat zumindest einen etwas erweiterten DMARC-Record gesetzt.

Zwar steht auch hier noch ein p=none aber zumindest sammelt jemand die Rückmeldung von DMARC-Reports ein.

Laut DNS-History gibt es den DMARC-Eintrag seit 16. Feb 2024 und wurde am 23. Mai 2026 zuletzt aktualisiert.


 https://dnshistory.org/dns-records/_dmarc.atruvia.de 

Ich weiß nicht, welcher Wert vorher dort stand aber vielleicht sehen wir in ein paar Wochen zumindest ein "p=quarantine".

Kann ich nun Atruvia etwas vorwerfen? Ich würde es bei einem JEIN lassen, denn natürlich müssen Firmen mit hohem B2CA-Mailverkehr, die auch mehr als 5000 Mails/Tag an Google, Yahoo und outlook.com senden wollen, auf jeden Fall einen DMARC-Record setzen. Da erscheint ein DMARC mit "p=none" der naheliegende Weg diese Anforderung zu erfüllen. Allerdings sollte dies nur ein Zwischenschritt auf Zeit sein und durch einen RUA-Eintrag begleitet werden. Nur dann kann der Versender auch ermitteln, welche Systeme in seinem guten Namen senden. Anhand der Ergebnisse könnte der Versender auch nachsteuern und nach einigen Wochen die DMARC-Policy auf "p=reject" oder zumindest "p=quarantine" stellen.

Weitere Links