E-Mail-Bounces lesen: was jeder Code bedeutet

Was ein Bounce ist, und die zwei Momente, in denen er entsteht

Das Wort ist der Papierpost entliehen, und das Bild trifft nicht zu. Nichts läuft zurück. Eine Nachricht wird von Server zu Server weitergereicht, und der letzte, der sie noch hat und sie nicht loswird, schreibt eine neue Nachricht — an Sie adressiert, über die alte — und schickt diese stattdessen ab. Alles, was Sie erfahren können, steht in diesem Bericht, und der Bericht ist nur so gut wie die Maschine, die ihn geschrieben hat.

Er kann in zwei ganz unterschiedlichen Momenten entstehen, und die beiden auseinanderzuhalten ist der größte Teil der Diagnose. Zwei weitere Ausgänge sehen von Ihrer Warte aus wie Fehlschläge aus und sind keine:

Von einem Bounce zu sprechen, meint also zwei Dinge. Das eine ist ein Fehler, den Ihre eigene Software Ihnen angezeigt hat, das andere ein Brief, den die Maschine eines Fremden Ihnen geschrieben hat — und nur im zweiten Fall steckt ein Bericht darin, den man lesen kann. Der Rest dieser Anleitung handelt von diesem Bericht.

Wo der eigentliche Grund steht

Ein Zustellbericht ist eine Nachricht in drei Teilen, und diese Form ist seit RFC 3464 festgelegt. Der erste Teil ist die Entschuldigung, für einen Menschen geschrieben von der Maschine in Ihrer Nähe. Der zweite ist der maschinenlesbare Block, der einzige Teil mit Fakten darin. Der dritte ist Ihre ursprüngliche Nachricht, oder nur ihre Header, damit Sie erkennen können, um welche es geht.

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

Lesen Sie den mittleren Teil in dieser Reihenfolge:

Final-Recipient:

Welche Adresse fehlgeschlagen ist. Ein Bericht kann einen Block pro Empfänger tragen, bei einer an mehrere Personen gesendeten Nachricht erkennen Sie so, um wen es geht — und die anderen sind womöglich durchaus angekommen.

Action:

failed ist ein Bounce. delayed ist eine Warnung, dass ein Server es noch versucht und noch nichts aufgegeben hat; es kann noch ein zweiter Bericht kommen, der Erfolg meldet. relayed und delivered sind gar keine Fehlschläge und werden leicht als einer missverstanden.

Status:

Der erweiterte Statuscode — drei Zahlen, gedacht zum Lesen durch Software, nicht durch Sie. Das ist der Teil, der zwischen einem Anbieter und einem anderen vergleichbar ist, was die Sätze nie sind.

Diagnostic-Code:

Die Zeile, auf die es ankommt. Es ist die eigene Antwort des fernen Servers, Wort für Wort zitiert, mit seinem Antwortcode und dem Satz, den sein Administrator geschrieben hat. Alles darüber ist eine Nacherzählung; das hier ist das Original.

Remote-MTA:

Welcher Host es gesagt hat. Einen Blick wert, sobald es beim Fehlschlag ums Routing geht: Ein Hostname, den Sie nicht erkennen, bedeutet meist, dass die Mail der Domain irgendwohin geht, wo Sie sie nicht erwartet hätten, oder wohin sie nur früher ging.

Der Satz ganz oben im Bericht ist kein Beweis. Ihr eigener ausgehender Server schreibt ihn, in welchem Wortlaut auch immer seine Software gerade mitbringt, über einen Fehlschlag, den er nur weitergibt. Zwei identische Entschuldigungen können über zwei völlig unabhängigen Diagnostic-Code:-Zeilen stehen, weshalb ein von oben gelesener Bounce so oft falsch verstanden wird.

Die zwei Zahlen, und die Ziffer, die entscheidet

Eine Ablehnung ist so geschrieben, und es sind drei getrennte Dinge, durch Leerzeichen verbunden:

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

Die 550 ist der Antwortcode: drei Ziffern, von SMTP selbst in RFC 5321 festgelegt, und der Teil, den das Protokoll braucht, um zu entscheiden, wie es weitergeht. Die 5.1.1 ist der erweiterte Statuscode aus RFC 3463, hinzugefügt, weil drei Ziffern nicht genug ausdrücken konnten. Alles danach ist Freitext, geschrieben von wem auch immer diesen Server betreibt, und durch nichts standardisiert.

