Hard Bounce vs Soft Bounce: The Codes, the Rules and What ESPs Do

A hard bounce is a permanent delivery failure: the address doesn't exist, or the receiving server has refused the message for good. A soft bounce is a temporary failure: the mailbox is full, the server is busy, or delivery was deferred. Hard bounces should be suppressed after the first one. Soft bounces should be retried, and suppressed only if they keep happening.

The reliable way to tell them apart is the SMTP code in the bounce, not the label your platform puts on it. The tables below map the common codes to each type and link to our explanation of each code. You can look up any code in the SMTP code directory, which marks the common ones hard, soft or block, and if you're seeing hard bounces, the free single email verifier shows whether an address still exists before you send to it again.

The definitions, from the standard

Two numbers in a bounce message tell you what happened. The three-digit SMTP reply (550, 452) comes first, then the enhanced status code (5.1.1, 4.2.2) defined in RFC 3463.

The first digit of the enhanced code is the class. RFC 3463 defines two failure classes:

• 4.x.x, "Persistent Transient Failure": the message was valid but a temporary condition stopped delivery. "Sending in the future may be successful."
• 5.x.x, "Permanent Failure": "not likely to be resolved by resending the message in the current form."

That maps directly onto soft and hard. The second digit, the subject, tells you what failed:

Subject	Meaning (RFC 3463)	Who usually needs to act
X.1.X	Addressing status	The sender: the address is wrong
X.2.X	Mailbox status	The recipient: their mailbox has a problem
X.3.X	Mail system status	The receiving system's admin
X.4.X	Network and routing status	Either side's network
X.7.X	Security or policy status	The sender: reputation, authentication or content

The subject matters as much as the class. A 5.1.1 and a 5.7.1 are both permanent, but the first means the address doesn't exist and the second means the server refused you. Treating them the same way either deletes good addresses or hides a sending problem.

Hard bounces, by code

Code	What it means	What to do
550 5.1.1	Mailbox does not exist	Suppress immediately
550 5.2.1	Mailbox disabled, not accepting messages	Suppress; RFC 3463 notes this can be permanent or temporary, but disabled accounts rarely come back
550 5.4.1	Recipient address rejected, access denied	Usually a non-existent address at Microsoft-hosted domains; suppress
550 5.7.1	Refused by policy	Don't suppress on one occurrence; check reputation and authentication
554 5.7.1	Rejected as spam	A content or reputation problem, not an address problem
571 5.7.1	Delivery not authorized	Often a recipient-side allowlist or block

Only the first three are true address failures. The 5.7.x codes are permanent rejections of a specific message from a specific sender, and the same address may accept mail from someone else. Platforms differ in how they file these: HubSpot, for instance, lists "Content", "Spam" and "Policy" alongside "Unknown user" as hard bounce reasons (HubSpot KB). If your platform counts policy blocks as hard bounces, your list looks worse than it is and your sending setup looks better than it is.

Soft bounces, by code

Code	What it means	What to do
450 4.2.1	Mailbox temporarily unavailable	Retry
452 4.2.2	Mailbox full	Retry; suppress if it persists across sends
552 5.2.2	Mailbox full, returned as permanent	Treat as soft at first; suppress if repeated
421 4.7.0	Deferred, try again later	Retry and slow down; often rate limiting or reputation
451 4.3.0	Temporary local error	Retry

The mailbox-full row shows why codes need reading, not just counting. RFC 3463 says the mailbox-full code X.2.2 "should be used as a persistent transient failure", yet servers commonly return it as 552 5.2.2, a permanent class. Some platforms take the opposite view and treat long-term full mailboxes as dead: HubSpot's hard bounce reasons include "Mailbox full" for an inbox that is inactive or over quota for a long time.

The 4.7.x deferrals are also different from the others. They say nothing about the address. They mean the receiving server is throttling you, and retrying faster makes it worse.

How each platform handles them

Every platform suppresses hard bounces. The differences are in how fast, and how many soft bounces they allow before treating an address as dead. Each row comes from the vendor's own help page, read on 8 October 2026.

Platform	Hard bounce	Soft bounce limit	Source
Mailchimp	Address cleaned and excluded from future sends	7 soft bounces with no subscriber activity; up to 15 with previous activity, then converted to a hard bounce	Mailchimp help
Klaviyo	"Automatically suppresses any email address that hard bounces"	Suppressed after "more than 7 consecutive" soft bounces; only the past 2 years count	Klaviyo help
Brevo	Blocklisted	Blocklisted after 5 consecutive soft bounces on campaigns; not applied to transactional email	Brevo help
HubSpot	Excluded from future emails; a hard bounce in 3+ HubSpot accounts becomes a "global bounce" suppressed everywhere	No limit stated; soft-bounced contacts "are eligible to receive future emails". Pending bounces are retried for up to 72 hours	HubSpot KB
Constant Contact	"Non-Existent"; an address that repeatedly bounces this way across any Constant Contact account becomes "Suspended"	"Undeliverable" retried for up to three days; no stated suppression count	Constant Contact KB

Three things stand out.

The counts are per send, not per day. Mailchimp's seven soft bounces take seven weeks on a weekly newsletter and over half a year on a monthly one. An abandoned mailbox stays on a monthly list for a long time.

Shared suppression is common. HubSpot's global bounce and Constant Contact's "Suspended" status both use other customers' sends. An address can be suppressed in your account before you have ever mailed it, which is one reason imported lists show fewer sends than contacts.

Transactional streams are often exempt. Brevo's soft bounce rule applies only to campaigns. If you send receipts and password resets through the same platform, a soft-bouncing address can keep receiving them.

For the transactional platforms (SendGrid, Mailgun, Amazon SES and Postmark) and how long each retries within a single send, see handling soft bounces. Amazon SES also counts only hard bounces toward its bounce rate, so soft bounces there affect delivery but not the number that triggers a review.

Which kind counts toward your bounce rate?

Usually hard bounces, but check. Most enforcement thresholds are defined as hard bounce rates: Brevo's 2% and HubSpot's 5% both are. Some dashboards show a combined figure that includes soft bounces and, in Constant Contact's case, auto-replies that were actually delivered. Before comparing your number with any threshold, find out which bounces your platform counts. The thresholds themselves are in bounce rate limits by platform, and the formula is in how to calculate email bounce rate.

A simple policy you can apply

1. Suppress 5.1.x and 5.2.1 on the first bounce. These are address failures. Sending again only adds to your hard bounce count.
2. Don't suppress 5.7.x on one bounce. Look for a pattern by receiving domain. If one provider rejects everything, it's your reputation or authentication, not the addresses. Our guide to provider bounce messages decodes the wording Gmail, Microsoft and Yahoo use.
3. Retry 4.x.x mailbox codes, and suppress after three to five consecutive sends with the same code. That's stricter than Mailchimp and Klaviyo, and in line with Brevo. It is our recommendation, not a standard.
4. Treat 4.7.x deferrals as a sending problem. Slow down, check your blocklist status, and don't remove the addresses.
5. Verify before importing. A list that has never been mailed has no bounce history, and platforms with shared suppression may still count its dead addresses against you. Checking it first finds the non-existent mailboxes before they become hard bounces.

The labels "hard" and "soft" are a summary. The code underneath tells you whether the problem is the address, the mailbox or you, and each needs a different fix.