Email & delivery / FIELD GUIDE

What is Email bounce rate?

Email bounce rate is the share of attempted messages reported as undeliverable, calculated using a stated denominator and time window. It should distinguish temporary failures from permanent rejection.

Also known as: Bounce rate

Key takeaways

  • Email bounce rate measures failed delivery under a defined event and denominator.
  • Permanent and temporary failures need different handling and diagnosis.
  • A bounce is not always proof that the mailbox is invalid; sender policy can also cause rejection.

Overview

Providers use different reporting conventions, especially for retries and delayed failures. State whether the rate is based on messages, recipients or attempts. SMTP responses provide useful clues, but application labels such as “hard” and “soft” bounce may simplify the underlying reason. Use the actual diagnostic information when deciding whether to retry or suppress an address.

How it works

  1. Collect delivery events and associate them with the original message.

  2. Classify failures using provider diagnostics and final retry outcomes.

  3. Calculate the rate consistently and suppress or investigate affected records.

Define the event behind the rate

An email platform may count a bounce after a receiving server rejects a message or after delivery attempts are exhausted. Another report may count individual failed attempts. Those definitions produce different rates. State whether the denominator is messages attempted, recipients or final delivery outcomes, and use the same definition when comparing campaigns.

Keep email bounce rate separate from the similarly named website analytics metric. In email, the useful evidence includes the receiving response, status category and affected message. A high-level label such as soft bounce can summarize several causes, so preserve the underlying diagnostic when deciding whether to retry or suppress.

Illustrative email failure categories
Failure contextPossible interpretationNext investigation
Unknown recipient responseThe address may not be usableConfirm the status and apply address policy
Temporary capacity issueDelivery may be deferredFollow bounded provider retry behavior
Authentication or policy rejectionThe sender or message failed a ruleInspect identity, alignment and receiving response
Network or service failureDelivery status may remain unresolvedReconcile the final outcome before classifying the address

Calculate a rate that answers the right question

For an illustrative campaign with 1,000 attempted messages and 25 final bounces, the final bounce rate is 2.5%. If ten temporary deferrals later deliver successfully, those deferrals should not also be counted as final bounces under that definition. This is a calculation example, not an acceptable-rate benchmark.

Break the result down by source, list age and receiving provider. A small problematic cohort can disappear inside an overall average. Compare equivalent message types as well: a transactional stream sent to existing users has different collection and recipient context from a newly acquired prospect list.

Fix the cause before sending more

If failures concentrate in obsolete addresses, review acquisition, freshness and verification. If they concentrate at one receiver after a configuration change, inspect authentication and policy responses. Replacing every bounced address is not the right repair when the receiver rejected a valid mailbox because of the sender’s setup.

Apply suppression according to the documented failure category and keep opt-outs separate from technical failures. Do not repeatedly retry a confirmed permanent failure, and do not assume that deleting the failed contact will prevent reimport. Preserve the minimum identifiers and reasons needed for the intended exclusion and monitor whether later imports respect them.

ILLUSTRATIVE EXAMPLE

What this looks like in practice

In an illustrative batch, 20 of 1,000 messages end in permanent rejection after processing. That is a 2% permanent-failure rate for that denominator; temporary deferrals should be reported separately.

Examples explain the concept; they are not reported customer results.

What to check

Check event completeness, duplicate events, delayed bounces and retry accounting. Segment failures by domain and reason to identify the source of a problem.

Common mistake

Counting every temporary retry as a new bounced message or confusing an email bounce metric with website analytics bounce rate.

Email bounce rate vs. Sender reputation

Bounce rate is an observed delivery metric. Sender reputation is the receiving system’s broader assessment of a sender, influenced by multiple signals rather than one rate.

Read the Sender reputation definition →

Questions answered

What is Email bounce rate?

Email bounce rate is the share of attempted messages reported as undeliverable, calculated using a stated denominator and time window. It should distinguish temporary failures from permanent rejection.

Should every bounced address be deleted?

No. Permanent invalid-recipient failures generally need suppression, while temporary server conditions may warrant controlled retries. Follow the diagnostic and provider policy.

What is a universally safe bounce rate?

There is no single rate that guarantees acceptance across providers and use cases. Monitor your own baseline and address invalid data and sudden changes promptly.

What is a good email bounce rate?

Use the requirements and diagnostics of the actual sending and receiving services, together with your audience and event definition. There is no single rate that guarantees healthy delivery. Investigate changes and causes rather than treating a generic benchmark as permission to ignore a defective list or configuration.

Does a soft bounce mean the email is safe to keep sending?

Not automatically. The label can cover different temporary or policy conditions, and repeated failures may need escalation or suppression under the platform’s rules. Inspect the underlying response and final delivery state. Retry behavior should be bounded and should not ignore an unrelated opt-out.

References and further reading

Primary documentation and source material for this topic. Sources checked September 14, 2026; provider requirements can change.

  1. RFC 5321: Simple Mail Transfer ProtocolIETF / RFC Editor
  2. Email sender guidelinesGoogle

Continue reading on the blog

Explore all articles and guides →

Put the concept to work.

Explore the relevant AstroFabric workflow and see how the pieces connect.

Help keep this guide useful. Suggest a correction or browse the full glossary.