Insight · DSN
DSN — Delivery Status Notifications — track each message through its lifecycle in real time: received by our server, queued, delivered, bounced, deferred, rejected. Every bounce carries the verbatim SMTP code the receiving server returned, plus the Bridge, sending node, IP, and queue that handled it.
Delivery status · live
Received by server
7:54:01accepted via marketing-bridge
In queue
7:54:01queue: gmail.com/acme-promo-3-1
Delivered to recipient
7:54:03250 2.0.0 OK
Bounced · sibling message
5.7.1smtp;550 5.7.1 Delivery not authorized — DKIM did not verify
The delivery lifecycle
A message doesn't just "send" or "fail." It moves through a sequence, and every transition is reported the instant it happens. Most platforms only surface the endpoints. ONE surfaces the whole path.
Accepted into Mumara ONE through a Bridge — the send request is in the system.
Waiting to hand off to the recipient mail server, tied to a specific domain queue.
The receiving server returned a 250 OK. The message is in the recipient mailbox.
A 5xx rejection — verbatim code (5.5.0, 5.7.1, …) plus the receiving MTA's own words.
A temporary 4xx — the receiving server asked us to retry later. ONE keeps trying.
Refused before delivery — policy, authentication, or reputation. The reason is recorded.
Bounce depth · why did it fail?
Most platforms reduce a bounce DSN to "hard" or "soft" and move on. The receiving MTA actually told you far more — a specific code and a line of text. ONE keeps it. Expand any bounced event and you see the verbatim response, the bounce category, and the full provenance: which Bridge originated the send, which sending node and IP carried it, which queue it drained through.
One off-list mailbox, you shrug. Thirty 5.7.1 "delivery not authorized" returns from one ISP through one Bridge, and you've found a DKIM/SPF break on that sending domain — which a "5.5% hard bounce" number would never have told you.
Bounce · DSN detail
soft 94.5% · hard 5.5% today
Bridge
marketing-bridge
Sending node
acme-promo-3-1
Node IP
203.0.113.10
Category
policy
Receiving MTA said
smtp;550 5.7.1 Delivery not authorized — message rejected. DKIM signature did not verify.
Three ways to consume
The same delivery-status events feed all three. The dashboard for ad-hoc investigation, webhooks for systems integration, Pushover for the alerts that can't wait for someone to be looking at a screen.
Pull
The Analytics surface — Summary, Received, Bounce, Queues, Delivery Logs. Status events appear as they arrive; expand any one for the full DSN detail. Filter, slice, and export the slice as Event JSON.
Best for: ad-hoc investigation, daily health checks.
Push · systems
Every status — received, queued, delivered, bounced, deferred, rejected — fires a webhook to your endpoint the moment it happens. Update order-status pages on delivered, sync suppression on bounced, retire the bounce-mailbox poller for good.
Best for: real-time integration, no polling.
Push · people
Define a criterion — a bounce-rate threshold trips, a specific DSN code appears, a Bridge starts getting rejected — route the webhook to the Pushover mobile app, and the alert lands on your phone instantly.
Best for: on-call, time-critical alerts.
Why push beats poll
Legacy bounce handling means polling a POP/IMAP mailbox on a timer, parsing bounce-backs, and reconciling them against your send log. It's slow, lossy, and only covers bounces.
Mumara ONE inverts it. The instant a delivery status changes — received, queued, delivered, bounced, deferred, rejected — the platform pushes it. No timer, no mailbox to parse, no reconciliation job. Your systems learn about a hard bounce the second the receiving MTA returns the code, not on the next polling cycle fifteen minutes later.
Because every status fires a webhook, you're not limited to bounce processing. Stream delivered events to flip an order-status page to 'sent.' Stream bounced events straight into your suppression workflow. Stream deferred events into an ops dashboard so you can see a receiving ISP throttling you in real time, while there's still time to react.
And for the statuses that need a human, not a system, the Pushover path closes the loop. A bounce-rate spike or a wave of authentication rejections can ping the person on call directly — phone in pocket, alert in hand — instead of sitting in a dashboard nobody's watching at the time it matters most.
What this replaces
The legacy pattern: a cron job checks a POP/IMAP inbox every few minutes, parses bounce-back messages, matches them to sends. It lags reality and drops malformed bounces. Instant DSN webhooks make the whole apparatus obsolete — the event arrives the moment it happens, fully structured.
Dashboards that bucket bounces into two categories throw away the receiving server's actual explanation. A 5.7.1 auth failure and a 5.5.0 missing-mailbox are both 'hard' — but one is a domain-config fire drill and the other is list hygiene. ONE keeps the verbatim DSN so you treat them differently.
Aggregate dashboards report account-wide bounce rate. When it jumps, you don't know where to look. Every DSN event in ONE carries the Bridge, sending node, IP, and queue that handled the message — the spike's source is one filter away, not one war-room away.
An ISP throttling your IP or rejecting your domain, discovered the next morning, is a problem you could have caught at onset. Criteria-based Pushover alerts put the signal on the responsible person's phone the moment a threshold trips — minutes matter for deliverability.
Common questions
DSN — Delivery Status Notification — is the report on where a message is in the delivery lifecycle: received by our server, queued, delivered, bounced, deferred, rejected. For bounces and rejections it includes the SMTP status code (like 5.5.0 or 5.7.1) and the verbatim text the receiving mail server returned. It's the infrastructure's account of what happened to the message — distinct from engagement, which is what the recipient does after delivery.
Delivery status (DSN) tracks the message: did it reach the recipient's mail server, and if not why. Engagement tracking (a separate Mumara ONE feature) tracks the recipient: did they open it, click it, complain. DSN answers 'did it land?'; engagement answers 'did it work?' This page covers DSN; engagement tracking has its own deep-dive.
Yes. Each status fires the moment it occurs — a delivered event when the receiving MTA returns 250 OK, a bounce event when it returns a 5xx code, a deferred event on a temporary 4xx. The live dashboard updates in real time, and webhooks fire in real time. There's no nightly batch between the SMTP conversation and the notification.
Every one. The full lifecycle — received, queued, delivered, bounced, deferred, rejected — can each fire an instant webhook to your endpoint. Point them wherever you need: a CRM, a data warehouse, an internal ops service, a serverless function. The webhook carries the same structured payload that powers the dashboard, including the SMTP code and provenance.
Pushover is a mobile push-notification app. You wire a delivery-status criterion — a bounce rate crossing a threshold, a specific DSN code, rejections from a particular Bridge or domain — through a webhook to Pushover, and matching events arrive as a push notification on your phone instantly. Same event stream as the webhooks, routed to a human instead of a system. Ideal for on-call deliverability monitoring.
A hard/soft label collapses the receiving server's explanation into one bit. The real DSN — 5.5.0 mailbox unavailable, 5.7.1 delivery not authorized, 4.2.2 mailbox full — tells you whether the problem is list hygiene, a domain-authentication break, or a temporary condition that'll clear. ONE keeps the verbatim code and text, plus the Bridge / node / IP / queue, so you diagnose the actual cause instead of guessing.
Yes — both. Every message the platform handles, whether it came from a broadcast, a drip step, a trigger, or a transactional API call through a Bridge, generates the same DSN lifecycle events. You see them together for total deliverability health and split by feed type for per-channel diagnosis.
Related
The sibling signal. DSN tracks the message; engagement tracks what the recipient did with it — opens, clicks, complaints, with bot verification.
Read moreThe bounce DSN stream is the same feed that drives auto-suppression. Hard bounces suppress automatically; the verbatim code stays visible.
Read moreEvery DSN event is attributed to the Bridge that originated the send. Filter or webhook by Bridge to isolate per-app delivery behaviour.
Read moreEvery status carries the sending node IP. Catch a per-IP reputation slip the moment the DSN codes shift, not after placement drops.
Read moreBounce and rejection DSNs feed suppression. Webhook them too, to keep your own systems in lockstep with what landed and what didn't.
Read moreWebhooks push delivery status out; the REST API lets you pull and act. Together they cover both directions of the integration loop.
Read moreMumara ONE · Realtime Delivery Status
Received, queued, delivered, bounced — every status in real time, every bounce with the verbatim SMTP code and full provenance. Watch it live, stream it via instant webhooks, or push it to your phone with Pushover.
