Undeliverable: outgoing messages failure - Fake-Bounce mit grünem SPF, DKIM und DMARC

Mein Mailserver hat mir geschrieben. Eine ausgehende Mail sei hängen geblieben, ich solle sie prüfen oder löschen. Nett von ihm. Nur hat mein Mailserver keine Adresse bei einer US-Domain, die früher eine Squarespace-Seite war.

Was in der Mail steht

Betreff: Undeliverable: outgoing messages failure. Absender: Postmaster <kira[@]foreplate[.]com>. Domains und URLs sind in diesem Artikel defangt, damit nichts aus Versehen angeklickt wird.

Oben ein grüner Balken mit „Message from <meine Domain> server“. Darunter:

The delivery of messages was stopped by the <meine Domain> mail server. You have 1 pending message that could not be sent as of 10/26/2026 6:54:12 a.m. Click to Review or Delete pending outgoing e-mail messages.

Unterschrieben von „Mail Administrator“. Kein Logo, keine Frist, keine Drohung. Das ist Absicht. Eine Systemmeldung, die nicht schreit, wirkt glaubwürdiger als eine, die mit Kontosperrung droht.

Inhaltlich hakt es trotzdem. „Undeliverable“ heißt: Eine Mail kam beim Empfänger nicht an. Der Text redet aber von einer Mail, die gar nicht erst raus ist. Und dann gibt es zwei Links, „Review“ und „Delete“. Beide führen auf exakt dieselbe Adresse. Die Wahl ist reine Deko.

Warum SPF, DKIM und DMARC hier nichts bringen

Der Header ist auf den ersten Blick blitzsauber. SPF pass, DKIM pass, DMARC aligned. Kein gekapertes Postfach, kein Spoofing, kein Relay. Eine einzige Station in der Received-Kette: vom Server local[.]foreplate[.]com (45[.]74[.]252[.]170) direkt zum Empfänger.

Das hat einen einfachen Grund: Die Domain gehört dem Angreifer. foreplate[.]com war bis 2018 eine kleine Website auf Squarespace. Dann ist sie verfallen und wurde 2020 neu registriert. Seit Mai 2026 hängt dahinter ein eigener Mailserver bei Valkyrie Hosting (AS397081, USA). Die IP wechselt alle sechs bis acht Wochen, immer im selben Netz: .5, .150, .48, jetzt .170. Wer eine IP verbrannt hat, nimmt eben die nächste.

SPF und DKIM beantworten nur eine Frage: Darf dieser Server für diese Domain senden? Ja, darf er. Ob die Domain einem Betrüger gehört, steht da nicht drin. Ich habe das schon beim cPanel-Webmail-Phishing geschrieben. Dort gehörte dem Angreifer gar nichts, alles war gekapert. Hier ist es umgekehrt: Ihm gehört alles. Das Ergebnis ist dasselbe, alles grün.

Ein paar Details verraten den Mailer trotzdem. Die DKIM-Signatur nutzt rsa-sha1, was seit 2018 nicht mehr verwendet werden soll. Daneben steht ein DomainKey-Signature-Header, der Vorgänger von DKIM, seit 2007 obsolet. Die Message-ID ist ein Zeitstempel plus 16 Hex-Zeichen, ein X-Mailer fehlt. Und im DNS steht neben dem SPF-Record ein verirrter TXT-Eintrag mit dem Inhalt @. Denselben Fehler und denselben SPF-Aufbau hat eine zweite Domain, steelscabinet[.]com, die im Juli auf derselben IP lag. Das ist kein Zufall, das ist ein Setup-Skript.

Wer F12 drückt, sieht drei Webmailer

Der HTML-Code ist ein Fundstück für sich. Die Absätze tragen die Klasse v1v1yiv9201021698gmail_quote_mr_css_attr. Das ist Webmail-Archäologie. gmail_quote stammt aus Gmail. yiv plus Ziffern hängt Yahoo Mail davor, _mr_css_attr kommt von Mail.ru, v1 von einem weiteren Webmailer. Ganz am Ende steht Apple-interchange-newline, der Fingerabdruck von Copy-Paste aus Safari.

Heißt: Jemand hat eine echte Mail, die durch mehrere Postfächer gewandert ist, im Browser markiert und als Vorlage eingefügt. Externe Bilder oder ein Tracking-Pixel gibt es nicht.

Was die eigentlich wollen

Der Link sieht so aus:

hxxps://duis294-hrsac931-p0n[.]checkflicked[.]eu/?xgi=<empfängeradresse>&ndu=hdwlJbAz…TXU=

xgi ist meine Adresse im Klartext. Damit füllt die Zielseite das Login-Formular vor, und schon der Klick bestätigt, dass die Adresse lebt. ndu ist ein 32-Byte-Token, vermutlich zur Prüfung, ob Adresse und Token zusammenpassen. Scanner, die nur die Adresse austauschen, sehen dann nichts.

