Why Is My Bounce Rate High? A Diagnosis Guide by Bounce Code

The campaign went out on Tuesday morning. By lunchtime the report showed 3.7% bounced, and by the afternoon your email platform had sent a polite warning about your account’s bounce rate.

The common reflex is to run the entire list through a verifier and move on. Sometimes that is exactly right. Often it fixes nothing, because a bounce rate is a symptom with at least three different causes, and only one of them lives in your list.

This guide is the diagnosis, in the order we would run it: separate the bounce types, read the actual codes, work out what pattern they form, find the segment or domain responsible, then fix the cause. The diagnosis takes an hour or two. Guessing can take weeks.

First, split hard bounces from soft bounces

A hard bounce is a permanent refusal: the receiving server answered with a 5xx code and will not accept this message, now or later. A soft bounce is a temporary one: a 4xx code that means “not right now”, and your platform will usually retry.

The split matters because the thresholds people quote apply to hard bounces. Amazon SES counts only hard bounces toward its account bounce rate, and its documentation says mailbox-full failures and bounces caused by blocked IP addresses do not count. Soft bounces only become a list problem when they repeat: Mailchimp, for instance, converts an address to a hard bounce after 7 soft bounces if the contact has never engaged, or 15 if they have.

So the first number to write down is not “3.7% bounced”. It is “X% hard, Y% soft”. A send with 0.6% hard and 3.1% soft is a very different day from one with 3.1% hard and 0.6% soft.

Read the actual bounce codes, not your platform’s summary

Every bounce carries the receiving server’s reply. On modern servers it has two parts: the basic SMTP code (550) and an enhanced status code from RFC 3463 (5.1.1). The enhanced code is the useful one. Its first digit is the class (2 success, 4 temporary, 5 permanent), and its second digit is the subject, which tells you what kind of problem it is:

Enhanced code	Subject	What it is usually about
x.1.x	Addressing	The recipient address: no such user, bad domain, bad syntax
x.2.x	Mailbox	The mailbox itself: full, disabled
x.3.x	Mail system	The receiving system: often a generic temporary error
x.4.x	Network and routing	Routing problems, loops, some directory checks
x.7.x	Security or policy	You: reputation, blocklists, authentication, content

Platforms then compress these replies into their own labels, and the labels hide what you need. Twilio SendGrid buckets every rejection into seven classifications (Invalid Address, Technical, Content, Reputation, Frequency/Volume, Mailbox Unavailable, Unclassified) and warns that the mapping changes as providers change their responses. Amazon SES gives a bounceType of Permanent, Transient or Undetermined.

The raw reply is almost always available if you look for it. In SES bounce notifications it is the diagnosticCode field. In SendGrid’s event webhook it is reason, next to status and the bounce_classification. Most marketing platforms include it in the bounce or activity export, sometimes as a “reason” or “diagnostic” column.

The diagnosis, as a flowchart

Once you have the codes, three questions get you to a cause. The threshold at the top follows our safe bounce rate guide: under 2% hard bounces per send, ideally under 1%.

Start

Hard-bounce rate above 2% on one send, or far above your normal

Question 1

Hard (5xx) or soft (4xx)?

Read the first digit of the raw SMTP reply, not your platform's label.

5xx: permanent

Question 2: which code family?

550 5.1.15.1.x550 5.4.1 (Microsoft)552 5.2.2

Bad addresses

Means: The mailbox does not exist, never did, or has been dead long enough to be refused for good.

Fix: Suppress now. Find the segment they came from (old or bought list, unverified import, a form full of typos) and verify it before the next send.

Verification fixes this

This is exactly what verification catches.

550 5.7.1554 5.7.1550 5.7.26550 5.7.515

You are blocked

Means: The receiver refused you, not the address: reputation, a blocklist listing, or failed SPF, DKIM or DMARC.

Fix: Read the text after the code. Fix authentication or get delisted. Do not delete these contacts as bad addresses.

Verification will not fix this

The addresses are probably fine. The sender is the problem.

4xx: temporary

Question 2: which code family?

452 4.2.2450 4.2.0

Mailbox full

Means: The mailbox exists but is over quota. Repeated for weeks, it usually means nobody reads it.

Fix: Let your platform retry. Suppress the address once it keeps failing across several sends.

Verification helps partly

Flagged as risky / mailbox_full, not as invalid.

421 4.7.0421 4.7.284.7.x

Throttled

Means: The provider is rate limiting you because of volume, a sudden spike, or weak reputation.

Fix: Send slower and in smaller batches. If it persists, treat it as an early version of a block.

Verification will not fix this

A reputation and volume signal, not a list one.

451 4.3.0450

Greylisting or a transient error

Means: The server asked you to try again later, often because it does not know your sending IP yet.

Fix: Usually nothing. Retries clear it. Investigate only if the same domains keep deferring for days.

