NDR, DSN, Bounce: Unzustellbarkeitsmeldungen richtig unterscheiden

Eine Mail kommt nicht an, und im Ticket steht wahlweise «Bounce», «NDR», «Mailer-Daemon» oder «Fehlermeldung vom Server». Im Admin-Alltag werden diese Begriffe synonym verwendet, obwohl sie unterschiedliche Dinge bezeichnen: Ein Reject in der SMTP-Session ist keine Rückläufer-Mail, eine Verzögerungsmeldung ist kein Zustellfehler, und eine Lesebestätigung hat mit Unzustellbarkeit gar nichts zu tun. Wer die Begriffe sauber trennt, findet die Ursache schneller, denn jede Meldungsart sagt etwas anderes darüber aus, wo im Transportweg das Problem liegt und wer es beheben kann.

DSN: der Oberbegriff aus den RFCs

Der formale Oberbegriff heisst Delivery Status Notification (DSN), definiert in den RFCs 3461 bis 3464. Eine DSN ist eine maschinell erzeugte Mail, die den Absender über den Zustellstatus seiner Nachricht informiert. Entscheidend: Eine DSN meldet nicht nur Fehlschläge. Das Feld Action im maschinenlesbaren Teil kennt fünf Werte:

Die Unzustellbarkeitsmeldung ist also nur ein Spezialfall: eine DSN mit Action: failed. Genau diesen Spezialfall nennt Microsoft Non-Delivery Report (NDR). Der Begriff NDR stammt aus der Exchange-Welt, ist aber inzwischen herstellerübergreifend gebräuchlich. Wer präzise sein will: Jeder NDR ist eine DSN, aber nicht jede DSN ist ein NDR.

Die Verzögerungsmeldung (Action: delayed) verdient besondere Aufmerksamkeit, weil sie im Support regelmässig als Zustellfehler missverstanden wird. Ein typischer Betreff lautet «Delivery delayed» oder «Zustellung verzögert». Die Mail liegt dann noch in der Queue des sendenden Servers, der es weiter versucht, üblicherweise über ein bis zwei Tage. Erst wenn die Queue-Lebensdauer abläuft, folgt der endgültige NDR. Ein Anwender, der auf eine Verzögerungsmeldung hin die Mail erneut sendet, erzeugt Duplikate, sobald das Zielsystem wieder erreichbar ist.

Reject oder Bounce: die wichtigste Unterscheidung

Bevor die weiteren Begriffe folgen, gehört die zentrale technische Weiche erklärt, denn an ihr entscheidet sich, welcher Server eine Meldung erzeugt.

Reject (Abweisung in der Session): Der empfangende Server lehnt die Mail bereits während der SMTP-Session ab, mit einem 5xx-Antwortcode auf RCPT TO oder nach DATA. Er nimmt die Mail nie an und erzeugt selbst keine Rückmeldungs-Mail. Die Pflicht, den Absender zu informieren, liegt beim einliefernden Server: Der sendende MTA sieht die 5xx-Antwort und erzeugt daraufhin den NDR für seinen lokalen Benutzer. Der NDR, den der Anwender liest, stammt in diesem Fall vom eigenen Server, zitiert aber die Fehlermeldung der Gegenstelle.

Bounce (Annahme mit späterem Rückläufer): Der empfangende Server nimmt die Mail mit 250 OK an und stellt erst danach fest, dass er sie nicht zustellen kann, etwa weil das Postfach nicht existiert, das Kontingent voll ist oder ein nachgelagerter Server ablehnt. Jetzt trägt er die Verantwortung für die Nachricht und muss selbst eine DSN an den Absender schicken. Diese nachträgliche Rückläufer-Mail ist der Bounce im engeren Sinn.

Für die Fehlersuche ist der Unterschied unmittelbar nutzbar: Steht im NDR der eigene Server als erzeugendes System, wurde die Mail in der Session abgewiesen oder kam gar nie hinaus. Steht ein fremder Server als Absender der Meldung, hat die Gegenseite die Mail zunächst angenommen, und das Problem liegt hinter deren Annahmepunkt, für den Absender unsichtbar.

Aus dem Marketing-Umfeld stammen zwei weitere Bounce-Begriffe, die in keinem RFC stehen: Hard Bounce für endgültige Fehler (5xx, Action: failed) und Soft Bounce für temporäre (4xx, Action: delayed). Für Mailing-Plattformen ist die Unterscheidung zentral, weil Hard Bounces zur sofortigen Listenbereinigung führen sollten. Technisch sind es dieselben Mechanismen wie oben.

Die Begriffe im Überblick

So ist eine DSN aufgebaut

Standardkonforme DSNs verwenden den MIME-Typ multipart/report; report-type=delivery-status mit drei Teilen: einer menschenlesbaren Erklärung, einem maschinenlesbaren Teil vom Typ message/delivery-status und optional der Originalnachricht oder deren Headern. Der maschinenlesbare Teil ist für die Diagnose der wertvollste, weil seine Felder normiert sind:

Reporting-MTA: dns; mail01.example.net
Received-From-MTA: dns; client.example.org

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

Eine DSN wird immer mit leerem Envelope-Absender verschickt (MAIL FROM:<>). Das ist keine Nachlässigkeit, sondern Vorschrift aus RFC 5321: Der leere Absender verhindert, dass auf eine unzustellbare DSN eine weitere DSN folgt und sich zwei Server endlos Fehlermeldungen zuschicken. Daraus folgt eine Konfigurationsregel: Ein Mailsystem darf Mails mit leerem Envelope-Absender nicht pauschal ablehnen, sonst erreichen legitime Unzustellbarkeitsmeldungen die eigenen Benutzer nie.