Wer klickt, landet auf einem nachgebauten Webmail-Login. Adresse steht schon drin, fehlt nur noch das Passwort. Mit dem Passwort hat der Angreifer das Firmenpostfach. Er liest Rechnungen und Kundenkorrespondenz mit, legt Weiterleitungen an und verschickt die nächste Welle aus einem echten, sauber authentifizierten Postfach. Genau so ein gekapertes Postfach hat die cPanel-Kampagne als Absender benutzt.

Die Domain checkflicked[.]eu liegt hinter Cloudflare, das Zertifikat ist vom 9. Oktober, 17 Tage vor dem Versand. Pro Welle gibt es eine neue Subdomain. Bekannt sind drei, zwei davon fast Anagramme voneinander (duis294-hrsac931-p0n, uisd829-cuisn270-d1n). VirusTotal meldet für die URL 13 von 93 Treffern. Der Server dahinter antwortet allerdings schon nicht mehr, Cloudflare liefert einen Fehler 522. Das Zeitfenster war also kurz.

Die eine Bremse, die nicht gezogen wurde

Jetzt der eigentlich interessante Teil. Fast alle harten Negativ-Indikatoren dieser Mail kommen von Spamhaus. Die Versand-IP steht auf der Spamhaus-CSS-Liste. checkflicked[.]eu steht auf der Domain-Blockliste DBL als Phishing, foreplate[.]com als Malware. Jeder einzelne Treffer hätte die Mail im Spamfilter deutlich nach oben gedrückt.

Nur hat der Spamfilter Spamhaus nie gefragt. In den Headern stehen URIBL_DBL_BLOCKED, RBL_SPAMHAUS_BLOCKED_OPENRESOLVER und DBL_BLOCKED_OPENRESOLVER. Übersetzt: Spamhaus hat die Abfrage abgelehnt, weil sie über einen öffentlichen Resolver kam. Ohne diese Listen blieb SpamAssassin bei 3,1 von 7 Punkten. Mein Analyse-Postfach nimmt absichtlich alles an, sonst könnte ich solche Mails nicht zerlegen. Der Befund gilt aber unabhängig davon: Ohne funktionierende Spamhaus-Abfrage sieht die Mail für den Filter fast harmlos aus.

Woran ihr's erkannt hättet

Ein echter Bounce kommt von eurem eigenen Server, meist als „Mail Delivery System“ oder MAILER-DAEMON. Er hängt die Originalmail an und enthält keinen Link, schon gar keinen zum Login. „Postmaster“ von einer fremden Domain ist kein Postmaster.

Mit der Maus über „Review“ fahren reicht: Das Ziel ist nicht eure Domain. Und wer eine Wahl zwischen zwei Buttons anbietet, die beide gleich verlinkt sind, will gar keine Entscheidung. Er will einen Klick.

Was ihr tun könnt

Einmal zeigen, wie ein echter Bounce aussieht. Schickt eine Mail an eine erfundene Adresse in eurer Domain und zeigt dem Team die Antwort. Zehn Minuten, danach fällt jeder Fake-Bounce auf.

Zwei-Faktor-Anmeldung für Webmail und Hosting-Panel einschalten, wo der Hoster sie anbietet. Für Mailprogramme App-Passwörter nutzen. Ein abgefischtes Passwort allein reicht dann nicht mehr.

Beim Hoster nachfragen, ob Spamhaus wirklich abgefragt wird. Wer selbst einen Mailserver betreibt, braucht einen eigenen Resolver oder einen Spamhaus-DQS-Zugang. Hier hätte das den Unterschied gemacht.

Nach einem Verdachtsklick sofort Passwort ändern und Weiterleitungen, Filterregeln und Abwesenheitsnotizen kontrollieren. Dort richten sich Angreifer gern ein.

Die eigene Domain prüfen. Hilft nicht gegen diese Mail, aber gegen den nächsten Schritt, wenn jemand euer Postfach missbraucht. Den Mail-Check hier auf der Seite könnt ihr dafür nutzen. DMARC auf p=none ohne Reporting ist dasselbe wie gar kein DMARC.

Fazit

Das Template ist zusammenkopiert, der Text widerspricht sich, und an den Buttons merkt man, dass sich niemand Mühe gegeben hat. Technisch ist die Kampagne trotzdem ordentlich: eigene Altdomain, eigener Mailserver, alles authentifiziert, Landing hinter Cloudflare. Wer sich bei Phishing-Erkennung auf grüne Häkchen bei SPF und DKIM verlässt, hat hier verloren. Gerettet hätte nur die Reputationsabfrage, und die ist nie angekommen.