Verification will not fix this

Normal mail flow, not a list problem.

Question 3

Are most of the failures at one recipient domain?

Group the failed addresses by the part after the @.

Yes, one domain or provider

• 5.1.x at one company domain: that domain changed its mail setup (migration, broken or missing MX). Check its MX records, and pause it rather than delete everyone.
• 5.7.x or 4.7.x at one mailbox provider: that provider is blocking or throttling you. Read its exact message and its postmaster guidance.

No, spread across many domains

• Mostly 5.1.x: the list is the problem. Find the segment by source, import date or signup form.
• Mostly 5.7.x: your sending setup or reputation is the problem. Check authentication and blocklists before the next send.

The rest of this post walks through each branch with the replies you will actually see.

5.1.x: the addresses are bad

550 5.1.1 is the classic hard bounce: the receiving server looked up the mailbox and it does not exist. Gmail phrases it as “The email account that you tried to reach does not exist”. Yahoo’s version reads 554 delivery error: dd This user doesn't have a yahoo.com account. Details and wording variants are on the 550 5.1.1 page.

Two codes outside the 5.1.x family mean the same thing in practice. Microsoft 365 rejects unknown recipients at its edge with 550 5.4.1 Recipient address rejected: Access denied, and Microsoft’s own documentation says it is generated because the recipient address is invalid. Gmail’s 552 5.2.2 says the inbox is out of storage space and inactive, which is a mailbox nobody reads.

When these make up most of your hard bounces, the list is the problem, and it nearly always traces back to one of four sources:

• An old segment. Addresses decay as people change jobs and providers close accounts. A segment you have not mailed in a year will bounce far more than one you mailed last month. See list decay.
• A bought, rented or scraped list. These have never been confirmed by the person, and they tend to contain old addresses and spam traps as well.
• An unverified import. A CSV from a webinar tool, an event badge scanner, a CRM migration, or a sales team’s spreadsheet that went straight into a send.
• A typo-heavy signup source. A form with no validation collects gmial.com, hotmial.com and .con addresses. Look for those domains in your bounce list, they are a reliable tell.

This is the one pattern verification fixes directly. A verifier asks the receiving server the same RCPT TO question your send did, without sending a message, and reports a mailbox that does not exist as undeliverable/ mailbox_not_found .

5.7.x and 554: you are being blocked

550 5.7.1, 554 5.7.1 and the rest of the 5.7.x family are policy rejections. The server is refusing you, not the address. The mailbox behind it may be perfectly healthy. See the 550 5.7.1 and 554 5.7.1 pages for the generic meanings.

The text after the code tells you which of three causes you are dealing with:

• Reputation. A Gmail 550 5.7.1 with “This message is likely unsolicited email” is a content or reputation judgment. Gmail’s temporary version is plainer still: 421 4.7.0 “This message is suspicious due to the very low reputation of the sending IP address”, or of the sending domain.
• A blocklist. The rejection often names the list or links to a lookup page. Our blocklist explainer covers how listings happen and how delisting works.
• Authentication. Gmail’s 550 5.7.26 reads “Unauthenticated email from domain-name is not accepted due to domain’s DMARC policy”. Outlook.com’s 550 5.7.515 reads “Access denied, sending domain … does not meet the required authentication level”, and applies to senders of 5,000 or more messages to Microsoft consumer mailboxes from the same From domain.

Authentication failures are the most common cause of a sudden spike that has nothing to do with the list. Someone adds a new sending tool that is not in your SPF record or not signing with your domain’s DKIM key, or a DNS change drops a record, and from the next send onward Gmail and Outlook refuse the mail. The requirements themselves are covered in Gmail, Yahoo and Microsoft sender requirements, and you can check your current SPF, DKIM and DMARC records in a few seconds with the email deliverability checker.

4.x.x: deferrals, throttling and full mailboxes

Soft bounces fall into three groups, and only one of them is about the recipient.

Full mailboxes. 452 4.2.2 means the mailbox exists but is over quota. Gmail’s wording is “The recipient’s inbox is out of storage space”. One occurrence is noise. The same address returning it send after send is an abandoned inbox, and your platform’s soft-to-hard conversion rules exist for exactly this case. See 452 4.2.2.

Throttling. 421 4.7.0 and Gmail’s 421 4.7.28 (“Gmail has detected an unusual rate of email”) mean the provider is slowing you down. The usual triggers are a volume spike, a new IP or domain, or a reputation that is sliding. Treat throttling as the warning that comes before a block. The 421 4.7.0 page has more detail.

Greylisting and transient errors. 451 4.3.0 is often greylisting, described in RFC 6647: the server defers mail from a sender it does not know yet and accepts the retry. Your platform’s retries handle it. It only deserves attention if the same domains keep deferring for days. See 451 4.3.0.

If most of your soft bounces are 4.7.x, read the 5.7.x section again. You are looking at the same problem, earlier.

