Warum quillt Ihr Posteingang über von Unzustellbarkeitsberichten für Kampagnen, die Sie nie gestartet haben? Das Dashboard Ihres E-Mail-Tools zeigt null Versand an. Trotzdem häufen sich die NDRs seit dem Vortag. Dieses Phänomen hat einen präzisen Namen: Backscatter. Ein Spammer hat Ihre Domain als Rückantwortadresse für seine betrügerischen Sendungen verwendet; die Server, die diese Nachrichten nachträglich abweisen, schicken Ihnen die Rechnung in Form von Bounces zurück. Das hat nichts mit einem Hack Ihres Kontos oder einem Leck Ihrer Kontaktliste zu tun.
Der Mechanismus des Backscatter: sichtbares From und Return-Path, zwei getrennte Adressen
Der Mail-Client zeigt einen Absender an. Der SMTP-Befehl MAIL FROM trägt einen anderen, der in der Oberfläche unsichtbar bleibt. Diese zweite Adresse, der Return-Path, ist das Ziel für Bounces. Ein Spammer fälscht dieses technische Feld, nicht zwangsläufig das sichtbare From, das der Empfänger in seinem Postfach sieht. Er trägt Ihre Domain im SMTP-Umschlag beim MAIL-FROM-Befehl ein, ohne dass der Nachrichtentext jemals Ihren Namen anzeigt. Diese Unterscheidung bestimmt alles Folgende, einschließlich der Wahl der Einstellung, die den Fluss unterbindet. Der vollständige Mechanismus der Identitätsfälschung, vom gefälschten technischen Umschlag bis zum sichtbaren Absendernamen, behandelt unser Artikel über wie E-Mail-Spoofing funktioniert. Hier ist das Ziel enger gefasst: der technische Umschlag, den das Protokoll zum Routen von Fehlerberichten verwendet, unabhängig von der Nachricht, die der eigentliche Empfänger tatsächlich liest.
Warum der Server des Empfängers den Bounce an Sie zurückschickt
Weil er den Fehlerbericht an die im Umschlag eingetragene Adresse sendet. Diese Adresse trägt Ihre Domain. Kein Element des Protokolls erlaubt es ihm zu erkennen, dass sie gefälscht wurde. Im Detail gibt es zwei Verhaltensweisen bei einem Server, der eine betrügerische E-Mail empfängt. Der erste weist die Verbindung direkt zurück, während der SMTP-Transaktion, mit einem sofortigen Fehlercode; dabei entsteht nie ein Bounce, das Problem endet direkt beim sendenden Server des Spams. Der zweite akzeptiert die Nachricht. Er entdeckt das Problem zu spät: Das Postfach ist voll oder der Empfänger existiert nicht. Dieser zweite Fall erzeugt den Backscatter: Der Server generiert einen NDR (Non-Delivery Report) im Format der RFC 3464 (IETF, 2003) und sendet ihn dann gutgläubig an den gefälschten Return-Path.
Ein Forscher, der innerhalb von vier Monaten 49.000 Backscatter-Nachrichten erhielt, hat seine Bounces mit vier Blocklists abgeglichen: Von 4.177 Bounces mit identifizierbarer sendender IP standen 19 % dieser IPs dort noch nicht, SpamCop meldete 73 % und CBL 69 % (Christopher Fuhrman, École de technologie supérieure de Montréal, 2008).
Diese alte Feststellung bleibt aktuell. Falsch konfigurierte Server, die annehmen und dann ablehnen, statt gleich am Eingang zurückzuweisen, bilden einen Restbestand, der weiterläuft, oft Unternehmens-Mailsysteme, die von Teams verwaltet werden, die die gängigen SMTP-Empfehlungen nicht mehr befolgen. Die vollständige Typologie der verschiedenen Ursachen für unzustellbare E-Mails behandeln wir an anderer Stelle. Der Backscatter kommt dort als Sonderfall hinzu, von Dritten erzeugt und ohne Zusammenhang mit Ihrem eigenen Versand.
Die Bounce-Header lesen, um zu bestätigen, dass der Versand nicht von Ihnen stammt
Ein verdächtiger Bounce trifft ein. Drei Prüfungen genügen in der Regel, um Klarheit zu schaffen, in dieser Reihenfolge:
- Die Received-Kette am Anfang der Rohnachricht listet jeden durchlaufenen Server vom ersten bis zum letzten auf. Wenn keiner davon Ihrer üblichen Versandinfrastruktur entspricht, IP, MTA, identifizierte E-Mail-Plattform, liegt der Ursprung extern.
- Die Message-ID der Originalnachricht, die meist als teilweises Zitat im Bounce-Text enthalten ist. Eine Message-ID, die Ihre eigenen Versandprotokolle nie erzeugt haben, bestätigt, dass die Nachricht nie von Ihnen versendet wurde.
- Der Enhanced Status Code des Berichts, im Format 5.x.x, gibt die genaue Ablehnungsursache seitens des Empfängerservers an: nicht existierendes Postfach oder überschrittenes Quota.
Ein Backscatter-Bounce erkennt man an der vollständigen Nichtübereinstimmung zwischen seiner Message-ID und den Versandprotokollen des legitimen Absenders, unabhängig von der verwendeten Versandplattform, Twilio SendGrid, Mailjet oder einem eigenen SMTP-Server. Ohne diese Übereinstimmung ist keine weitere Untersuchung nötig.
Was es nicht bedeutet: weder Hack noch Listen-Leck
Die erste Reaktion beim Entdecken Dutzender unbekannter NDRs neigt oft zur Annahme eines kompromittierten Kontos. Das ist verständlich. Doch ein Backscatter setzt keinen Zugriff auf die Domain oder das Postfach voraus, kein Leck der Kontaktdatenbank, keine Kompromittierung des E-Mail-Tools. Der Spammer braucht nur eine öffentliche Information, Ihren Domainnamen, um ihn in den Umschlag eines Versands einzutragen, der Ihre Server nie betrifft. Man könnte auch glauben, ein ESP genüge, um dieses Risiko abzudecken, da er die Authentifizierung ausgehender Sendungen bereits verwaltet. SPF und DMARC werden jedoch auf DNS-Ebene der Domain deklariert, nicht auf Ebene des Versandtools: ein ESP-Wechsel schließt also nichts, solange diese Einträge fehlen oder zu freizügig sind.
Danach kommt regelmäßig eine weitere Sorge auf: Führt diese Flut dazu, dass ich auf eine Blocklist gerate? Backscatterer.org, die diesem Phänomen gewidmete Blocklist, erfasst die Server, die Backscatter versenden, niemals die missbrauchten Domains, die ihn empfangen. Man landet dort, indem man Bounces an unschuldige Dritte zurückschickt. Tausende davon zu empfangen ändert daran nichts.
Was sich tatsächlich tun lässt: SPF mit Hard Fail veröffentlichen
Ein SPF-Eintrag, der mit -all veröffentlicht wird, ist die einzige Einstellung, die an der Quelle des Backscatter ansetzt. Dieser Hard Fail verlangt vom empfangenden Server, während der SMTP-Transaktion jede Nachricht abzulehnen, die Ihre Domain als MAIL FROM einträgt, ohne von Ihren autorisierten Servern zu stammen. Die Nachricht stirbt an der Tür, es wird kein NDR erzeugt, nichts geht an Sie zurück. Unser Artikel darüber, was passiert, wenn SPF fehlt, beschreibt die vollständige Syntax. Die Falle der Überschreitung erklärt dieser Leitfaden zu dem Limit von 10 DNS-Lookups. Was keine Konfiguration hingegen leisten kann: einen Spammer daran hindern, Ihre Domain in einen Umschlag zu schreiben, oder einen schlecht konfigurierten Drittserver dazu zwingen, SPF zu respektieren.
DMARC wirkt auf einer anderen Ebene. Diese Nuance entscheidet darüber, was Sie hier erwarten können. Eine Richtlinie mit p=quarantine oder p=reject wird anhand der Domain im From-Header-Feld bewertet, also demjenigen, den der Empfänger sieht, nachdem geprüft wurde, ob eine DKIM-Signatur oder eine SPF-Prüfung diese Domain tatsächlich authentifiziert. Das ist die Alignment-Regel. Wenn sich der Spammer damit begnügt, nur den Umschlag zu fälschen, und seine Nachricht mit einem From signiert, das nicht zu Ihrer Domain gehört, wird Ihre DMARC-Richtlinie vom empfangenden Server also nie herangezogen. Sie schützt Ihre Marke vor sichtbarer Identitätsfälschung, stoppt aber allein nicht die verirrten Bounces: Diese Aufgabe übernimmt SPF, wobei DMARC einspringt, sobald der Spammer auch das angezeigte From fälscht.
Auf der Empfangsseite regelt BATV (Bounce Address Tag Validation) die Sortierung an der Wurzel. Ihr Server signiert die Rückantwortadresse jeder ausgehenden Sendung mit einem datierten Token und lehnt anschließend jeden NDR ab, der an eine unsignierte Adresse gerichtet ist. Ein Backscatter kann dieses Token nicht tragen, da er auf einen Umschlag antwortet, den Sie nie versendet haben. Die Überwachung der aggregierten DMARC-Berichte (rua) gibt zudem ein Bild von Umfang und Herkunft der Identitätsfälschung, ohne sie jemals an der Quelle zu stoppen, mit derselben Einschränkung wie oben: Diese Berichte erfassen nur Nachrichten, die Ihre Domain im From-Header tragen. Eine auf den Umschlag beschränkte Fälschung wird dort nicht erscheinen. Unser Leitfaden, um einen aggregierten DMARC-Bericht zu lesen, erklärt das Lesen dieser XML-Dateien im Detail.
Diese Verschärfung hat eine Obergrenze. Ein SPF-Hard-Fail bringt Server nicht zum Schweigen, die die Richtlinie ignorieren, ihren Resolver nicht aktualisiert haben oder eine unvollständige Auswertung der DNS-Einträge vornehmen. Dieser Restbestand produziert weiterhin verirrte Bounces, selbst nach korrekter Bereitstellung auf Domain-Seite. Das -all hat außerdem einen Nachteil, den man kennen sollte: Eine legitime Nachricht, die über einen Alias oder ein Weiterleitungspostfach zugestellt wird, scheitert beim Empfänger an der SPF-Prüfung, da die IP, die die Nachricht überträgt, nicht mehr Ihre eigene ist. Gut gepflegte Weiterleitungsserver schreiben den Umschlag über SRS um, um das zu vermeiden; die übrigen zerstören Ihre Weiterleitungen.
Prüfen, ob der eigene Server keinen Backscatter erzeugt
Der Gedankengang lässt sich umkehren. Diese Hälfte des Themas wird fast immer verschwiegen. Ein Server, der alles annimmt und dann einen NDR zurückschickt, erzeugt genau das oben beschriebene Rauschen, allerdings bei jemand anderem. Die Einstellungen, die dieses Verhalten verursachen, sind bekannt:
- eine Catch-all-Adresse, die jeden Empfänger annimmt, bevor sie feststellt, dass das Postfach nicht existiert;
- ein Abwesenheits-Autoresponder, der mechanisch auf einen gefälschten Umschlag antwortet;
- ein Antispam-Gateway, das erst nach der Annahme filtert, statt während der SMTP-Transaktion abzulehnen.
Die Korrektur besteht aus einer Regel: die Existenz des Empfängers beim RCPT TO prüfen und dort mit einem Code 5.x.x ablehnen, statt anzunehmen und sich anschließend zu entschuldigen. Das unterscheidet einen Server, der andere schützt, von einem Server, der auf Backscatterer.org landet.
Backscatter nicht mit einer tatsächlich schmutzigen Liste verwechseln
Ein plötzlicher Anstieg von Bounces in den Versandstatistiken sieht auf den ersten Blick wie eine Verschlechterung der Sender Reputation aus. In den meisten Fällen ist dem nicht so, wenn die Bounces nie gestartete Kampagnen betreffen. Diese Verwechslung wird teuer, wenn sie dazu führt, eine Kontaktliste aufgrund eines Signals zu bereinigen, das gar nicht von ihr stammt: Die von Google Postmaster Tools gemeldeten Zustellungsfehler ebenso wie die Hard-Bounce-Zähler Ihrer Versandplattform bleiben taub für Backscatter, der nie über Ihre eigenen Kampagnen lief, da kein tatsächlicher Versand ihn ausgelöst hat. Bevor Sie aufgrund einer Flut von NDRs auf mangelhafte List Hygiene schließen, prüfen Sie anhand der oben beschriebenen Header, ob diese Bounces zu einem tatsächlichen Versand gehören oder zu einem gefälschten Umschlag: Das Bereinigen der Kontaktliste löst nichts, wenn das Problem woanders liegt.
Die Verbreitung von DMARC nimmt zu, angetrieben durch die Vorgaben von Google und Yahoo für Großversender seit Februar 2024, die mindestens eine veröffentlichte Richtlinie mit p=none verlangen. Die 2026 veröffentlichte Überarbeitung des Standards unter dem Namen DMARCbis (RFC 9989) hebt diese Schwelle nicht an: Sie formuliert das Protokoll neu und ersetzt die Liste öffentlicher Suffixe durch eine DNS-Baumhierarchie-Auflösung, ohne jemandem eine strikte Richtlinie vorzuschreiben. Der Restbestand falsch konfigurierter Mailsysteme folgt hingegen einem viel langsameren Zeitplan, dem der DNS-Aktualisierungen, die niemand geplant hat.
