# Email Bounce Rate Calculator and Segment Analyzer > Calculate hard, soft, unclassified, and total email bounce rates from an explicit attempted-recipient denominator. Compare weighted segments, inspect a 95% Wilson interval, apply editable house thresholds, project a future send, and export the evidence without treating acceptance as inbox placement. - **Canonical page:** [https://emailbump.com/tools/email-bounce-rate-calculator](https://emailbump.com/tools/email-bounce-rate-calculator) - **Interactive tool:** [Open the bounce rate calculator](https://emailbump.com/tools/email-bounce-rate-calculator) - **Category:** Email measurement and deliverability operations - **Standards:** [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463.html), [RFC 3464](https://www.rfc-editor.org/rfc/rfc3464.html) - **Updated:** July 2026 - **Privacy:** All counts, calculations, comparisons, and exports stay in the browser - **Network boundary:** The calculator does not contact recipients, mailbox providers, or sending platforms ## What this tool is for An aggregate bounce percentage answers a narrow question: how many reported failure events occurred relative to the attempted recipient deliveries in the same reporting scope? That question is useful only when its accounting rules remain visible. Two percentages that are both called “bounce rate” may not be comparable if one uses messages while another uses recipients, one counts only terminal events while another counts every temporary deferral, or one includes retries that the other deduplicates. The interactive tool therefore starts with a delivery ledger rather than a single percentage field. Each row represents a segment such as: - A message stream - A campaign - A mailbox provider or receiver domain - An acquisition cohort - A sending domain - An IP pool - A region - A product workflow For every segment, the operator enters attempted recipients, hard bounces, soft bounces, and unclassified bounces. The calculator validates the ledger, computes the weighted aggregate, shows each segment's contribution to total bounces, and preserves counts next to rates. The calculator does not claim that one universal percentage is “good.” Its total-rate and hard-rate ceilings are editable house decision rules. They are operator inputs, not facts about every sender, stream, provider, or account. ## Core formula The total bounce rate is: ```text total bounce rate = (hard bounces + soft bounces + unclassified bounces) / attempted recipient deliveries × 100 ``` Category rates use the same denominator: ```text hard bounce rate = hard bounces / attempted recipients × 100 soft bounce rate = soft bounces / attempted recipients × 100 unclassified rate = unclassified bounces / attempted recipients × 100 ``` Using one common denominator makes the category rates additive: ```text total rate = hard rate + soft rate + unclassified rate ``` The accepted remainder is: ```text accepted remainder = attempted recipients - hard bounces - soft bounces - unclassified bounces ``` “Accepted remainder” is deliberately cautious language. It describes attempts that were not entered as terminal bounce events in the supplied ledger. It is not evidence that a message reached the inbox, appeared in a particular tab, avoided the spam folder, rendered correctly, or was seen by a person. ## Define the attempted-recipient denominator The denominator should count recipient delivery attempts that belong to the same scope as the supplied bounce events. Record the definition with every report. A useful scope statement includes: - Start and end timestamps, including timezone - Included message streams and campaigns - Included sending domains and infrastructure - Whether the unit is recipient delivery, message, or API request - Treatment of multi-recipient SMTP transactions - Treatment of provider retries - The event key used for deduplication - The point at which a temporary failure becomes a terminal bounce - Whether pre-send validation failures are included - Whether suppressed recipients are excluded before the attempted count For most operational email reporting, recipient delivery is the clearest unit. One API request addressed to five recipients represents five recipient outcomes, not one. An SMTP transaction that temporarily defers and is retried several times should not automatically become several bounces. Count the terminal recipient outcome according to a documented event model. Do not use contacts, audience size, opens, clicks, accepted messages, or successful deliveries as the denominator unless the metric is intentionally defined as something other than bounce rate. ## Align numerator and denominator The numerator and denominator must describe the same population. A few common accounting failures are: 1. Counting attempts at API acceptance but bounces only after the sending system's suppression rules 2. Combining campaign attempts from one timezone with bounce events from another 3. Counting every transient SMTP reply as a bounce while counting the recipient once in the denominator 4. Counting the final hard failure after retry and also retaining its earlier temporary failures 5. Including provider-side pre-send rejections in the numerator but not the denominator 6. Combining unique recipients in the denominator with per-message failures in the numerator 7. Removing retry successes from the denominator while retaining the earlier deferral as a failure A practical deduplication key often combines a stable message identifier, recipient identifier, and delivery attempt or terminal-outcome identifier. The exact design depends on the sender, but the report should make it possible to reconstruct why each event was counted. ## Hard, soft, and unclassified are operational mappings RFC 3463 defines the first digit of an enhanced mail system status code: - `2.x.x` indicates success - `4.x.x` indicates persistent transient failure - `5.x.x` indicates permanent failure Many providers map `4.x.x` outcomes to “soft bounce” and `5.x.x` outcomes to “hard bounce.” Those labels are useful operational shorthand, but the enhanced code and raw SMTP response carry more information than the label alone. The second and third digits describe a subject and detail. Subject families include addressing, mailbox status, mail-system status, network and routing, protocol, message content or media, and security or policy. A permanent `5.1.x` address failure and a permanent `5.7.x` policy failure are both permanent-class outcomes, but they should not necessarily trigger the same action. For example: - A confirmed nonexistent recipient may justify recipient suppression. - A sender-authentication policy rejection may require DKIM, SPF, DMARC, alignment, or reputation work. - A message-content rejection may require template or link investigation. - A temporary receiver-capacity failure may justify bounded retry and receiver-level monitoring. - A temporary sender-rate limit may require traffic shaping rather than any change to the recipient record. Do not convert every `5xx` response into “invalid address, suppress forever.” The SMTP reply class, enhanced status code, remote host, sender context, and retry history should travel together. ## Why preserve an unclassified category An unknown event is evidence of a mapping gap. Forcing it into hard or soft makes the percentage look complete while reducing operational accuracy. Keep an event unclassified when: - The provider webhook does not expose enough detail - The enhanced status code is missing or malformed - The provider label conflicts with the raw reply - A local mapping table does not recognize the response - The failure occurred outside the normal SMTP delivery path - Several outcomes were collapsed into an ambiguous summary Track the unclassified rate and its share of all failures. A rising unknown share should trigger event-pipeline work before it triggers broad recipient suppression or retry changes. Useful raw evidence fields include: - Provider event type and event version - SMTP reply code - Enhanced status code - Complete diagnostic response - Remote receiving host - Recipient domain - Message stream - Sending domain - Sending IP or pool - Message identifier - Recipient identifier or privacy-safe surrogate - First-attempt timestamp - Final-attempt timestamp - Retry count - Final disposition - Mapping-rule version ## Weighted segment totals The overall rate is calculated from summed counts, not by averaging segment percentages: ```text weighted total rate = sum(segment bounces) / sum(segment attempted recipients) × 100 ``` Suppose one segment has 100 bounces from 10,000 attempts, a 1% rate, and another has 10 bounces from 100 attempts, a 10% rate. A simple average of the two rates is 5.5%, which does not describe the combined population. The weighted aggregate is: ```text (100 + 10) / (10,000 + 100) × 100 = 1.089% ``` The small segment still matters. Its 10% rate may indicate a serious cohort problem. But it should contribute according to its actual volume when constructing the aggregate. The tool shows two distinct quantities for every segment: - **Segment rate:** the segment's bounces divided by its attempts - **Contribution:** the segment's bounces divided by all valid bounces A large segment with a moderate rate may contribute more failure events than a tiny segment with a spectacular rate. Both views are needed for prioritization. ## Choose segments that can change a decision Segment dimensions should connect to an investigation or action. Useful cuts include: ### Message stream Separate password resets, receipts, alerts, onboarding, lifecycle marketing, newsletters, and bulk announcements. Their urgency, consent source, send pattern, retry policy, and reputation surface differ. ### Receiver or mailbox provider A receiver-specific rise can indicate throttling, a reputation event, DNS failure, provider policy, or a temporary incident. A global average can hide it. ### Acquisition cohort Separate organic product signups, imported contacts, partner sources, events, legacy lists, and recent forms. Cohort differences often reveal address-quality or consent problems. ### Sending infrastructure Compare sending domains, DKIM identities, IP pools, providers, routes, and migration phases. Keep the time of infrastructure changes in the evidence. ### Campaign or template A single content pattern, link domain, attachment type, or sender identity may attract policy rejection without affecting other traffic. ### Time Use comparable windows. Daily monitoring catches incidents, while rolling windows reduce noise. Preserve raw counts so low-volume percentages do not acquire false authority. Do not create dozens of segments only because the data permits it. Start with dimensions tied to plausible causes, then drill down from the segment that contributes the problem. ## The Wilson interval The calculator displays a two-sided 95% Wilson score interval for the observed total proportion. Wilson's method behaves better than the simple normal approximation when the event rate is near zero or the denominator is small. For observed proportion `p = x / n`, sample size `n`, and normal critical value `z`, the interval uses: ```text center = (p + z² / (2n)) / (1 + z² / n) margin = z × sqrt((p(1-p) + z² / (4n)) / n) / (1 + z² / n) interval = center ± margin ``` The page uses `z ≈ 1.96` for a nominal 95% interval. This interval is descriptive, not magical. Its usual binomial interpretation assumes trials are independent and share a common probability. Email outcomes frequently cluster by receiver, campaign, cohort, incident, and infrastructure. A provider outage can create thousands of correlated failures. Therefore: - Do not call the interval an inbox-placement forecast. - Do not interpret it as the probability that the true rate lies inside after seeing the data. - Do not let a narrow aggregate interval replace segmentation. - Do not treat repeated looks at the same stream as independent experiments. - Do report counts and collection rules beside the interval. For operational monitoring with strong clustering, time-series baselines, receiver-level control limits, and incident models may be more appropriate. ## House ceilings are not universal benchmarks The calculator begins with editable example ceilings so the interface can demonstrate a decision. Those values are not assertions about a universally safe bounce rate. A useful house rule depends on: - Stream purpose and urgency - Recipient acquisition and consent - Receiver mix - Message frequency - Address age - Retry and terminal-event policy - Provider account terms - Historical baseline - Complaint and unsubscribe context - Reputation sensitivity - The organization's risk tolerance Document who owns the rule, what scope it covers, when it was reviewed, and what action follows a breach. Consider separate rules for total rate, permanent address failures, policy failures, unclassified events, and critical streams. A threshold is a decision boundary, not a diagnosis. Crossing it says “investigate or act according to policy.” It does not say why the rate changed. ## Compare with a prior rate correctly The calculator reports both percentage-point and relative change. If the prior bounce rate is 0.50% and the current rate is 0.75%: ```text percentage-point change = 0.75% - 0.50% = +0.25 percentage points relative change = (0.75% - 0.50%) / 0.50% × 100 = +50% ``` These are different statements. Saying the rate “increased by 0.25%” is ambiguous and often mistaken. Prefer “up 0.25 percentage points” or “up 50% relative.” Only compare like with like. Keep the same: - Event definition - Denominator definition - Retry and deduplication policy - Timezone - Stream mix - Receiver mix, when possible - Provider mapping version When stream or receiver mix changes materially, compare standardized segments or report the composition shift alongside the aggregate. ## Future-send projection The tool multiplies the observed rate by an editable next-send volume: ```text projected bounces = next attempted recipients × observed bounce rate ``` It also computes the maximum whole-event count at the supplied total-rate ceiling and the arithmetic reduction needed to reach that ceiling. This is a planning translation, not a probabilistic forecast. It assumes the observed aggregate rate repeats at the next volume. That assumption can fail when: - The audience source changes - Receiver mix changes - The send is much larger - An incident resolves - A new domain, IP, or provider is introduced - Reputation changes - Retry behavior changes - Suppression improves - Message content changes Use it to communicate order of magnitude and operational capacity. Pair it with the segment plan and uncertainty rather than promising an exact event count. ## A practical investigation runbook ### 1. Verify the ledger Confirm that attempted recipients and terminal bounce events share the same time window and population. Inspect duplicates, retries, late-arriving webhooks, backfills, and provider-event version changes. ### 2. Preserve the diagnostic evidence Store raw SMTP response, enhanced status code, remote host, timestamps, retry history, message stream, sending identity, and provider mapping version. Do not keep only “hard” or “soft.” ### 3. Identify the contributing segment Sort by share of total bounces, then inspect within-segment rate. Split the leading contributor by receiver, acquisition source, status-code subject, infrastructure, or time. ### 4. Separate address failures from policy failures Within permanent-class events, distinguish recipient-address outcomes from sender, content, routing, or security-policy outcomes. This protects valid recipients from inappropriate permanent suppression. ### 5. Review transient concentration For temporary failures, plot first attempt, retry attempts, and terminal disposition over time. A spike at one receiver or one hour suggests a different response from a slow persistent rise across cohorts. ### 6. Apply the narrowest corrective action Possible actions include: - Suppress a confirmed invalid recipient - Correct a malformed address capture path - Add confirmation or validation at acquisition - Pause a problematic cohort - Repair authentication or alignment - Fix DNS or routing - Reduce or reshape receiver-specific traffic - Adjust a bounded retry schedule - Remove a content or link-domain cause - Escalate a provider incident with exact evidence ### 7. Monitor the next comparable window Record the change timestamp and owner. Confirm whether the target segment's event count, rate, and cause mix respond. Watch complaints, unsubscribes, latency, and successful outcomes for unintended effects. ## Retry policy Persistent transient failure means the message is not deliverable now, while the condition may be temporary. It does not imply infinite retry. A bounded retry policy should define: - Eligible status categories - Maximum retry age - Backoff schedule - Receiver-specific rate controls - Queue capacity - Urgency by message stream - Terminal classification - Event deduplication - Escalation conditions Password reset and security-alert usefulness may expire quickly. A slower newsletter can tolerate different timing but may not deserve prolonged pressure against a repeatedly deferring receiver. Align retry behavior with message value and receiver signals. Count a temporary failure as a terminal soft bounce according to the reporting contract. Do not count every intermediate deferral as another recipient bounce unless the metric is explicitly about SMTP attempts rather than terminal delivery outcomes. ## Suppression policy Suppression should be evidence-specific. A robust system can distinguish: - Recipient does not exist - Recipient address is malformed - Mailbox is disabled - Mailbox is full - Domain or routing failure - Sender authentication failure - Sender reputation or policy rejection - Message-content rejection - Rate limit or capacity issue - Ambiguous provider response Some evidence points to the recipient. Other evidence points to the sender, message, route, or receiver. A single global “hard bounce equals permanent recipient suppression” rule discards that distinction. Retain audit fields for the suppression reason, source event, mapping version, timestamp, scope, and reversal procedure. Suppression systems also need consistent behavior across campaign queues, transactional systems, vendors, and re-import paths. ## Example: aggregate looks healthy, cohort is not Suppose the ledger contains: - Existing subscribers: 140,000 attempts and 460 total bounces - New product signups: 48,000 attempts and 440 total bounces - Partner-import cohort: 22,000 attempts and 1,250 total bounces The combined rate is: ```text (460 + 440 + 1,250) / 210,000 × 100 = 1.024% ``` The partner cohort's rate is: ```text 1,250 / 22,000 × 100 = 5.682% ``` Its share of all bounces is: ```text 1,250 / 2,150 × 100 = 58.14% ``` An aggregate-only report loses the actionable fact: a segment representing about 10.5% of attempts contributes more than half of the failures. ## Example: temporary receiver incident Suppose Microsoft consumer recipients show a sharp increase in temporary failures while Gmail, Yahoo, and other domains remain near baseline. The first questions are not “Which addresses should be deleted?” They are: - Did the failures cluster in time? - Which remote hosts and enhanced codes appear? - Did the provider retry them, and what became terminal? - Did sending volume or connection behavior change? - Did authentication, routing, content, or IP allocation change? - Is the behavior isolated to one stream? Receiver segmentation, raw diagnostic preservation, and a bounded retry timeline make the incident legible. A single global bounce rate does not. ## Data-quality checklist Before sharing the result, verify: - [ ] Attempts and bounces cover the same time window - [ ] The unit is recipient delivery - [ ] Retries are treated consistently - [ ] Terminal outcomes are deduplicated - [ ] Late events and backfills are understood - [ ] Hard, soft, and unclassified mapping rules are versioned - [ ] Raw replies and enhanced codes remain available - [ ] Segment counts sum to the reported total - [ ] Bounces do not exceed attempts in any segment - [ ] Suppressed recipients are treated consistently - [ ] Accepted remainder is not labeled inboxed - [ ] House rules are labeled as operator inputs - [ ] Counts appear beside percentages - [ ] Comparison windows are actually comparable - [ ] Projection assumptions are stated ## Exports The interactive page provides four handoff forms. ### Copy brief A compact text summary contains the observed total, category mix, Wilson interval, house-rule state, prior comparison, future-volume translation, segment contribution, and the inbox-placement boundary. ### Copy CSV The CSV contains one row per segment with: - Segment name - Attempted count - Hard bounce count - Soft bounce count - Unclassified count - Total bounce count - Accepted remainder - Total rate - Hard rate - Share of all valid bounces - Ledger-validity flag ### Copy JSON The JSON report includes formulas, exact house-rule inputs, next-send calculations, aggregate counts, rates, Wilson intervals, segments, and findings. ### Download JSON The same structured report can be downloaded for an incident ticket, repository, dashboard fixture, or review workflow. The export is generated locally. ## What this calculator does not measure It does not measure: - Inbox placement - Spam-folder placement - Opens or human visibility - Message rendering - Authentication correctness - Reputation directly - Complaint rate - Unsubscribe rate - Consent quality - Address validity before sending - Provider account standing - Whether a suppression decision is correct - The causal effect of a remediation Use the rate as one piece of a delivery evidence system. Authentication checks, raw header inspection, enhanced-status analysis, provider reputation tools, acquisition review, complaint monitoring, and controlled change logs answer different questions. ## Frequently asked questions ### What denominator should email bounce rate use? Attempted recipient deliveries in the same reporting scope as the counted terminal bounce events. State the time window, retry policy, and deduplication rule. ### Are soft bounces always 4.x.x? Persistent transient `4.x.x` enhanced statuses are commonly mapped to soft bounces, but provider event models vary. Preserve the original enhanced code and diagnostic reply. ### Are hard bounces always invalid addresses? No. Permanent `5.x.x` failures include address, mailbox, routing, content, security, and policy subjects. Diagnose the subject and context before choosing recipient suppression. ### Should temporary SMTP deferrals count as bounces? Only according to the documented metric contract. For terminal recipient reporting, intermediate deferrals are generally part of retry history and the final disposition is counted once. ### What is a good email bounce rate? There is no context-free percentage that is authoritative for every sender. Use comparable history, stream purpose, acquisition source, receiver mix, provider rules, and explicit risk policy. The interactive tool's ceilings are editable house rules. ### Why not average segment percentages? A simple mean gives a tiny segment the same weight as a large one. Sum bounce counts and attempt counts to compute the weighted aggregate. ### Why show a confidence interval? It communicates sampling precision under a stated model and makes small-denominator uncertainty visible. It does not correct clustered delivery events or predict inbox placement. ### Does “accepted remainder” mean delivered? No. It only means those supplied attempts were not counted among the supplied terminal failures. Later filtering, spam placement, mailbox rules, rendering, and user visibility remain unknown. ### Can I paste recipient addresses into the tool? The tool needs aggregate counts only. Do not paste recipient-level personal data. Calculation and export happen locally in the browser. ## Primary sources - [RFC 3463 — Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html) - [RFC 3464 — An Extensible Message Format for Delivery Status Notifications](https://www.rfc-editor.org/rfc/rfc3464.html) ## Related tools and guidance - [SMTP bounce code decoder](https://emailbump.com/tools/bounce-code-decoder.md) - [Email header analyzer](https://emailbump.com/tools/email-header-analyzer.md) - [Email blacklist checker](https://emailbump.com/tools/email-blacklist-checker.md) - [Domain reputation guide](https://emailbump.com/blog/check-email-domain-reputation.md) - [IP reputation guide](https://emailbump.com/blog/check-sending-ip-reputation.md) - [Email bounce handling guide](https://emailbump.com/blog/email-bounce-handling-guide.md) - [Reacting to Gmail reputation-based bounces](https://emailbump.com/blog/gmail-reputation-bounces.md) - [Deliverability documentation](https://emailbump.com/docs/deliverability.md)