# Email Bounce Rate: How to Measure It and What to Fix URL: https://notificationharbor.com/journal/email-bounce-rate-measure-benchmarks-fixes Type: blog Locale: en Published: 2026-11-03 Updated: 2026-11-03 --- > Email bounce rate is bounces divided by sends, but the denominator, bounce type and stream change the answer. Here is how to measure it and what to alert on. Your email bounce rate is the share of sent messages that the receiving server refused, divided by the messages you sent. Keep hard bounces under 1% on a healthy list, treat 2% as the point where you investigate, and treat 5% as an incident. Most teams read one blended number off a dashboard and miss that the denominator, the bounce type and the time window each change the answer. The rest of this piece is about getting the number right first, then deciding what to do about it. ## The formula is simple. The denominator is where teams disagree. Bounce rate equals bounced messages divided by sent messages, times 100. Some ESPs divide by delivered messages instead, which makes the rate look larger because delivered already excludes the bounces. Check which one your provider reports before you compare it to any benchmark. Amazon SES, for example, computes its bounce rate from hard bounces only, measured against what you sent through the account. That detail matters, because a dashboard that mixes soft and hard bounces will show a higher number than the one your provider uses to judge you. Pick one definition and write it down next to the metric, in the dashboard title if you have to. We use hard bounces over sent, per sending domain, per 24 hours and per 7 days. If two people on your team quote different numbers for the same week, the denominator is the first thing to compare. ![Desk with notebook sketch of a rising line graph next to a keyboard](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/0de2bf-img1.webp) ## Hard, soft and block bounces are three different signals A hard bounce is a permanent failure. The address does not exist, the domain does not resolve, or the mailbox was closed. SMTP reports it with a 5.x.x enhanced status code, defined in [RFC 3463](https://datatracker.ietf.org/doc/html/rfc3463). A soft bounce is a transient failure: a full mailbox, a server that is down, a message that is too large. These come back as 4.x.x codes and a well-behaved sender retries them. If you want the full classification, we covered the SMTP code mapping in our earlier soft bounce vs hard bounce guide. The third category is the one dashboards hide. A block is a 5.x.x rejection that says nothing about the address and everything about you: a blocklisted IP, a failed authentication check, a content or reputation filter. Counting a block as a hard bounce makes your list look dirty when the real problem is your sending setup. Skip any report that shows a single "bounce" line. Split it into three series, or you will clean a list that was never the problem. ## What counts as a good bounce rate in 2026? There is no single published number, and that is worth knowing before you quote one. Gmail and Yahoo publish thresholds for spam complaints, not for bounces. Google asks bulk senders to keep the spam rate reported in Postmaster Tools under 0.10% and never reach 0.30%, per its [sender guidelines FAQ](https://support.google.com/a/answer/81126). For bounces, the working numbers come from ESPs and from practice. These are the thresholds we use as alert levels, not guarantees from any mailbox provider. Hard bounce rate per domain over 24 hours, and how we treat it: - **Under 0.5%:** normal for an engaged, verified list. - **0.5% to 1%:** watch, and check the sources of new addresses. - **1% to 2%:** investigate, and pause the segment with the highest rate. - **2% to 5%:** stop bulk sends from that stream and find the import or form behind it. - **Over 5%:** incident. Amazon SES puts accounts at this level under review. The last row is a documented line. In its reputation dashboard documentation, [Amazon SES states](https://docs.aws.amazon.com/ses/latest/dg/reputationdashboardmessages.html) that an account at a 5% bounce rate or higher is placed under review, and that sending might be paused if the rate stays above 10%. Other providers use different numbers and wording, so read your own contract. ## Segment first: a blended rate hides the stream that is failing An account-wide 0.8% can contain a transactional stream at 0.1% and a re-engagement import at 6%. The blend looks acceptable and the second stream is quietly damaging the sending domain. Calculate the rate per stream, per source and per recipient domain. Four cuts catch most problems: - **By stream.** Transactional, lifecycle and bulk campaigns should never share one number. - **By signup source.** Forms, API signups, CSV imports and partner lists have very different address quality. - **By recipient domain.** A spike at one provider usually means a rejection policy, not a dirty list. - **By address age.** Addresses collected more than 12 months ago bounce at a higher rate than fresh ones. This is not a reporting nicety. It is the difference between fixing a form validation bug in an hour and purging a healthy list in a panic. ![Laptop showing a terminal log stream with highlighted lines in a dim room](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/98b212-img2.webp) A fifth cut worth adding once the others are in place: by sending IP or domain. If you run a dedicated IP for transactional mail and a shared pool for campaigns, a spike on one of them tells you where to look before you open a single log line. ## Reading bounce events from your provider without losing them Every serious ESP exposes bounces as events: a webhook, a notification topic or an events API. Treat that feed as the source of truth and write it into your own store, because dashboards aggregate and lose the detail you need later. Persist these fields for each event: message id, recipient, bounce type, the enhanced status code, the diagnostic text and the timestamp. With those six you can answer almost every question that comes up in a postmortem. `{ "event": "bounce", "message_id": "msg_01H9", "recipient": "user@example.com", "bounce_type": "permanent", "status": "5.1.1", "diagnostic": "550 5.1.1 user unknown", "stream": "lifecycle", "ts": "2026-11-02T09:14:03Z" }`Make the handler idempotent, and key it on the provider event id plus the message id. Providers retry webhooks, and a duplicated hard-bounce event that increments a counter twice will distort your rate and can suppress an address that is actually fine. Postmark and Resend both separate bounce types in their events and let you pull them per message stream, which makes the stream-level split above cheap to build. ## The suppression rule that does most of the work The single highest-leverage control is automatic suppression. After one hard bounce, stop sending to that address, permanently, at the application layer rather than relying only on the provider list. Most ESPs suppress hard bounces for you. The gap appears when you switch providers, run two in parallel, or send from a system that never reads the suppression list. Your own table keyed on a normalized address closes that gap. For soft bounces, use a counter instead of a single event. Our default is to suppress after three consecutive soft bounces across at least seven days. A mailbox that has been full for a week is, for lifecycle purposes, gone. Do not delete bounced addresses from your user table. Flag them with the status code and the date. A deleted row cannot tell you that the same address bounced twice last quarter. You need the record to avoid re-importing the same address from the next CSV, which is the most common way a "cleaned" list gets dirty again. ![Blank envelopes stacked on a table with three set apart in a tray](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/dc3638-img3.webp) ## Why the rate suddenly jumps: the usual causes, ranked When the rate moves, look for the cause in this order. The first three explain most spikes. - **A new import.** A CSV from an event, a partner or an old CRM export. Check the bounce rate by source before anything else. - **A signup form without validation.** Typos like gmial.com and disposable domains. A syntax and MX check at submit time removes most of them, and a confirmation email removes the rest before they ever count as a send in a lifecycle flow. - **A sending change.** A new IP, a new domain, or a warmup that ramped too fast, which turns into blocks rather than hard bounces. - **An authentication break.** SPF, DKIM or DMARC alignment failing after a DNS change. - **A provider-side rejection policy.** One recipient domain tightened its filters. Your rate is up at that domain only. The diagnostic is the status code distribution, grouped by stream and by recipient domain over the same window as the spike. A rise in 5.1.1 (user unknown) points at the list. A rise in 5.7.x points at policy, authentication or reputation. Those need opposite fixes, which is why you store the code. ## What we would alert on Alerting on a daily average is too slow. A bad import can send 40,000 messages in an hour. Alert on a rolling window instead. - Hard bounce rate over 1% across the last 1,000 sends in any stream. - Any single recipient domain above 5% on at least 200 sends in an hour. - A 5.7.x block count that exceeds your normal baseline by a clear margin. Wire the first two to a pause on the offending stream, not to a page for a human. A human can investigate afterwards. The pause is what protects your reputation in the next ten minutes. Export the rate to the monitoring you already run, whether that is Grafana, Datadog or something homegrown, and keep the stream label on the series so the split survives the export. For reporting upward, use hard bounce rate per stream over a 7-day window, plus the count of blocks. Leave soft bounces in the engineering view, where they are useful, and out of the executive one, where they cause confusion. Never report the blended account number alone, because it moves for reasons nobody in the room can explain. If a stakeholder asks for one figure, give the transactional stream's hard bounce rate. It is the stream where a failure costs you a password reset or an invoice, and it is the cleanest read on whether your infrastructure is healthy. The next concrete step is small: pull the last 30 days of bounce events, group by stream and status code, and see which row you did not expect. ## FAQ ### What is a good email bounce rate? For hard bounces, under 1% is a reasonable ceiling for an engaged list, and under 0.5% is common for verified addresses. Gmail and Yahoo publish no official bounce threshold, so these are working alert levels rather than mailbox provider rules. ### How do you calculate email bounce rate? Divide bounced messages by messages sent, then multiply by 100. Some ESPs divide by delivered messages instead, which gives a higher number, so confirm the denominator before you compare it to a benchmark. ### What bounce rate will get my account suspended? It depends on the provider. Amazon SES places an account under review at a 5% bounce rate and might pause sending if the rate stays above 10%. Other ESPs set their own lines, so check your provider's terms. ### Do soft bounces count toward bounce rate? It depends on the provider. Some count only hard bounces, as Amazon SES does. Track soft bounces in a separate series so a temporary mailbox problem does not distort the number that decides your account standing. ### How do I lower my email bounce rate quickly? Suppress every hard-bounced address at the application layer, validate addresses at signup with a syntax and MX check, and stop sending to the import or source with the highest rate. Fixing the source beats purging the whole list. ### Is a block the same as a hard bounce? No. A block is a 5.x.x rejection caused by your IP, domain reputation or authentication, not by an invalid address. Counting it as a hard bounce makes the list look bad when the sending setup is the problem.