On this page
Bounce rate is an operational signal, not a universal grade. It can reveal stale contact data, a malformed address, a domain problem, a temporary receiving failure, or a change in sender readiness. The useful question is not whether one number is acceptable in the abstract. It is what changed, where the failures cluster, and whether the evidence supports continuing.
Treat bounce rate as a signal, not a score
A campaign-wide rate compresses several different events into one number. It may hide that every failure came from one source, one company domain, or one short period. It may also look severe when the sample is still too small to support a stable conclusion. Always keep the underlying events available for review.
Compare like with like. Separate newly prepared contacts from older records, hard failures from temporary failures, and one sending account from another. A useful report should let an operator trace the signal back to the contacts and campaign activity that produced it, rather than presenting a single color-coded number without context.
Separate hard and soft bounces
A hard bounce commonly indicates that the destination cannot accept the message as addressed. The address may not exist, the domain may no longer receive mail, or the receiving system may reject it permanently. Repeating the same send usually adds risk without adding information.
A soft bounce is temporary, but it still needs context. A mailbox may be full, the receiving service may be unavailable, or the sender may be deferred. Repeated temporary failures can become an operational problem even when no individual event is permanent. Preserve the response detail, limit retries, and review clusters instead of treating every soft bounce as harmless.
Investigate the pattern before sending more
Start with the smallest useful slice. Did the failures come from one recently imported group? Do they share a company domain? Were the addresses checked at the same time? Did the change begin with a new sending account or a new audience definition? The answers distinguish a contact-quality problem from a broader readiness problem.
Then inspect the source and decision trail. A contact may have passed a technical check while the person or company record was already stale. A public company page may have changed after research. A guessed address pattern may look plausible but never have represented a real inbox. Diagnosis should be allowed to remove the source, not just the failed rows.
Improve contact confidence before scheduling
Use layered email checks to improve contact confidence before a message is scheduled.
Layered checks reduce avoidable uncertainty, but timing matters. Check after the intended person and role are established, and close enough to scheduling that the result still describes the contact you plan to reach. A check attached to an old list cannot make the company context current.
Verification should also have a stop state. When the available evidence is ambiguous, the workflow needs a way to exclude the contact rather than converting uncertainty into a send. Protecting quality sometimes means accepting a smaller prepared audience.
Understand what safeguards can and cannot do
Sending controls can pause or limit activity when risk signals appear. They cannot guarantee inbox placement, preserve a domain's reputation under every condition, or make a weak audience appropriate. Those outcomes depend on systems and recipient behavior outside any one product.
Defrost has sending controls in code, but public availability depends on launch-environment and customer-specific checks. That distinction is important: an implemented safeguard should be tested in the actual operating path before customers are told to rely on it. Until then, contact preparation and outcome attribution can be discussed without representing sending as generally available.
Use a response plan before a campaign begins
Decide in advance who reviews bounce events, which patterns stop new scheduling, how contacts are excluded, and what evidence is required before activity resumes. A practical response sequence is:
- Pause the affected slice instead of continuing by default.
- Separate permanent and temporary responses.
- Trace failures to their source, account, and preparation date.
- Refresh company, role, and contact evidence where needed.
- Resume only after the cause and scope are understood.
Track delivery and response outcomes alongside the campaign activity that produced them. That connection makes a bounce useful as evidence about the workflow rather than a number noticed after damage has accumulated. It does not mean the system automatically changes future campaigns.
For the upstream causes that often appear in bounce investigations, read our guide to B2B contact data freshness. For the full public boundary around sending claims, see the Defrost standards.
Frequently asked questions
- What cold email bounce rate is too high?
- There is no universal percentage that is safe in every environment. Any unexpected rise, repeated hard bounce, or cluster tied to one source should trigger investigation before more messages are scheduled.
- What is the difference between a hard bounce and a soft bounce?
- A hard bounce usually means the address or domain cannot accept the message as addressed. A soft bounce is a temporary failure, such as a full mailbox or a transient receiving-system problem. The response code and repeated pattern matter more than the label alone.
- Can email verification prevent every bounce?
- No. Layered checks can improve contact confidence before scheduling, but mailbox state and receiving systems can change after a check. Verification is a safeguard, not a promise of delivery.
- How does Defrost use bounce information?
- Defrost can track delivery and response outcomes beside campaign activity, and sending controls exist to protect execution. Public sending availability still depends on launch-environment and account-specific verification.
