A temporary hiccup is not reported as a bounce

Soft failures that the provider will retry are ignored rather than recorded as bounces, so a message that arrives ten minutes later is not permanently marked as rejected.

What it is

The event handler reads the failure severity and skips storing temporary failures entirely, acknowledging them so retries stop.

Also called: greylisting · mailbox full · false bounce · it says rejected but they got it

See it
A temporary hiccup is not reported as a bounce
Won
52%
Avg cycle
10d
Pipeline
$653k
JanSep
Two event streams: one showing a temporary failure quietly skipped then Delivered, one showing a true bounce recorded with its reason. Sample data — no customer information appears here.
How it works
  1. 1A failed event arrives with a severity.
  2. 2Temporary severity is acknowledged and ignored.
  3. 3Permanent severity is stored as a bounce with the provider's reason text.
Why we built it

The reasoning is written out: 'A temporary one — greylisting, a full mailbox, a momentarily unreachable server — is retried automatically and usually delivers minutes later. Storing it as a bounce would be wrong twice over: it is not a bounce, and bounced outranks every later stage, so the eventual delivered could never correct the record. The tenant would be told an estimate was rejected when it actually arrived.'

The problem
  • Soft failures were recorded as permanent bounces that later delivery could not correct.
Sound familiar?
What you get
Bounce status means bounced.
No wasted follow-up chasing mail that arrived.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →