Email bounce rate

Email bounce rate: the number to watch first

Email bounce rate is the percentage of sent emails that fail to reach the recipient. If a sequence sends 1,000 emails and 40 are rejected, the email bounce rate is 4%.

That number is useful, but it doesn't tell you what to do next. A hard bounce usually means the address is dead or malformed, so you should suppress it. A soft bounce may be temporary, so you might retry once or twice. Treating both as the same event is how teams keep sending to bad records.

The mistake usually starts upstream. A sales team imports 12,000 contacts from an old event list, verifies them once, and assumes the results stay valid forever. Six months later, people have changed jobs, domains have tightened their mail rules, and the sequence keeps retrying addresses that were already failing. The campaign report calls this a delivery issue. It's really a data and process issue.

Hard bounces cost more than one failed email

A hard bounce commonly points to a nonexistent mailbox, a malformed address, or a domain that no longer accepts mail. The immediate loss is easy to understand: the email can't start a conversation.

The less obvious cost is the pattern it creates. Mailbox providers look at sending behavior over time. Repeated attempts to dead addresses can make the sending domain or mailbox look careless with its list hygiene. Turning off the campaign doesn't erase that history.

So a hard bounce should be a stop condition. Suppress the address. Check where the record came from. If the contact still matters, find a replacement address and verify that one independently. Don't simply re-add the old address because the account is still a good prospect.

A contact can remain useful for account research even after its email address becomes ineligible for sending. Those are separate decisions. Too many systems treat them as one.

Soft bounces need a rule, not optimism

A soft bounce means the receiving system rejected the message for a condition that may change. The mailbox could be full. The receiving server could be down. The message might have hit a size or policy limit.

But "temporary" doesn't always mean harmless. Some domains return temporary-looking errors for restrictions that last much longer than a normal outage. And automated sequences are very good at turning one reasonable retry into six unreasonable ones.

A practical policy might look like this:

• Hard bounce: suppress the address unless it is replaced or reverified.
• Soft bounce: pause the sequence, record the reason if available, and retry under a defined limit.
• Catch-all result: treat the address as unresolved, not verified.

One retry after a full mailbox or short server outage may make sense. Repeatedly sending to an address that has failed three times does not. At that point, the system is spending delivery volume to avoid making a decision.

Catch-all domains deserve their own caution. They accept mail for addresses that may not exist, which can make an address check look more positive than it is. If a verifier can confirm only that the domain accepts mail, the honest result is uncertainty. A green status is not proof that a person monitors the mailbox.

Most bounce problems begin before verification

Verification isn't just a check performed on a finished email address. It starts with matching the right person to the right company, finding the company's actual address convention, and deciding how much confidence the result deserves.

In Workloom's system, named people on a company record are promoted into contactable people and placed against the org chart. Addresses are derived from the company's own convention instead of applying one generic pattern to every domain. An adaptive guesser handles nicknames, around 19 address patterns, and per-domain convention learning. When a domain accepts every address, the system gives up honestly instead of treating a catch-all response as certainty.

That distinction matters in ordinary cases:

A 250-person software company acquires a smaller competitor. The sales team imports the acquired company's contacts, but several people now use the parent company's domain. The old addresses may still look valid because the domain responds to mail. A pattern-based verifier can mark them as plausible. The message still bounces because the mailbox was never migrated, or because the person left during the acquisition.

The bad record wasn't created at the point of sending. It was created when the company match, person match, or domain change was missed.

The same thing happens with titles. A contact may be a valid employee but not the person the campaign is meant to reach. "VP of Revenue," "Chief Revenue Officer," and "Head of Sales" may all be mapped differently across companies. Sending to the wrong person won't necessarily raise the bounce rate, but it wastes the same sending opportunity. Valid is not the same as relevant.

Verification goes stale

A verification result is evidence about an address at a particular time. It isn't a permanent property of the record.

Workloom keeps results fresh for 30 days and expires them at 90. That gives the sending system a way to distinguish a recent check from an old one that should no longer be trusted. People leave companies. Mailboxes get disabled. Domains change their rules. Catch-all behavior shifts.

The expiry rule only works if it reaches the campaign system. This is where teams get it wrong: the database marks an address as verified, but the sending tool has no rule that blocks expired records. The result looks current in one system and stale in the next.

A useful control is simple. Before a message is released, check whether the address is still inside its allowed verification window. If not, pause it for rechecking. Don't rely on the date the contact was imported, and don't let a "verified" field remain true forever.

Freshness also needs to follow the data path. A person who changes jobs should be rematched to the new company. A domain that changes its convention should not keep receiving guesses based on the old one. And a contact record with no recent evidence should be treated as unresolved, not quietly promoted back into an active sequence.

Use email bounce rate to find the broken step

A rising email bounce rate is a symptom. It might point to poor collection, stale verification, weak company matching, bad suppression, or an overly generous retry policy.

The aggregate number won't tell you which one. Break it down by source, domain, campaign, verification age, and bounce type. A 2% rate across the whole system can hide a 9% rate in one purchased list or one newly added domain.

Then trace failed records backward. Were they derived from a known company convention? Guessed from a nickname? Pulled from an old org chart? Sent after verification expired? Repeated after a soft bounce? Those questions usually reveal more than another dashboard chart.

My view is blunt: teams spend too much time trying to lower the reported bounce rate and not enough time stopping bad addresses from entering the send queue. Suppression and freshness rules do more than a prettier report. They keep uncertainty from becoming repeated delivery attempts, which is what eventually damages the sending identity.