Exchange und Exchange Online halten sich beim Format an den Standard, verpacken den Inhalt aber in eine eigene Darstellung: Der Anwender sieht eine aufbereitete Seite mit Klartext-Erklärung, darunter stehen «Generating server» (entspricht Reporting-MTA) und die Raw-Angaben. Für die Diagnose lohnt sich immer der Blick in diesen unteren, technischen Teil.

Enhanced Status Codes lesen

Im Feld Status und meist auch im Diagnostic-Code steht ein dreiteiliger Code nach RFC 3463: Klasse.Subjekt.Detail. Die Klasse nennt die Verbindlichkeit, Subjekt und Detail die Ursache:

Der klassische dreistellige SMTP-Antwortcode (etwa 550) und der Enhanced Status Code stehen oft gemeinsam in einer Zeile: 550 5.7.1 .... Der dreistellige Code steuert das Protokollverhalten des sendenden Servers, der erweiterte Code liefert die Diagnose-Aussage. Bei Widersprüchen zwischen Code und Freitext ist der Freitext der Gegenstelle häufig die genauere Quelle, denn viele Systeme setzen generische Codes und schreiben die eigentliche Ursache in den Kommentar, inklusive Referenz-IDs für den Support der Gegenseite.

Zu beachten: 5.7.x-Ablehnungen durch Reputations- und Inhaltsfilter sagen oft bewusst wenig. Wer hier nur auf den Code schaut, sucht am falschen Ort; die Blockliste oder der Filterhersteller aus dem Freitext führt schneller zum Ziel.

Backscatter: die schädliche Sorte Bounce

Backscatter entsteht, wenn ein Server Spam mit gefälschtem Absender zuerst annimmt und anschliessend einen NDR an die gefälschte Adresse schickt. Der NDR trifft damit einen Unbeteiligten, dessen Adresse der Spammer missbraucht hat. Bei grossen Spam-Wellen erhalten die Betroffenen tausende NDRs für Mails, die sie nie versandt haben, und Server, die solche NDRs in Masse erzeugen, landen selbst auf Blocklisten (etwa der Backscatterer-Liste von UCEPROTECT).

Die Abhilfe folgt direkt aus der Reject-Bounce-Unterscheidung: Alles, was ablehnbar ist, gehört in der SMTP-Session abgelehnt, nicht nach Annahme zurückgeschickt. Konkret bedeutet das Empfängervalidierung am äussersten Annahmepunkt (das Edge-Gateway kennt die gültigen Adressen, per Verzeichnisabgleich oder Recipient Callout, statt alles anzunehmen und intern scheitern zu lassen), Spam- und Malware-Ablehnung während der Session statt Quarantäne-NDRs, und der Verzicht auf NDRs für als Spam klassifizierte Nachrichten. Ein Reject erzeugt keinen Backscatter, denn bei gefälschtem Absender läuft die 5xx-Antwort beim Spammer-Server auf, der daraus keinen NDR an das Opfer baut.

Was keine Unzustellbarkeitsmeldung ist

Drei Meldungsarten landen in Tickets regelmässig im selben Topf, gehören aber nicht dazu:

MDN (Message Disposition Notification, RFC 8098): Die Lesebestätigung. Sie wird nicht vom Transportsystem erzeugt, sondern vom Mailclient des Empfängers, und meldet die Anzeige oder Löschung der Nachricht, nicht deren Zustellung. Der MIME-Typ heisst entsprechend multipart/report; report-type=disposition-notification. Eine ausbleibende Lesebestätigung sagt nichts über die Zustellung aus; die meisten Clients fragen den Benutzer oder unterdrücken MDNs ganz.

Abwesenheitsnotizen und Autoresponder (RFC 3834): Eine Abwesenheitsnotiz beweist das Gegenteil eines Zustellfehlers, denn sie setzt voraus, dass die Mail das Postfach erreicht hat. In Ticket-Schilderungen («ich bekomme eine automatische Antwort, kommt meine Mail an?») lohnt die Rückfrage, welche Meldung genau vorliegt.

Quarantäne-Benachrichtigungen: Meldungen wie der Quarantäne-Digest von Microsoft 365 oder eines Gateways informieren den Empfänger über zurückgehaltene Mails. Sie gehen an den Empfänger, nicht an den Absender, und folgen keinem DSN-Standard. Der Absender erhält in diesem Szenario oft gar nichts, was die Fälle erklärt, in denen eine Mail «ohne Fehlermeldung verschwindet».

Checkliste für die Diagnose

Liegt eine Meldung vor, klären Sie in dieser Reihenfolge:

1. Um welche Art handelt es sich: NDR (Action: failed), Verzögerung (Action: delayed), MDN, Autoresponder oder Quarantäne-Hinweis? Bei einer Verzögerungsmeldung: warten, nicht erneut senden.
2. Wer hat die Meldung erzeugt (Reporting-MTA bzw. «Generating server»)? Der eigene Server bedeutet Reject oder internen Fehler, ein fremder Server bedeutet Annahme mit späterem Fehlschlag auf der Gegenseite.
3. Was sagen Status und Diagnostic-Code? Klasse 4 gegen Klasse 5 trennt temporär von endgültig, das Subjekt (x.1 Adresse, x.2 Postfach, x.4 Netz, x.7 Richtlinie) grenzt die Ursache ein, der Freitext der Gegenstelle liefert die Details.
4. Fehlt jede Meldung, obwohl die Mail nicht ankommt: Message Tracking auf dem eigenen System prüfen und an Quarantäne oder stille Filterung auf der Gegenseite denken.

Wie sich einzelne Zustellwege danach gezielt nachstellen lassen, zeigen die Beiträge zum Message Tracking und zur SMTP-Diagnose im Befehls-Generator sowie der Mail-Header-Analyzer für die Auswertung des Transportwegs einer angekommenen Mail.