How to Calculate Email Bounce Rate From Your Own Send Data

Email bounce rate is the number of bounced messages divided by the number of messages you attempted to send, times 100. Send 2,000 emails, get 50 bounces, and your bounce rate is 2.5%. The arithmetic is trivial; the hard part is deciding what goes on top and bottom of that fraction, because a soft bounce that later delivered, a policy block and a dead mailbox are not the same event.

This guide is about computing the number yourself, from your own export, in a way you can trust. For what each sending platform does once you cross its line, see bounce rate limits by platform, which compares the published thresholds and why each tool reports a different figure for the same campaign.

The basic formula

Bounce rate = bounced messages / attempted messages x 100.

Sent (attempted)	Bounced	Bounce rate
500	4	0.8%
2,000	50	2.5%
10,000	310	3.1%

Three decisions sit inside that formula, and each one can move the result by a factor of several:

1. What counts as a bounce: hard only, hard plus soft, or every rejection including policy blocks.
2. What you divide by: messages attempted, messages delivered, or contacts in the campaign.
3. Over what window: one send, a sequence step, a rolling 7 or 30 days.

Write down your choices once and keep them. A bounce rate is only useful compared with itself over time, and changing the definition halfway through makes every trend line meaningless.

Choose the denominator: attempted, not delivered

Divide by the number of messages you attempted to send. That is the number the receiving servers saw, and it is the only denominator that does not move when the bounce count moves.

Dividing by delivered is a common mistake. Delivered messages are the ones that did not bounce, so the denominator shrinks as bounces grow. With 1,000 attempted and 100 bounced, attempted gives 10.0% and delivered gives 100 / 900 = 11.1%. The gap widens as things get worse, which is exactly when you need the number to be honest.

Dividing by contacts in the campaign goes the other way. If a sequence has 5,000 leads loaded but only the first 1,000 emails have gone out, 60 bounces read as 1.2% against leads and 6.0% against attempts. The mailbox providers saw 6.0%. Some cold email tools use the leads denominator in their own auto-pause logic, which is one reason a campaign can do damage before the tool reacts.

Separate bounces by what the code says

Classify each bounce by its enhanced status code, not by the word "bounced" in your dashboard. Enhanced status codes have the form class.subject.detail, and RFC 3463 defines what the first two numbers mean.

The class is the first digit. RFC 3463 defines 4.x.x as a "Persistent Transient Failure", meaning "sending in the future may be successful", and 5.x.x as a "Permanent Failure", one "not likely to be resolved by resending the message in the current form". The subject, the middle digit, says what failed: X.1.X is addressing status, X.2.X mailbox status, and X.7.X security or policy status.

That gives you a classification you can apply to any export:

Code pattern	Example	What it means	Bucket
5.1.x	550 5.1.1 user unknown	The address does not exist	Hard bounce (address)
5.2.1	Mailbox disabled	The account exists but is inactive	Hard bounce (address)
5.7.x	550 5.7.1 rejected for policy	Your mail was refused; the address may be fine	Policy block (sender)
4.x.x, later delivered	451 4.3.0, then accepted on retry	Temporary problem that resolved	Not a bounce
4.x.x, retries exhausted	Repeated deferrals until the platform gave up	Undelivered, cause unclear	Soft bounce

Two lines in that table change most people's numbers.

Policy blocks are not bad addresses. A 5.7.x rejection is permanent, so many platforms file it under "hard bounce". But the subject digit says security or policy, so the problem is your IP, domain, authentication or content. Mixing it into your address bounce rate makes your list look dirty when your setup is the issue. Track it as its own rate. A rising 5.7.x rate points to sender reputation or authentication, not to list cleaning.

A deferral that later delivered is not a bounce at all. RFC 5321 describes a 4yz reply as one where "the error condition is temporary, and the action may be requested again." If your platform retried and the message went through, count it as delivered. Only count a soft bounce when the platform stopped retrying. Our guide to handling soft bounces covers how long the main platforms keep trying.

Mailbox-full (5.2.2 or 4.2.2) sits awkwardly in between, because servers send it with both classes. Count it as a soft bounce the first time and as an address problem if it persists across sends.