When the failures sit on one domain

Before you blame the list, group the failed addresses by domain. A concentration on one domain changes the diagnosis completely.

One company domain, all 5.1.x. Every address at acme-logistics.com bounced as unknown, including contacts who opened last week. That is rarely 200 people leaving at once. It is usually a mail migration, a domain that stopped publishing MX records, or a directory sync problem on their side. Microsoft’s guidance for 550 5.4.1 says to check whether the error hits everyone in the recipient domain, and if so the fix sits with that domain’s admin. Run the domain through MX lookup, pause it for a week, and re-verify before deleting anyone.

One mailbox provider, mostly 5.7.x or 4.7.x. Your Gmail addresses all failed while Outlook and company domains delivered normally. That is a Gmail block or throttle aimed at you. The fix is in that provider’s requirements and postmaster data, not in your list.

Here is how the same diagnoses look in the wild, using the providers’ published messages:

Provider	Reply you see	Diagnosis
Gmail	550 5.1.1 The email account that you tried to reach does not exist	Bad address
Gmail	552 5.2.2 The recipient’s inbox is out of storage space and inactive	Dead mailbox, suppress
Gmail	550 5.7.26 Unauthenticated email … is not accepted due to domain’s DMARC policy	Authentication, fix your DNS
Gmail	421 4.7.28 Gmail has detected an unusual rate of email	Throttled, slow down
Microsoft 365	550 5.4.1 Recipient address rejected: Access denied	Bad address (or the domain’s directory, if it hits everyone there)
Outlook.com	550 5.7.515 Access denied, sending domain … does not meet the required authentication level	Authentication, fix SPF, DKIM, DMARC
Yahoo	554 delivery error: dd This user doesn't have a yahoo.com account	Bad address

How to find the segment that caused the spike

If the hard bounces are mostly 5.1.x and spread across many domains, the next question is where those contacts came from. A whole list rarely goes bad at once. One slice of it does.

Join the bounce export to your contact records and compute the bad-address rate per group. The fields worth grouping by:

• Source: the form, import, integration or list name that created the contact.
• Import date or batch: a spike that starts the week after a CSV upload usually is that CSV.
• Signup form: one form without validation can outweigh ten good ones.
• Last engagement date: contacts with no open or click in a year bounce far more than recent ones.

If your data sits in a warehouse, the query is short:

SELECT c.source,
       COUNT(*) AS sent,
       SUM(CASE WHEN b.enhanced_code LIKE '5.1.%' THEN 1 ELSE 0 END) AS bad_addresses,
       ROUND(100.0 * SUM(CASE WHEN b.enhanced_code LIKE '5.1.%' THEN 1 ELSE 0 END) / COUNT(*), 2) AS bad_pct
FROM sends s
JOIN contacts c ON c.email = s.email
LEFT JOIN bounces b ON b.send_id = s.id
WHERE s.campaign_id = 'october-newsletter'
GROUP BY c.source
ORDER BY bad_pct DESC;

In a spreadsheet, a pivot table on the same columns does the job.

What to fix today, in order

How high is too high?

Gmail and Yahoo publish no bounce-rate limit. Your sending platform does, or at least enforces one:

Amazon SES: recommended ceiling for bounce rate

2%

Amazon SES: recommended ceiling for bounce rate

Amazon SES: account placed under review

5%

Amazon SES: account placed under review

Amazon SES: sending may be paused

10%

Amazon SES: sending may be paused

Twilio SendGrid recommends generating hard bounces from fewer than 5% of attempted messages, while noting there is no exact number that causes deliverability problems. Mailchimp’s bounce warning says only that your rate has passed thresholds set by mailbox providers, and Mailchimp’s Transactional documentation gives 5% of total volume as a rule of thumb that varies by provider.

Treat those as the ceiling at which your platform intervenes, not as a target. Mailbox providers can start throttling and filtering you well before a platform suspends you. Our working target, explained in what is a safe bounce rate, is under 2% hard bounces on every send and under 1% on a list you maintain.

Stopping the next one

Most bounce spikes come from a contact that was never checked at the point it entered your system. The durable fixes are all upstream:

• Validate at capture. A form check catches typos, throwaway domains and fake signups before they become contacts. RocketShield does this with one script tag on a form.
• Verify every import before its first send. Webinar exports, event lists and CRM migrations are where most 5.1.x spikes start.
• Re-verify segments you have not mailed in a while. The longer a segment sits, the more of it decays. Our guide on how to clean an email list covers the full process.
• Watch authentication and blocklists continuously. Deliverability monitoring checks SPF, DKIM, DMARC and blocklist status on a schedule and alerts you when something changes, which is how you hear about a block before a campaign does.

For anything that bounced with a code not covered here, the bounce code reference explains each one, what causes it, and whether it is a list problem or a sender problem.