Understanding and Reducing Email Bounce Rates

Hard Bounces vs Soft Bounces

When an email fails to deliver, the receiving server returns a status code. These fall into two categories: hard bounces (permanent failures) and soft bounces (temporary failures). Providers track them separately, and your response to each should be different.

Hard bounces are permanent delivery failures. The most common causes: the address does not exist (user deleted or never existed), the domain does not resolve to a mail server, or the receiving server has permanently rejected your sending domain or IP. The SMTP code range is 5xx — 550 (mailbox unavailable), 551 (user not local), 553 (mailbox name not allowed). A 550 is the most common; it typically means the address is invalid or the domain has no such user.

Hard bounces must be suppressed immediately and permanently. The address will hard bounce on every subsequent send. Each repeat adds another negative signal to your sender reputation with no upside. Move every hard bounce to a suppression list that applies globally across all campaigns, not just the one where the bounce occurred.

Soft bounces are temporary failures. The address exists, but something prevented delivery at that moment: the mailbox is full (452), the receiving server is temporarily overloaded (421), or a connection timeout occurred (451). Soft bounces are less damaging because they indicate a temporary condition rather than an invalid address.

Most outreach tools retry soft bounces automatically over 24 to 72 hours. If delivery eventually succeeds, no reputation damage occurs. If an address soft bounces consistently across multiple campaigns — three or more consecutive failures on the same address — treat it as a hard bounce and suppress it. Persistent soft bouncing signals an abandoned account or a mailbox that is effectively unreachable.

What Bounce Rates Mean for Deliverability

Every provider tracks hard bounces as a percentage of messages sent and uses the number as a signal of list quality. The thresholds differ by provider but the logic is the same: a sender with a high bounce rate is emailing addresses they should not have.

Amazon SES enforces a 5% hard bounce threshold. Above that, AWS places your account under review and may suspend sending. The threshold applies at the SES account level, not per domain — a bad campaign on one domain affects your entire SES account. Bounce rate is visible in the SES console under Reputation Metrics. SES also enforces a separate 0.1% complaint rate threshold with the same enforcement consequences.

Gmail does not publish explicit bounce thresholds, but Google Postmaster Tools tracks domain reputation through a health classification: High, Medium, Low, or Bad. Consistent high bounce rates push the score toward Bad. At Low or Bad classification, Gmail routes the majority of your sends to spam regardless of content quality. Recovery from a Bad classification takes weeks of clean sending behavior.

For cold email generally: keep hard bounce rates below 2%, ideally below 1%. At 3-4%, expect noticeable deliverability degradation. Above 5%, expect problems significant enough to affect reply rates. Use the SES threshold as your operational ceiling across all providers — it is the strictest enforced limit and a safe benchmark regardless of which infrastructure you use.

How to Diagnose a Bounce Rate Problem

Start with your outreach tool's bounce report, broken down by hard versus soft. If you have access to raw SMTP error codes, read them — they tell you exactly what failed and point you toward the right fix.

550 / 550 5.1.1 — Mailbox unavailable. The address does not exist or has been deactivated. This is the most common hard bounce code and indicates an address validity problem in your list.

550 5.7.1 — Policy rejection. The receiving server rejected your message based on your sending domain or IP reputation, not because the address is invalid. A pattern of 5.7.x codes rather than 5.1.x codes means the problem is reputation, not list quality.

421 — Service temporarily unavailable. The receiving server is busy or throttling inbound connections. Soft bounce; the message will be retried automatically.

452 — Insufficient storage or mailbox full. Soft bounce, typically retried. If the same address returns 452 across multiple campaigns, suppress it.

For Amazon SES, bounce data arrives through SNS notifications if you have configured bounce handling webhooks. SES sends a JSON payload with the bounce type (Permanent or Transient), the subtype, and the affected recipients. If you are not processing these notifications, you are relying on aggregate rates to tell you something is wrong rather than seeing the per-address detail that would identify the cause.

How to Fix a High Bounce Rate

If the problem is address validity (mostly 550 5.1.x errors): verify every uncontacted address in the affected campaign before sending further. Build a global suppression list from all hard bounced addresses and confirm it applies across every campaign, not just the current one. Then investigate the data source — if a specific list segment is producing disproportionate bounces, stop using that source. High bounce rates from a particular provider or scraping method indicate a systemic data quality problem, not a one-off event.

If the problem is reputation rejection (mostly 550 5.7.x errors): stop sending from the affected domain immediately. Continuing to send while under a reputation penalty extends the damage. Check your sending domain and IP against Spamhaus, Barracuda, and SURBL. If listed, follow each blacklist's delisting process and identify what triggered the listing. Give the domain a rest period of at least two weeks before resuming cold outreach.

On re-engagement and when to abandon: do not attempt to re-engage a segment that produced the reputation problem while the domain is recovering. Re-sending to a low-quality segment during a recovery period undoes the clean sending history you are trying to rebuild. If a list segment produces bounce rates above 5% after verification and re-verification, and the data source cannot explain why, stop investing in that segment. The time cost of working around persistently bad data exceeds the value of the contacts in it.

List Verification Best Practices

Verification checks whether an address is likely to receive email. What good verification catches: DNS record validity (the domain exists and has MX records), SMTP-level mailbox confirmation (the receiving server acknowledges the address exists), known spam trap addresses, disposable email domains, and role-based addresses like info@ and support@.

What verification does not catch: addresses that are technically valid but belong to people who left a company months ago; mailboxes that are full and will soft bounce; and addresses at catch-all domains. A catch-all domain accepts all incoming mail at the server level, returning a success response to the SMTP verification check even for addresses that do not exist as individual inboxes. On a catch-all domain, verification returns valid for bad addresses because the server never issues a 550. Treat catch-all results as uncertain rather than confirmed — look for secondary signals like LinkedIn activity or a named contact on the company website before including those addresses.

Verify before every campaign, not just when building the list. Addresses decay at roughly 2-3% per month as people change jobs and domains go offline. A list built in January for a campaign running in March needs a fresh verification pass. Remove addresses marked invalid, risky, or disposable without exception — do not make case-by-case decisions for contacts that look otherwise promising. Verification flags exist because those addresses fail at higher rates, and the bounce rate cost of ignoring them is not worth any individual contact.

Verification reduces bounce rates but does not eliminate them. Even a well-verified list will produce a small number of bounces from addresses that passed verification but changed status between the check and the send. This is expected. The goal is to stay well below the 2% threshold — not right at it — so you have buffer to absorb that variance without crossing into reputation-damage territory.

How EmailQo Helps with Bounce Rates

EmailQo runs pre-send checks that include list quality validation alongside DNS and content scanning. The platform tracks bounce rates per campaign and per sending account so problems surface before they compound. If you use Amazon SES, where bounce and complaint thresholds are strictly enforced with account-level consequences, real-time monitoring helps you stay within AWS limits rather than discovering a threshold breach after the damage is done.

Related Resources

• Cold Email Bounce Rate Too High? Fix It Now
• Cold Email Deliverability Guide 2026 | Own Infrastructure Approach
• Sender Reputation Guide for Cold Email