Messages or unique addresses?

For list quality, count unique addresses; for reputation, count messages. They answer different questions.

If you send a three-step sequence to 1,000 people and 40 addresses are dead, a platform that keeps retrying those addresses on every step might record up to 120 bounced messages from 3,000 attempts. That is still 4.0%, but only if every step went to everyone. Most tools stop mailing an address after it hard-bounces, so step two and three bounce less, and the per-message rate falls even though the list did not improve.

So report two numbers:

• Address bounce rate: unique addresses that hard-bounced / unique addresses mailed. This tells you how clean the list was.
• Message bounce rate: bounced messages / messages attempted, in a given window. This is closer to what receiving servers experienced from you.

Break it down by receiving provider

A single overall rate can hide a problem at one provider. Group your bounces by recipient domain or, better, by MX host, since thousands of company domains route through Microsoft 365 or Google Workspace.

A 2% overall rate made up of 0.5% at Gmail and 9% at Microsoft-hosted domains is not a list problem; it is a Microsoft problem, and probably a 5.7.x one.

Spreadsheet formulas you can copy

Assume an export with one row per message, and columns Email (A), Status (B: delivered or bounced) and Code (C: the enhanced status code, such as 5.1.1).

What	Google Sheets / Excel formula
Messages attempted	=COUNTA(A2:A)
All bounces	=COUNTIF(B2:B,"bounced")
Address hard bounces (5.1.x, 5.2.1)	=COUNTIF(C2:C,"5.1.*")+COUNTIF(C2:C,"5.2.1")
Policy blocks (5.7.x)	=COUNTIF(C2:C,"5.7.*")
Soft bounces (4.x.x with status bounced)	=COUNTIFS(B2:B,"bounced",C2:C,"4.*")
Address bounce rate	=(address hard bounces)/(messages attempted) formatted as %

In Excel, use bounded ranges such as A2:A10001 instead of A2:A. If your platform only exports the raw SMTP response text, extract the enhanced code with =REGEXEXTRACT(D2,"[245]\.\d{1,3}\.\d{1,3}") in Google Sheets.

A worked example

One send to 4,000 addresses produced this:

Result	Count
Delivered on first attempt	3,770
Deferred with 4.x.x, delivered on retry	60
5.1.1 user unknown	112
5.2.1 mailbox disabled	8
5.7.1 policy rejection, all at one provider	38
Deferred until retries ran out	12

The platform dashboard said 170 bounced (all the 5.x.x plus the 12 exhausted soft bounces), or 4.25%. Broken down:

• Address hard bounce rate: (112 + 8) / 4,000 = 3.0%. That is a list problem, and a large one.
• Policy block rate: 38 / 4,000 = 0.95%, concentrated at one provider. That is a separate reputation or authentication problem.
• Soft bounce rate: 12 / 4,000 = 0.3%. Watch those 12 addresses on the next send.
• The 60 delayed messages were delivered and do not count.

Two different fixes come out of one dashboard number: clean the list, and investigate why one provider is refusing the mail.

Calculate it before you send

The cheapest bounce rate to fix is the one you predict. Verifying a list before a campaign gives you an estimate of the address hard bounce rate without sending anything: the share of addresses returned invalid is close to what would hard-bounce, and the risky or catch-all share is an uncertain extra on top. If 3% of a list comes back invalid, removing those addresses removes most of the 3.0% in the example above.

The verification cost calculator puts a number on what those bounces cost. SimpleVerifier's own plan is $29.99 a month with no per-address charge (see pricing), but the method in this guide works whichever verifier you use, and it works just as well on a raw export with no verifier at all.

The short version

1. Divide by messages attempted, never by delivered.
2. Split bounces by enhanced code: 5.1.x and 5.2.1 are address problems, 5.7.x is a sender problem, and a 4.x.x that later delivered is not a bounce.
3. Report an address rate for list quality and a message rate for reputation.
4. Break the result down by receiving provider before deciding what to fix.
5. Keep the definition fixed so the trend means something.