Skip to content
Mumara

Insights

Bounces handled where they happen, not fetched later.

Mumara ONE classifies every bounce at the gateway in real time — hard bounces auto-suppress, soft bounces enter a retry window, and feedback-loop complaints flow straight into suppression. No POP/IMAP mailbox to poll, no reconciliation cron.

Get started The classification flow →
gateway · classify
Send response

250 — Delivered

recorded

5xx — Hard

auto-suppress

4xx — Soft

retry window

FBL — Complaint

→ suppression

classified at the gatewayreal-time

How it works

Classify, act, attribute.

Classified at the gateway

Bounces are classified where the message is sent, not fetched later from a mailbox. The verbatim SMTP code and category are captured the instant the receiving server responds — no POP/IMAP polling, no lag.

Acted on automatically

A permanent (hard) failure suppresses the address immediately so it's never sent to again. A temporary (soft) failure enters a retry window and escalates if it keeps failing. You don't run a cleanup job — the platform does it as events arrive.

Complaints close the loop

Feedback-loop complaints from the ISPs flow straight into suppression, so anyone who hit 'spam' stops receiving mail — protecting the reputation of every other recipient on your IPs.

Hard vs soft

Two bounces, two very different responses.

Hard (5xx). A permanent failure — the mailbox doesn't exist, the domain is gone, the message was refused on policy. Sending again only deepens the damage, so the address is suppressed immediately and won't receive future mail.

Soft (4xx). A temporary condition — mailbox full, server busy, greylisting. Mumara keeps the address in a retry window and tries again on a schedule; repeated soft failures escalate rather than silently vanishing.

The distinction matters because treating every bounce the same either over-suppresses (losing recoverable addresses) or under-suppresses (battering dead mailboxes). Real classification keeps your list clean without throwing away the temporarily unreachable.

What it replaces

The legacy bounce apparatus.

  • Polling a bounce mailbox

    The old pattern — a cron checking a POP/IMAP inbox, parsing bounce-backs, matching to sends — lags reality and drops malformed bounces. Gateway classification is instant and structured.

  • Hard and soft treated the same

    Suppressing every bounce loses recoverable addresses; suppressing none batters dead mailboxes. Real hard/soft classification does the right thing per type.

  • Complaints ignored until reputation drops

    A complaint that doesn't feed suppression is a recipient you keep annoying. FBL complaints flow into suppression automatically.

  • No idea which IP bounced

    Aggregate bounce counts hide the source. Every bounce carries its Bridge, IP, and queue, so a spike traces to where it came from.

What it handles for you

The list-hygiene work you never have to run.

  • A dead mailbox

    What happens
    A send hits an address that no longer exists (5xx).
    What the platform does
    The address is suppressed the instant the hard bounce comes back — it never gets mailed again, no cleanup job needed.

  • A full inbox

    What happens
    A mailbox is temporarily full or the server is busy (4xx).
    What the platform does
    The address enters a retry window and is re-attempted on a schedule, so a recoverable contact isn't thrown away.

  • A spam complaint

    What happens
    A recipient hits "report spam" and the ISP forwards it.
    What the platform does
    The complaint feeds straight into suppression, so you stop mailing them — protecting everyone else on your IPs.

  • A bounce spike on one IP

    What happens
    One IP starts returning a burst of bounces.
    What the platform does
    Every bounce carries its IP and Bridge, so the spike traces to its source and feeds the reputation rules that throttle it.
“Coming from a self-hosted setup, the thing I most appreciate is not running a bounce mailbox anymore. It's all classified at the gateway — hard bounces just disappear from future sends, soft ones retry, complaints suppress themselves. Our list stays clean without me ever touching a cron job.”

Verified review

Mumara ONE customer

G2

Common questions

What buyers usually ask.

How are bounces processed?

At the gateway, in real time. When the receiving server responds, Mumara classifies the result — delivered, soft bounce, hard bounce, or rejection — with the verbatim SMTP code, rather than fetching bounce-backs from a mailbox later.

What happens on a hard bounce?

The address is suppressed immediately so it never receives mail again. Hard bounces are permanent failures (missing mailbox, dead domain, policy rejection) where re-sending only harms your reputation.

What about soft bounces?

Soft (temporary) bounces enter a retry window and are re-attempted on a schedule. Repeated soft failures escalate rather than disappearing silently, so a temporarily-full mailbox isn't lost but a permanently-broken one doesn't get hammered.

How are spam complaints handled?

Feedback-loop (FBL) complaints from the ISPs flow straight into suppression, so a recipient who marked you as spam stops receiving mail — protecting the reputation of everyone else on your IPs.

How does this relate to Realtime Delivery Status?

Realtime Delivery Status is the live event stream and dashboard view of DSN events. Bounces & DSN is about what the platform does with bounce and complaint events — classification, auto-suppression, retries, and FBL handling. They share the same underlying feed.

Related

Pages that pair with this one.

Mumara ONE · Bounces & DSN

Let the platform keep your list clean.

Gateway classification, automatic hard-bounce suppression, soft-bounce retries, and FBL complaints fed into suppression — in real time, with no mailbox to poll.

Get started See pricing