How Norbelys tells a real reply from an out-of-office
A bounce, an auto-responder, and a real reply all land in the same inbox. Here's how Norbelys tells them apart and threads each one correctly.
By David Lara, Founder
Founder-reviewed ·How we research and correct articles
A campaign sends 400 emails overnight. By morning, 46 messages land back in the connected mailboxes. Some are people genuinely interested. Some are “I’m on leave until the 12th” auto-responders. A few are servers bouncing the message back because the address doesn’t exist anymore. One is a one-line “please remove me” that technically looks like a reply but means something closer to an unsubscribe.
Treat all 46 the same way and you’ll count auto-responders as engagement, keep emailing addresses that already bounced, and bury the three replies that actually needed a same-day response under noise. The fix isn’t a human reading all 46 before breakfast — it’s a classifier that reads every one of them first.
What actually looks like a reply and isn’t
| Message type | Counted as a reply? | Stops the sequence? | Suppressed going forward? |
|---|---|---|---|
| Hard bounce (address doesn't exist) | — | ✓ | ✓ |
| Soft bounce (mailbox full, temporary) | — | — | — |
| Auto-responder / out of office | — | — | — |
| Unsubscribe request written as a reply | — | ✓ | ✓ |
| A person writing back | ✓ | ✓ | — |
Each of those five looks similar at a glance — an email, in the inbox, apparently in response to your send. What they mean for the person on the other end, and what should happen next in your sequence, are entirely different, and getting that classification wrong in either direction has a real cost: miss a hard bounce and you keep damaging your sender reputation on a dead address; miscount an auto-responder as a reply and your analytics quietly lie to you about what’s working.
Every inbound message is classified before it reaches your inbox view — the outcome decides whether the sequence stops, the address gets suppressed, or nothing changes at all.
A concrete morning, sorted
Go back to those 46 messages. In practice, a batch that size from an overnight send typically breaks down something like this: a handful of hard and soft bounces from addresses that were never going to deliver, a larger chunk of auto-responders and out-of-office replies from people who are simply away, one or two opt-outs disguised as an ordinary reply, and a small number — often under ten — of actual people writing back.
That last group is the entire reason the campaign exists, and it’s usually the smallest one in the inbox that morning. If you’re reading every message in the order it arrived, the real replies are scattered somewhere in the middle of the noise, indistinguishable at a glance from an auto-responder until you actually open and read each one. Classifying first means the unibox shows you that small group first, already separated from everything that doesn’t need a response.
Threading: matching a reply to the send it’s answering
Classification alone doesn’t tell you which campaign, which step, or which variant a reply belongs to — and without that, a reply just shows up as an orphaned message with no context. Norbelys threads every real reply back to the specific message it’s answering, so when you open it you’re looking at the actual conversation: which sequence sent it, which step it was, and which sender’s mailbox carried it — not a bare message with no history attached.
That threading is also what makes the unibox useful instead of just a second inbox to check. A reply that’s correctly matched to its origin shows up already labeled with the context you need to act on it fast — which campaign, which contact, what the sequence was about — instead of a subject line you have to go investigate before you know whether it’s worth answering right now.
The same matching has to hold even when the setup is less simple than “one contact, one sequence.” A campaign running several variants of the same step still needs each reply matched to the specific version that produced it, not just the step in general — otherwise a variant test’s reply numbers would be meaningless. A campaign rotating across several connected mailboxes still needs a reply to land back with the sender that actually sent the original message, not a generic “somewhere in this campaign” bucket. Threading correctly means both of those keep working exactly as expected, without you having to account for the added complexity yourself.
What happens automatically, by type
A hard bounce means the address is no longer valid, permanently. The address is suppressed platform-wide — not just paused in this one sequence — because there’s no scenario where continuing to send to a dead address helps you, and every send to one is a small, cumulative hit to sender reputation across every mailbox you send from.
An auto-responder or out-of-office is logged for visibility but doesn’t touch your reply numbers and doesn’t stop the sequence. The person hasn’t actually seen or responded to your message yet — they’ve just told you they’re away — so treating that as “handled” would mean the sequence silently stops reaching someone who might still reply once they’re back.
An unsubscribe request buried in reply text — “please remove me,” “stop emailing me,” anything functionally equivalent to opting out — gets caught and treated the same way as a one-click unsubscribe: the address is suppressed and the sequence stops immediately. This matters for the same reason one-click unsubscribe compliance matters — an opt-out is an opt-out regardless of which mechanism the person used to send it.
A real reply stops the sequence — no one should keep receiving automated follow-ups once they’ve actually responded — and surfaces in the unibox, correctly threaded, ready to act on.
Why this can’t be a human-review step
The instinct, especially early on, is to review every reply yourself before deciding what happens next. That works at ten replies a week. It stops working somewhere well before a hundred, and the failure mode isn’t dramatic — it’s a real reply sitting unanswered for two days because it was buried between six auto-responders, or a sequence that keeps running against a bounced address because nobody manually caught it in time. Reply triage by hand doesn’t scale linearly with reply volume — the backlog grows faster than the time available to clear it, every time volume goes up.
It also doesn’t scale across people. A single founder reading every message can at least remember which prospects already replied last week. The moment a second person is triaging the same inbox, that memory disappears — nothing stops two teammates from independently deciding a message needs a reply, or from missing the same one because each assumed the other already read it. Classification that runs the same way regardless of who’s looking at the unibox removes that coordination gap entirely: the sequence already knows what happened, before anyone opens the message.
Automating the classification step doesn’t remove the human decision from the parts that actually need judgment — what to say back, whether this lead is worth a call. It removes the part that doesn’t: reading forty-six messages every morning just to figure out which three of them are real.
What this looks like once it’s running
In practice, the difference shows up as a much shorter list to actually look at. Instead of scanning every inbound message across every connected mailbox, the unibox surfaces only what needs a human: real replies, already threaded to context, already separated from the bounces and auto-responders that don’t need anyone’s attention. What happens in the seconds after you hit send covers the sending side of this same pipeline — this is the return path, running the same way, automatically, on every reply that comes back.
Reply detection, answered directly
Can an auto-responder accidentally get counted as a real reply?
The classifier is specifically built to separate auto-responders and out-of-office messages from person-written replies, so they're logged for visibility but excluded from reply counts and don't stop the sequence — unlike a real reply, which does both.
What happens if someone writes 'unsubscribe' inside a normal reply instead of clicking a link?
It's caught the same way a one-click unsubscribe request is: the address is suppressed platform-wide and the sequence stops immediately, regardless of which mechanism the person used to opt out.
Does a soft bounce suppress the address the way a hard bounce does?
No. A soft bounce (a full mailbox, a temporary server issue) is treated as delivery friction, not a permanent failure — the address isn't suppressed on a single soft bounce, since the same message may deliver successfully on a later attempt or step.
How does a reply end up correctly threaded instead of showing up as a stray message?
Every inbound reply is matched back to the specific send it's answering — the campaign, the step, and the sender's mailbox — so it appears in the unibox already attached to that context rather than as an unlabeled message you'd have to investigate yourself.
Get the replies that matter, without reading everything
The whole point of running outbound is the conversations it produces — which means the thing standing between you and those conversations shouldn’t be forty auto-responders and a few bounces you have to sort through by hand every morning. Reply detection and threading run automatically on every connected mailbox, on every Norbelys plan, the moment a message comes back. Start on any plan and let the classifier handle the forty-six messages so you can handle the three that actually need you.