Cold email bounce rate: what it means and how to fix it

Hard and soft are different problems

A hard bounce is a 5xx response: the mailbox does not exist, the domain does not accept mail, or the server has blocked you. Sending again cannot succeed, and repeating it is what damages reputation. Remove the address and, if several addresses share the domain, check whether the domain itself is the cause.

A soft bounce is a 4xx response: the mailbox is full, the server is busy, or a policy is deferring you. It may succeed later. Retrying the whole list is the wrong response, because most soft bounces are temporary for a specific recipient, not for everyone.

• 5xx: permanent, remove the address, check the domain's MX.
• 4xx: temporary, retry later, never in the same burst.
• Blocklisting responses name the sender, not the recipient; they are not list problems.
• A bounce of the whole domain means stop, not skip.

Most hard bounces are visible before you send; list verification explains how to remove them at import.

What a normal rate looks like, and why you should not chase a number

Any quoted industry average hides the only thing that matters: whether the addresses were verified and how recently. A freshly verified list and a year-old purchased list have nothing in common. Use your own trend line instead of a benchmark. If this week's rate is twice last week's on the same list, something changed.

The useful question is not what the rate is but which addresses produced it. Group bounces by domain. One broken domain can account for most of the rate and is fixed by removing that domain, not by replacing the mailbox.

• Compare the same list over time, not against an external average.
• Group bounces by recipient domain to find clusters.
• Investigate the first ten bounces of a batch; they predict the rest.

The stop rule that protects the domain

Decide in advance what would make you stop. A practical rule: if more than a small share of the first hundred messages bounce hard, pause the campaign and inspect before the next hundred. The cost of pausing for an hour is small; the cost of burning a domain is the whole quarter.

Worked example: a campaign sent 60 messages, 11 bounced with 550 responses from a single domain that had gone dark overnight. The operator paused, removed the domain, re-read the remaining addresses against the verification data and resumed. The campaign finished with no further bounces, and the sending domain kept its reputation.

Pacing decisions interact with bounce handling; daily sending limits covers the volume side.

Instrument the bounce path or you are guessing

Bounces must land somewhere you read. A bounce domain with no MX, or a return path pointing at an unmonitored mailbox, hides the data you need. Check that the bounce address resolves, that messages arrive, and that the response codes are stored per recipient.

Keep the raw SMTP response. The difference between mailbox unavailable, domain not found and blocked for policy decides whether you remove one address, one domain, or stop entirely. A dashboard that only counts bounces removes the ability to make that decision.

• Bounce mailbox receives and retains the original response code.
• Per-recipient status is stored, not just a campaign total.
• Suppression list is updated automatically for hard bounces.

Separating a list defect from a sender defect

When bounces rise, the question is whether the addresses or the sender changed. One test answers it: send a small batch to a segment verified in the last day, and compare its bounce behaviour with the suspect segment under the same sender and pacing. If the fresh segment is clean, the list is the problem. If both bounce, the sender is.

Run the test at fifty messages per segment, not five hundred. The point is to learn the cause cheaply, and fifty is enough to separate a domain-level rejection from an address-level one. Pause the main campaign while the test runs so the evidence is not mixed.

Record the result with the date and the exact SMTP codes. A month later, the same pattern is much easier to recognise, and you will not repeat a repair that was never needed.

• Fifty messages per segment, same sender and interval.
• Pause the main campaign during the test.
• Keep the codes; counts alone cannot distinguish causes.
• Record the recipient domain on every bounce, not just the address. One dead domain can explain most of a spike, and it is removed in a single action rather than as a list of fifty addresses.

Bounce response, likely cause and correct action

Codes vary by provider; the 5xx or 4xx class is the reliable part.

Frequently asked questions