ine Zustellbestätigung (DLR) ist eine Statusmeldung, die nach dem Absenden einer SMS zurückgegeben wird und deren endgültigen Status – ZUGESTELLT, NICHT ZUGESTELLT, ABGELAUFEN, GELÖSCHT, ANGENOMMEN, UNBEKANNT oder ABGELEHNT – gemäß SMPP-Definition angibt. Eine gültige DLR stammt vom Mobilfunkanbieter des Empfängers, nicht vom Gateway. Sie informiert Sie darüber, ob das Mobiltelefon die Nachricht empfangen hat und, über das Fehlerfeld, warum dies nicht der Fall war.
Was ein Zustellbericht ist – und was er nicht ist
Sobald Sie eine Nachricht absenden, erhalten Sie zwei unterschiedliche Signale. Deren Verwechslung ist die häufigste Ursache für scheinbare Ausfälle. Das erste Signal ist die Empfangsbestätigung: Bei SMPP sendet der SMSC eine submit_sm_resp mit dem command_status ESME_ROK (0x00000000). Über eine HTTP-API erhalten Sie den Statuscode 202 und eine Nachrichten-ID. Dies bedeutet lediglich, dass die Plattform die Nachricht zur Verarbeitung angenommen hat. Das zweite Signal, das später eintrifft, ist die Zustellbestätigung – ein separater Bericht darüber, was das Netzwerk letztendlich mit der Nachricht gemacht hat. Bei SMPP wird diese als deliver_sm PDU zurückgegeben, deren esm_class sie als Empfangsbestätigung kennzeichnet. Über eine REST-API wird sie an Ihren Webhook übermittelt. Konfigurieren Sie Ihr System anhand der Zustellbestätigung (DLR), nicht anhand der Antwort auf die Übermittlung. Informationen zu den Flags für Bind und Receipt-Request finden Sie im SMPP-Entwicklerhandbuch (/developers/smpp).
Gateway-ACK versus DLR eines echten Betreibers
Nicht jede DLR (Direct Line Report) wird an derselben Stelle im Netzwerk erzeugt, und genau hier liegt die Problematik der Routenqualität. Eine echte DLR auf Betreiberebene wird vom Zielnetz generiert, nachdem das Mobiltelefon die Kurznachricht auf der SS7/MAP- oder Diameter-Schicht bestätigt hat. Der SMSC (Short Message Service Center) des Betreibers wandelt diesen Bericht der Netzwerkschicht in die SMPP-Empfangsbestätigung um, die Sie erhalten. Eine Zwischen- oder Gateway-DLR hingegen wird von einem Aggregator synthetisiert, wenn dieser die Nachricht an den nächsten Hop weiterleitet – bevor der Zielbetreiber etwas bestätigt hat. Bei einer sauberen Direktroute stimmen die beiden überein; bei einer Grauroute nicht.
Deshalb sind „gefälschte DLRs“ gefährlich. Ein Graurouten-Aggregator, der keine echte Empfangsbestätigung eines Netzbetreibers erhält, fälscht oft einen DELIVRD-Bericht beim Handoff, damit seine Dashboards einwandfrei aussehen – selbst wenn die Nachricht stillschweigend verworfen, gefiltert oder von der SIM-Box terminiert wurde. Ein Indiz dafür ist eine verdächtig hohe Zustellrate in Verbindung mit echten Nutzern, die die Nachricht nie erhalten haben, oder eine Route, die massenhaft UNKNOWN zurückgibt (das SMSC hat keinen gültigen Status, da ein nachgelagerter Hop keinen gültigen Bericht zurückgegeben hat). Fügen Sie eine beliebige Empfangsbestätigungszeichenfolge in den DLR-Decoder ein, um genau zu sehen, was eine Route behauptet und wie eine echte Empfangsbestätigung eines Netzbetreibers aussieht.
Wie DLRs zu Ihnen zurückfließen
Es gibt zwei Transportprotokolle und eine zugrundeliegende Quelle. Über SMPP wird die Empfangsbestätigung asynchron als deliver_sm PDU in Ihrer gebundenen Sitzung zurückgegeben. Der endgültige Status wird im Nachrichtentext (der klassischen Zeichenkette id:… stat:… err:…) und – in Version 5.0 und vielen Implementierungen von Version 3.4 – in den TLVs message_state und network_error_code übertragen. Über eine HTTP-API werden dieselben Informationen per POST an einen von Ihnen registrierten Webhook gesendet, üblicherweise als JSON. Beide basieren letztendlich auf dem Statusbericht des Netzwerks: 3GPP TS 23.040 definiert den SMS-STATUS-REPORT und sein Feld TP-Status, das vom terminierenden SMSC in den von Ihnen gelesenen SMPP-Nachrichtenstatus übersetzt wird. Die SMPP-Schicht ist ein zuverlässiger Träger für einen Bericht, der im Mobilfunknetz selbst erstellt wird.
Unabhängig vom Transportmittel sollten für jeden Beleg die gleichen Felder protokolliert werden, damit die Diagnose anhand von Mustern und nicht anhand von Anekdoten gestellt werden kann:
- Die Nachrichten-ID, damit Sie den DLR mit dem ursprünglichen submit_sm verknüpfen können.
- Der stat-Wert (der endgültige Nachrichtenstatus) und der err-Wert (der Netzwerk-/Betreiberfehlercode).
- Der Zielbetreiber (MCC/MNC), die Absender-ID und die verwendete Route oder Bindung.
- Die Zeitstempel für das Absendedatum und das Fertigstellungsdatum ermöglichen es Ihnen, die End-to-End-Latenz zu messen und ABGELAUFENE Muster zu erkennen.
ID: 1a2b3c4d5e, Unterabschnitt: 001, Zustelldatum: 2608031200, Fertigstellungsdatum: 2608031201, Status: ZUGESTELLT, Fehler: 000, Text: Ihr BroadNet-CodeID: 9f8e7d6c5b, Unterabschnitt: 001, Zustelldatum: 2608031200, Fertigstellungsdatum: 2608031205, Status: NICHT ZUGESTELLT, Fehler: 062, Text: Ihr BroadNet-CodeDie Diagnose wird in zwei Feldern gespeichert. Das Feld „stat“ enthält den standardisierten endgültigen Nachrichtenstatus (siehe unten). Das Feld „err“ ist ein netz- bzw. betreiberspezifischer Code – dieselbe UNDELIV-Nachricht kann bei verschiedenen Betreibern mit unterschiedlichen Fehlerwerten eintreffen. Daher ist „err“ nur im Kontext des Zielnetzes aussagekräftig. Beachten Sie, dass sich dieser Fehlercode vom SMPP-Befehlsstatus unterscheidet, den Sie mit „submit_sm_resp“ erhalten (ESME_RINVDSTADR, ESME_RTHROTTLED usw.). Die beiden werden unterschiedlich dekodiert. Verwenden Sie die SMPP-Fehlercodesuche (siehe /tools/smpp-error-codes) für Befehlsstatuswerte und den DLR-Decoder für die Empfangsbestätigung.
Die SMPP-Nachrichtenzustände, dekodiert
SMPP definiert eine kleine, abgeschlossene Menge von Endzuständen sowie den vorübergehenden ENROUTE-Zustand, der vor dem Empfang einer Nachricht auftreten kann. Die sieben unten aufgeführten Zustände beenden den Lebenszyklus einer Nachricht. Sie enthalten die typische Ursache und die jeweils auszulösende Aktion. Betrachten Sie diese Zustände als Verteilung nach Betreiber, Absender-ID und Route: Ein einzelnes UNDELIV ist irrelevant; eine Route, bei der 40 % der Nachrichten bei einem Betreiber UNDELIV sind, deutet auf ein Routenproblem hin.
| DLR-Status (Stat.) | Was es bedeutet | Typische Ursache | Was zu tun |
|---|---|---|---|
| GELIEFERT | Der Empfang wurde auf dem Mobiltelefon bestätigt. | Die Nachricht erreichte das Gerät | Nichts – das ist Erfolg; Stichprobenabgleich mit echten Nutzerberichten, um gefälschte DELIVRDs aufzudecken. |
| AKZEPTIERT | Im Namen des Abonnenten akzeptiert (z. B. vom Kundendienst gelesen) | Der Bediener hat die Nachricht ohne tatsächliche Bestätigung am Empfang als angenommen markiert. | Als Teilerfolg behandeln; jede Route untersuchen, die massenhaft ACCEPTD zurückgibt – dies verschleiert oft eine Nichtzustellung. |
| ABGELAUFEN | Die Gültigkeitsdauer ist vor der Lieferung abgelaufen. | Mobilteil ausgeschaltet oder außerhalb der Netzabdeckung für das gesamte Zeitfenster, oder SMSC-Wiederholungsversuche erschöpft | Versuchen Sie es später erneut oder nutzen Sie einen anderen Kanal; prüfen Sie, ob Ihre Gültigkeitsdauer nicht zu kurz ist. |
| GELÖSCHT | Nachricht vor Zustellung im SMSC entfernt. | Manuelle/administrative Löschung oder Entfernung aus dem Spamfilter | Prüfen Sie die Inhaltsfilterung des Betreibers und Ihre Absender-ID-/Inhaltsrichtlinie. |
| UNDELIV | Die Nachricht konnte nicht zugestellt werden. | Ungültige oder nicht zugewiesene MSISDN, keine Route, Ablehnung auf Netzwerkschicht oder Firewall-Blockierung | Überprüfen Sie die Rufnummer (HLR-Abfrage), anschließend die Routenqualität und die Registrierung der Absender-ID. |
| ABGELEHNT | Der Betreiber hat die Nachricht abgelehnt. | Nicht registrierte Absender-ID, Inhaltsfilter, Spam-Klassifizierung oder DND-/Zustimmungsliste | Registrieren Sie die Absender-ID, korrigieren Sie die Vorlage und bestätigen Sie die Anmeldung für das Ziel. |
| UNBEKANNT | Der SMSC hat keinen gültigen Status für die Nachricht | Ein nachfolgender Hop lieferte nie einen echten Bericht – oft ein schwarzes Loch in der Grauzone. | Hinterfrage den Weg; ein gesunder direkter Weg führt selten zurück zu UNBEKANNT |
DLRs als Signal für die Streckenqualität lesen
Sobald Sie akzeptieren, dass nur die DLR-Daten auf Betreiberebene vertrauenswürdig sind, wird der Empfangsfeed zu Ihrem besten Instrument zur Routenqualitätsanalyse – besser als jede Abdeckungskarte oder Vertriebspräsentation. Direkte Routen liefern spezifische, konsistente Fehlercodes und eine stabile Zustellrate (DELIVD). Graue Routen hingegen liefern generische Fehler, vereinzelt UNKNOWN-Einträge und eine wöchentlich schwankende Zustellrate, da Betreiber-Firewalls den Datenverkehr abfangen und der Aggregator ihn stillschweigend umleitet. Analysieren Sie die DLR-Verteilung nach Betreiber und Absender-ID im Zeitverlauf: Die Betreiber, bei denen Sie steigende UNDELIV/UNKNOWN-Werte oder verschwindende Fehlerdetails feststellen, nutzen eine sich verschlechternde Route. In regulierten GCC-Märkten – den VAE unter der TDRA, Saudi-Arabien unter der CST – bedeutet ein auf eine Absender-ID konzentrierter RELECTD-Wert fast immer eine Lücke in der Registrierung oder Vorlagengenehmigung und nicht einen Netzwerkfehler.
BroadNet liefert echte DLRs auf Betreiberebene – keine Gateway-Bestätigungen – über 1,000+ Betreiberverbindungen in 200+ Ländern. Die Felder „stat“ und „err“ werden pro Nachricht bereitgestellt, sodass die Routenqualität in Echtzeit sichtbar ist. Unterstützt wird dies durch eine Plattform-SLA von 99,99 % und direkte A2P-Routen, die seit 2003 gepflegt werden. Weitere Informationen finden Sie in der SMS-API oder im SMPP-Entwicklerhandbuch.
Häufig gestellte Fragen
Was ist eine Zustellbestätigung per SMS?
Eine Zustellbestätigung (DLR) ist ein Statusbericht, der nach dem Absenden einer SMS zurückgegeben wird und den endgültigen Status der Nachricht mitteilt – zugestellt, unzustellbar, abgelaufen, abgelehnt usw. Sie trifft nach der Empfangsbestätigung entweder als SMPP deliver_sm recycel PDU oder als HTTP-Webhook ein. Eine gültige DLR stammt vom Mobilfunkanbieter des Empfängers, nicht vom Gateway, und bestätigt somit, ob das Endgerät die Nachricht tatsächlich empfangen hat.
Was bedeutet DLR?
DLR steht für Zustellbestätigung (manchmal auch „Zustellbericht“). Im SMPP-System ist dies der Nachrichtenstatusbericht, den der SMSC für eine gesendete Nachricht zurückgibt. Er enthält ein Statusfeld (DELIVRD, UNDELIV, EXPIRED, DELETED, ACCEPTD, UNKNOWN, REJECTD) und einen betreiberspezifischen Fehlercode. DLR ist der Unterschied zwischen der Information, dass eine Nachricht zur Verarbeitung angenommen wurde, und der Information, dass sie tatsächlich an ein Endgerät zugestellt wurde.
Warum wird bei meiner SMS „UNDELIV / REJECTD“ angezeigt?
UNDELIV bedeutet in der Regel, dass die Nachricht das Endgerät nicht erreichen konnte – beispielsweise aufgrund einer ungültigen oder nicht zugewiesenen MSISDN, fehlender Route oder einer Blockierung durch Netzwerkschicht oder Firewall. REJECTD bedeutet, dass der Netzbetreiber die Nachricht direkt abgelehnt hat, typischerweise aufgrund einer nicht registrierten Absenderkennung, eines Treffers im Inhaltsfilter, einer Spam-Klassifizierung oder einer Sperrliste. Lesen Sie das Fehlerfeld und korrelieren Sie die Fehler nach Absenderkennung, Netzbetreiber und Route, um die tatsächliche Ursache zu ermitteln.
Worin unterscheidet sich eine Gateway-Bestätigung von einer Betreiber-DLR?
Eine Gateway-Bestätigung (submit_sm_resp mit ESME_ROK oder HTTP 202) bestätigt lediglich, dass die Plattform Ihre Nachricht zur Verarbeitung angenommen hat. Ein vom Betreiber bereitgestelltes DLR bestätigt hingegen, was das Zielnetzwerk tatsächlich mit der Nachricht gemacht hat. Aggregatoren auf Graurouten fälschen mitunter DELIVRD-Empfangsbestätigungen beim Handover. Daher ist ein vom Betreiber bereitgestelltes DLR das einzige verlässliche Signal dafür, dass das Endgerät die Nachricht empfangen hat.
Referenzen
- SMPP v3.4- und v5.0-Spezifikationen – Zustellbestätigungsformat, message_state und network_error_code: smpp.org
- 3GPP TS 23.040 — technische Realisierung des Kurznachrichtendienstes (SMS-STATUS-REPORT, TP-Status): 3gpp.org
- BroadNet-Tools — DLR-Decoder und SMPP-Fehlercode-Lookup.
- BroadNet – SMPP-Entwicklerhandbuch und SMS-API.