Beide Zahlen beginnen mit derselben Ziffer, und diese Ziffer ist das Urteil:

Die zweite Zahl ist das Thema — welche Art von Sache schiefgegangen ist. Das ist der schnellste Weg, einen Code einzuordnen, den Sie noch nie gesehen haben:

Hard Bounce

Eine 5. Die Adresse ist falsch, verschwunden, oder aus Richtliniengründen abgelehnt, und dieselbe Nachricht erneut zu senden ändert nichts. Massenversender streichen eine Adresse schon beim ersten von der Liste, denn weiterzumachen ist genau das, was eine Versanddomain überall gleichzeitig ausbremst.

Soft Bounce

Eine 4. Ein volles Postfach, ein ausgelasteter Server, eine vorübergehende Richtlinienablehnung. Sie wird ohne fremdes Zutun erneut versucht und kommt meist an; Sie erfahren nur davon, wenn zuerst die Versuche ausgehen.

Keiner der beiden Ausdrücke steht in einer Spezifikation. Beide sind der Kurzbegriff der Versandbranche für genau diese erste Ziffer — und den Kurzbegriff zu kennen lohnt sich, weil jedes Zustellbarkeits-Tool, das Ihnen je in die Hände kommt, in genau diesen Begriffen berichtet.

Die Codes, denen Sie tatsächlich begegnen

Im Register, das die IANA führt, gibt es Dutzende, im Alltag etwa ein Dutzend. Diese hier decken so gut wie jeden Bounce ab, den irgendjemand liest:

Codes außerhalb dieser Liste gibt es, und jeder von ihnen bedeutet etwas, aber ein Code, den Sie noch nie gesehen haben, ist fast immer ein .7. — irgendjemandes Richtlinie, in eigenen Worten beschrieben auf der Zeile daneben.

Was an einer Wegwerf-Adresse einen Bounce auslösen kann, und was nicht

Fast nichts — und das ist es wert, ausbuchstabiert zu werden, denn drei der Dinge, die man hier als Bounce bezeichnet, sind keiner:

„Unbekannter Empfänger“ kann nicht vorkommen

Der Server akzeptiert jeden Namen auf seinen öffentlichen Domains. anything@grabmail.io ist eine gültige Adresse, noch bevor sie irgendjemand eingetippt hat, weil es keine Liste von Postfächern gibt, gegen die geprüft würde — eine 5.1.1 von GrabMail ist also etwas, das es nicht gibt. Wie Temp-Mail darunter funktioniert hat den Mechanismus in voller Länge.

Ablauf ist kein Bounce

Eine Nachricht wird 5 Tage nach ihrer Ankunft gelöscht, und da wurde dem sendenden Server längst 250 gesagt, und er hat den ganzen Austausch vergessen. Niemand wird benachrichtigt, weil nichts fehlgeschlagen ist: Sie wurde zugestellt, und später gelöscht. Wie lange ein Postfach besteht ist die Anleitung für diese Hälfte.

Ein Formular, das die Adresse ablehnt, ist kein Bounce

Es wurde überhaupt keine Mail verschickt. Die Website hat die Domain mit einer Liste abgeglichen und das Formular abgelehnt; nichts hat je einen Mailserver erreicht, und es gibt nichts zu lesen. Warum Anmeldeformulare Wegwerf-E-Mail blockieren ist ein anderes Problem mit einem anderen Satz Antworten.

Stille ist ebenfalls kein Bounce

Ist etwas, das Sie erwartet haben, nie angekommen, und hat Ihnen niemand einen Bericht geschickt, geschah der Fehlschlag — falls es einen gab — auf der sendenden Seite, wo Sie ihn nicht sehen können. Mail, die nicht ankommt geht die Ursachen in der Reihenfolge durch, in der sich das Prüfen lohnt.

Damit bleibt genau eine echte Ablehnung übrig, und das ist die Größengrenze. Ein sendender Server, der die Größe vorab ankündigt, wird sofort abgewiesen, bevor auch nur ein Byte gespeichert wird:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Ein Absender, der die Größe nicht vorab ankündigt, bekommt stattdessen dieselbe Antwort am Ende der Nachricht, sobald die Bytes für ihn gezählt wurden. So oder so lautet der Code 5.3.4, nichts wird gespeichert, und eine echte Person wird von ihrem eigenen Mailsystem informiert — was der ganze Grund dafür ist, an der Tür abzuweisen statt anzunehmen und zu verwerfen.

Es gibt weder einen Tarif noch einen Header, der die Grenze anhebt, und keinen Bounce für sonst irgendetwas hier: kein Kontingent für eingehende Mail, kein Ratenlimit, keine Ablehnung, weil jemand den Namen schon verwendet. Auf einer gemeinsam genutzten Domain teilen sich zwei Personen, die denselben Namen eintippen, einfach das Postfach — eine Eigenschaft der Privatsphäre, keine der Zustellung.

Bounces auf einer Domain, die gerade erst hierher zeigt

Eine Domain auf ein Catch-all-Postfach zeigen zu lassen, ist ein einziger DNS-Eintrag, und fast jeder Bounce, den das erzeugt, gehört zur Stunde rund um die Änderung und nicht zum Setup selbst. Es gibt fünf Fälle, und sie sehen unterschiedlich aus:

1. Bevor der Eintrag existiert. Eine Domain ohne MX und ohne Adress-Eintrag als Rückfalloption gibt Absendern 5.4.4 oder 5.1.2: Es gibt nirgendwo zuzustellen und nichts, das einen erneuten Versuch lohnt.
2. Während die Änderung sich verbreitet. Absender, die den Eintrag schon abgefragt hatten, behalten die alte Antwort, bis deren TTL abläuft. Ein Bounce in diesem Fenster nennt den alten Host auf der Zeile Remote-MTA: — genau daran erkennen Sie den Unterschied zu einem falsch gesetzten Eintrag.
3. Sobald sie sich verbreitet hat. Jeder Name auf der Domain wird angenommen, „unbekannter Empfänger“ wird also auch dort unmöglich. Ein Eintrag, Priorität 10, zeigt auf smtp.grabmail.io, und es muss nichts weiter veröffentlicht werden, damit Mail ankommt.
4. Wenn die Domain früher einen Null-MX veröffentlicht hat. Geparkte Domains tragen oft den Eintrag, der bedeutet: „Diese Domain empfängt nie Mail“. Absender, die ihn zwischengespeichert haben, antworten mit 5.1.10, bis er abläuft — ganz gleich, was Sie seither veröffentlicht haben.
5. Wenn die Domain auch Mail versendet. Eine 5.7.26 bei ausgehender Mail hat mit alldem nichts zu tun — dann deckt Ihr eigenes SPF oder DMARC nicht ab, was auch immer die Nachricht verschickt hat. Die Anleitung für reine Empfangsdomains ist der strenge Fall; eine Domain, die auch versendet, braucht stattdessen die gewöhnliche stufenweise Einführung.

Den Eintrag abzufragen beantwortet das meiste davon, bevor überhaupt jemand einen Bounce lesen muss:

$ dig +short MX yourdomain.com

Die Antwort sollte eine Zeile sein: die Priorität, dann der Host, dann ein abschließender Punkt. Alles andere — zwei Zeilen, ein unbekannter Host, gar nichts — ist der Bounce, den Sie gleich bekommen, nur drei Minuten früher. Die eigene Domain hierher zeigen lassen ist das gesamte Setup, und die drei Einträge, die Spoofing stoppen ist, was Sie veröffentlichen, sobald Mail ankommt.

Ein Bounce für eine Nachricht, die Sie nie verschickt haben

Er kommt an und sieht genau aus wie ein gewöhnlicher Fehlerbericht, zitiert eine Nachricht, die Sie nie gesehen haben, an einen Empfänger, von dem Sie nie gehört haben. Es wurde nirgendwo eingebrochen. Jemand hat Mail verschickt, mit Ihrer Adresse als Absender in den Umschlag geschrieben, ein empfangender Server hat sie angenommen, bevor er entdeckte, dass er sie nicht zustellen konnte, und hat dann das Richtige mit einer fehlgeschlagenen Nachricht getan: einen Bericht geschrieben und ihn an den Absender geschickt, der ihm gegeben wurde. Und das sind Sie.

Der Fachbegriff dafür ist Backscatter, und was er beweist, ist es wert, klar ausgesprochen zu werden: nichts über Ihr Postfach. Einen Envelope-Absender zu fälschen braucht keinerlei Zugriff auf irgendetwas — es ist eine Zeile, in eine Konversation eingetippt. Wer auch immer es getan hat, brauchte nur Ihre Adresse und sonst nichts, und hat sie sich womöglich einfach nur erraten.

Drei Dinge unterscheiden es in etwa zehn Sekunden von einem echten Bounce:

• Die zurückgegebene Nachricht stammt nicht von Ihnen. Der dritte Teil des Berichts trägt das Original, oder zumindest dessen Header. Haben Sie sie nie geschrieben, haben Sie sie nicht verschickt, und alles andere im Bericht betrifft das Problem von jemand anderem.
• Die Received:-Kette beginnt irgendwo, das Sie nie verwendet haben. Lesen Sie sie von unten nach oben: Die unterste Zeile ist die Maschine, die die Nachricht tatsächlich eingespeist hat, und das wird nicht Ihr Anbieter sein. E-Mail-Header lesen behandelt die Richtung und warum unten das ehrliche Ende ist.
• Die Daten passen nicht zusammen. Backscatter meldet meist eine Nachricht, die Stunden oder Tage vor dem Eintreffen des Berichts verschickt wurde, aus einer Warteschlange, die seitdem die Kampagne von jemand anderem erneut versucht.

Es gibt nichts zu reparieren und nichts zu beantworten. Gehört die Adresse zu einer Domain, die Ihnen gehört, verringert das Veröffentlichen von SPF und DMARC es auf die einzige Art, die wirklich funktioniert: Ein empfangender Server, der die Richtlinie des Absenders vor der Annahme prüft, weist die Fälschung schon während der Konversation ab und erzeugt für niemanden einen Bericht. Drei Einträge auf einer reinen Empfangsdomain ist die strengste Version davon, und mit Abstand die am leichtesten zu veröffentlichende.

Ein kurzer Name auf einer gemeinsam genutzten öffentlichen Domain sammelt davon mehr als eine private Adresse, aus demselben Grund, aus dem er auch mehr Spam sammelt: Er ist erratbar, und ein Fälscher, der Envelope-Absender auswählt, zielt nicht besonders auf Sie. Es ist Lärm über jemand anderen, und anders als bei Spam gibt es keine Schaltfläche, die irgendetwas trainiert — was die Spam-Kontrollen wirklich tun ist die Anleitung für die Schaltflächen, die tatsächlich etwas bewirken.

In welcher Reihenfolge Sie einen lesen

1. Entscheiden Sie, welche Art Sie vor sich haben. Ein Fehler in Ihrer eigenen Mail-App im Moment des Sendens ist eine Ablehnung. Eine Nachricht von MAILER-DAEMON, die danach ankam, ist ein Bericht, und nur im Bericht steckt etwas zum Lesen.
2. Prüfen Sie, ob es um eine Nachricht geht, die Sie wirklich verschickt haben. Die zurückgegebene Kopie steckt im dritten Teil. Ist sie nicht von Ihnen, ist es Backscatter, und Sie sind fertig.
3. Öffnen Sie die Rohquelle. Die Entschuldigung ganz oben ist die Standardformulierung Ihres eigenen Servers, nicht der Grund, und der maschinenlesbare Block wird nirgendwo standardmäßig angezeigt.
4. Suchen Sie Status: und lesen Sie die erste Ziffer. Eine 4 wird noch erneut versucht und kann von selbst noch gelingen; eine 5 ist endgültig, und es passiert nichts mehr.
5. Lesen Sie Diagnostic-Code:. Das ist der eigene Satz des anderen Endes, und die einzige Stelle, an der die Regel, die Sie abgelehnt hat, tatsächlich benannt wird.
6. Ordnen Sie die zweite Ziffer ein. .1. ist die Adresse, .2. das Postfach, .4. die Route, .7. die Richtlinie von irgendjemandem. Das reicht normalerweise, um zu wissen, wessen Problem es ist.
7. Handeln Sie danach, wessen Problem es ist. Ein Adressierungsfehler wird durch die richtige Adresse behoben; ein Routingfehler durch die Reparatur des DNS; ein Richtlinienfehler durch das Erfüllen der Richtlinie, oder indem Sie die Person auf der anderen Seite bitten, in die eigenen Logs zu schauen — wo dieselbe Ablehnung sehr viel ausführlicher steht, als man sie Ihnen geschickt hat.

Zwei Dinge sind nie die Antwort. Die Nachricht nach einer 5 unverändert erneut zu senden, wiederholt dieselbe Ablehnung und schadet, oft genug getan, dem Ruf der Versanddomain überall gleichzeitig. Und auf den Bericht zu antworten erreicht niemanden: Er kam von einem leeren Envelope-Absender, was der eigentliche Grund dafür ist, dass er überhaupt an Sie zugestellt werden konnte.

Fragen