Not every bounce is your fault (but some absolutely are)

If you've ever looked at an email dashboard, you know the drill. One big number at the top: delivered over sent. 97-point-something percent, a little green arrow, everyone nods, meeting over.

I've spent years staring at that number, and here's my honest take: it's not wrong. It's just lazy. It blends together things that have nothing to do with each other — and worse, it makes no distinction between the failures you can fix and the failures nobody on this planet can fix.

Let me explain with a courier again. You know I like couriers.

Four kinds of "undelivered"

Imagine our courier heading out with a van full of packages. By the end of the day, some of them come back. But look closer at why they came back:

Package one was addressed to a house that doesn't exist. Never did, or was demolished years ago. The courier drove there, stared at an empty lot, shrugged, and drove back. That's your hard bounce. The address is gone, or was never real in the first place. You cannot deliver to an object that isn't there. No amount of trying harder will change that — the only thing you can do is stop putting such addresses on packages at all. Catch them at import, catch them at send time. But once the van leaves, physics wins.

Package two arrived at a real house with a real mailbox — except the mailbox was stuffed completely full. The courier couldn't squeeze one more thing in. That's your soft bounce of the capacity kind: mailbox full, over quota, bandwidth limits. I like to call it "unexisting, but temporarily." Hard, but softer. Also, notice: still nothing to do with the courier. The recipient simply needs to empty their mailbox.

Package three got rejected at the gate because of the sender's name on the label. The recipient took one look — "oh, it's from that guy" — and refused it. In email terms, this is the sender's own domain reputation failing in transit. If you're the courier company (read: the sending platform), you can advise your customer, give them tooling, teach them how to rebuild trust. But their name is their name. You can't scrub someone else's reputation for them.

Package four is the interesting one. It got rejected because of the logo on the van. Not the address, not the sender — the courier company itself has a reputation problem in this neighborhood. Too many complaints, too much junk delivered from those vans lately, so the whole street stopped accepting anything from them.

That one — the reputational bounce — is the only one that's fully, entirely on the courier. Which means it's the only one that's fully fixable by the courier.

So why do we count them all the same?

That's my problem with the single delivered/sent number. It stacks all four packages in the same "failed" pile, as if a demolished house and a trashed van reputation were the same kind of problem.

They're not. Three of the four are, to different degrees, outside the sender's infrastructure control. The fourth is the actual daily work of deliverability: monitoring, blocklistings and mitigations, killing abuse before it burns the shared reputation, working with the senders who need guidance — and saying goodbye to the ones who refuse to comply.

When you separate the buckets, two things happen. First, you finally see how the infrastructure is really doing — and in my experience, once you strip out the undeliverables, the full mailboxes and the sender-side domain issues, a well-run platform lands remarkably close to the very top of the published benchmarks. The blended number was hiding that all along.

Second, and more importantly: you know where to point your effort. A rising hard bounce rate means an import hygiene problem. Rising capacity softs are trickier: sometimes it's just people on vacation, but a steady climb is a classic symptom of a stale list — mailboxes that filled up because nobody has emptied them in months are mailboxes nobody is coming back to. Today's overquota is often tomorrow's hard bounce. Rising reputational rejections mean drop everything, something is burning.

One more layer: not all traffic is equal either

The same logic applies to the traffic itself. Mixing brand-new senders, proven long-term senders, and frankly risky traffic into one stream — and one metric — is how one bad actor ruins the neighborhood for everyone. Separating traffic into reputational pools (an entry pool, pools for proven quality, an isolation pool for the risky rest) keeps the good vans clean and puts the problem children where the mitigation work can focus on them.

Pools by traffic quality, bounces by cause and control. That's the whole idea.

To sum up

Delivered/sent is a fine headline. But if that's the only number you look at, you're grading yourself on the weather. Split your bounces by what you control, split your traffic by what it's earned — and suddenly the daily deliverability work has a fair scoreboard.

And fair scoreboards, in my experience, are the ones that make teams better.