Hard Bounce vs Soft Bounce: Keep Your List Clean

Hard bounces are permanent email delivery failures, usually represented by SMTP 5xx or enhanced 5.x.x status codes, while soft bounces are temporary failures, usually represented by 4xx or 4.x.x codes. Remove or suppress confirmed hard-bounce addresses, but let your ESP retry legitimate soft bounces before removing them.

SMTP defines 4xx replies as transient negative responses that should normally be retried and 5xx replies as permanent negative responses that should not be repeated unchanged. Enhanced mail status codes preserve the same temporary-versus-permanent distinction. RFC 5321 and RFC 3463 define these behaviors.

What Is a Hard Bounce?

A hard bounce is a permanent delivery failure that prevents an email from being delivered without changing the recipient address, message, destination, authentication, or another part of the sending condition.

RFC 5321 defines a 5xx SMTP response as a permanent negative completion response. The SMTP client should not simply repeat the identical request because something must change before delivery can succeed.

Enhanced status codes provide more detail.

For example:

• 5.1.1 means the destination mailbox address does not exist.

• 5.1.2 means the destination mail system or domain address is invalid for mail.

• 5.1.3 identifies invalid destination mailbox syntax.

• 5.1.6 indicates that the mailbox moved and has no forwarding address.

RFC 3463 specifically classifies bad destination mailbox addresses and bad destination system addresses as permanent failures.

A hard bounce does not always mean the subscriber entered a fake email address.

A 5xx response can also result from a permanent policy, security, authentication, routing, or message-format problem. Gmail, for example, documents 550 5.7.1 responses for certain permanent sending-IP or policy rejections.

That distinction changes the correct list-cleaning action.

A nonexistent mailbox such as john.smith@example.com returning 5.1.1 should normally be suppressed. A sender-wide 5.7.x rejection should trigger an authentication, reputation, or policy investigation before thousands of recipient records are removed.

What Is a Soft Bounce?

A soft bounce is a temporary email delivery failure where the recipient address or message may still be deliverable after the temporary condition clears.

SMTP 4xx replies are transient negative responses. RFC 5321 states that the SMTP client should normally try the request again because an unchanged request may succeed later.

Typical temporary conditions include:

• A full recipient mailbox

• Temporary server overload

• Network connection failures

• Temporary DNS or directory-server failures

• Mail-system congestion

• Temporary rate limiting

• Greylisting

• Temporary sender throttling

RFC 3463 defines X.2.2, mailbox full, as a persistent transient failure. It also defines conditions such as no answer from the destination host, bad connections, directory-server failure, and mail-system congestion as transient conditions.

Gmail also uses temporary SMTP responses for sending restrictions. Google documents 4.7.28, for example, when a sender exceeds certain sending quotas and instructs senders to reduce activity before gradually resuming.

A soft bounce therefore should not trigger the same immediate suppression rule as a confirmed nonexistent mailbox.

What Causes a Hard Bounce?

Hard bounces occur when successful delivery requires a meaningful correction rather than another identical delivery attempt.

1. The recipient mailbox does not exist

An expired employee account, deleted consumer mailbox, typo, or fabricated address can produce an enhanced 5.1.1 response.

RFC 3463 defines X.1.1 as a bad destination mailbox address and states that the mailbox does not exist.

2. The recipient domain cannot accept email

A misspelled domain such as gmai.com instead of gmail.com, a removed domain, or a domain without a usable mail destination can produce a permanent address or routing failure.

3. The email address syntax is invalid

A malformed local part or destination address can produce a permanent syntax-related failure such as 5.1.3.

4. The mailbox was permanently disabled

An employee who leaves a company may have a mailbox that once existed but no longer accepts messages.

5. The message violates a permanent limit

RFC 3463 treats conditions such as a message exceeding certain mailbox or mail-system size limits as permanent failures.

The recipient address may still be valid in this situation. Reducing the message size may solve the problem.

6. The receiving server permanently rejects the sender

Policy, authentication, reputation, blocklist, security, or infrastructure problems can produce 5xx responses.

If many valid addresses at one domain start returning the same permanent error simultaneously, investigate the sender or receiving-domain relationship before treating every recipient as invalid.

For authentication-specific failures, see SPF, DKIM, and DMARC explained for email senders. MailEditor’s existing guide explains how the three protocols establish sender authorization, message integrity, and domain alignment.

What Causes a Soft Bounce?

Soft bounces occur when the current delivery attempt fails but another attempt can succeed without changing the recipient address.

Mailbox full

4.2.2 commonly identifies a mailbox that has exceeded its available quota. RFC 3463 classifies the mailbox-full condition as transient because the recipient can create space and accept future messages.

Receiving server unavailable

A destination mail server can be offline, overloaded, under maintenance, or temporarily unable to accept network messages.

Network or connection failure

The sending server can reach the destination but fail to complete the SMTP transaction because of a timeout or connection-quality problem.

Temporary DNS or routing problem

A mail server can temporarily fail to retrieve the routing information required to locate the next destination.

Mail-system congestion

RFC 3463 includes a specific enhanced status condition for delivery delayed by mail-system congestion.

Temporary rate limiting

Mailbox providers can defer messages when a sender sends too quickly, develops an unusual traffic pattern, exceeds quotas, or receives temporary reputation-based throttling.

Google explicitly advises senders whose messages begin bouncing or being deferred to reduce sending volume until SMTP error rates decline and then increase volume gradually.

What SMTP Codes Indicate Hard and Soft Bounces?

The first digit provides the most useful starting point.

The enhanced code matters because the difference between 5.1.1 and 5.7.1 is operationally significant.

5.1.1 points toward the destination mailbox.

5.7.1 points toward a security or policy rejection.

Treating both records as identical "hard bounces" can cause unnecessary subscriber deletion.

Do Hard and Soft Bounces Hurt Email Deliverability?

Repeated bounces are a deliverability warning because they indicate recipient-quality, sending-volume, infrastructure, or sender-policy problems that should be corrected before the next large campaign.

Google recommends confirming recipient email addresses before subscription, monitoring server responses, automatically unsubscribing recipients with multiple bounced messages, and reducing sending volume when bounces or deferrals increase.

Google does not publish "bounce rate" as one universal Gmail reputation score. Google Postmaster Tools instead exposes signals such as spam rate, domain reputation, IP reputation, authentication, and delivery errors.

This distinction matters.

A bounce is a delivery result.

Sender reputation is the broader history mailbox providers associate with the domain and infrastructure.

Poor list hygiene can contribute to poor sending behavior, but suppressing bounces is only one part of maintaining deliverability.

Google currently recommends keeping Postmaster Tools spam rates below 0.10% and avoiding 0.30% or higher. That is a spam-complaint metric, not a bounce-rate threshold.

How Should You Handle a Hard Bounce?

Handle hard bounces according to the actual SMTP reason rather than the word "hard" alone.

1. Read the SMTP and enhanced status code. Identify whether the failure concerns the address, domain, message, authentication, policy, or sender infrastructure.

2. Suppress confirmed invalid mailboxes. Addresses returning permanent invalid-recipient responses such as 5.1.1 should not continue receiving campaigns.

3. Separate recipient failures from sender failures. A domain-wide 5.7.x policy rejection requires investigation rather than mass deletion of subscribers.

4. Correct fixable permanent errors. Message-size, authentication, configuration, and formatting problems can require changes before another attempt.

5. Do not automatically restore suppressed addresses. Restore an address only when the underlying address or delivery condition has genuinely been corrected.

6. Keep bounce history. Suppression and diagnostic records help prevent accidentally importing the same invalid contacts during a future list migration.

Suppression is usually more useful than permanently erasing the record because the suppression record prevents the same invalid address from being reintroduced.

Should You Retry a Soft Bounce?

Yes. A legitimate soft bounce should normally remain eligible for retry because SMTP defines 4xx errors as temporary conditions.

Your ESP or mail-transfer system normally manages retry timing automatically. Do not repeatedly resend the campaign manually every few minutes.

The reason code should control the next action.

A full mailbox requires patience.

A temporary network failure requires another delivery attempt.

A sender-rate-limit response requires slower sending.

A temporary authentication or reputation-related deferral requires diagnosis before aggressive retrying.

Identical retry behavior is therefore inappropriate for every 4xx response.

How Many Soft Bounces Before You Remove an Address?

There is no universal SMTP rule requiring removal after a fixed number of soft bounces.

SMTP defines whether a condition is transient or permanent. It does not say that every address must be removed after two, three, or five temporary failures.

Google similarly recommends automatically unsubscribing recipients who have multiple bounced messages but does not specify one universal soft-bounce count for every sender or ESP.

Use the ESP's retry system first.

Then evaluate repeated transient failures by:

• Error code

• Failure duration

• Number of campaigns affected

• Recipient domain

• Whether other recipients at the domain are delivering

• Whether the failure is recipient-specific or sender-wide

An address repeatedly returning temporary failures across separate campaigns deserves suppression or manual investigation even if the server never converts the condition into a permanent 5xx failure.

How Do You Keep an Email List Clean?

A clean email list contains valid, permission-based recipients and consistently suppresses contacts that should no longer receive campaigns.

1. Confirm addresses when subscribers enter the list

Google recommends confirming each recipient's email address before subscribing the recipient.

An address-confirmation workflow catches typos before the first large campaign.

2. Send only to people who requested the email

Permission reduces complaints and prevents databases from filling with scraped, purchased, or irrelevant addresses.

Google explicitly recommends sending subscription email only to people who want to receive the messages.

3. Suppress permanent invalid-recipient bounces

Do not continue sending campaigns to mailboxes that have returned confirmed permanent invalid-address responses.

4. Monitor repeated temporary failures

Keep soft-bounced contacts while legitimate retries continue, but identify addresses that fail repeatedly across campaigns.

5. Separate bounced, unsubscribed, and inactive contacts

These are three different states.

A bounce means delivery failed.

An unsubscribe means the recipient withdrew permission.

An inactive subscriber can still receive the email but has stopped engaging.

Each status requires different automation and reporting.

6. Process unsubscribes correctly

Unsubscribing is cleaner than forcing an uninterested recipient to report the message as spam.

For Gmail senders, Google's Email Sender Guidelines recommend easy subscription management and require one-click unsubscribe for qualifying high-volume marketing traffic. Google also recommends automatically unsubscribing recipients with multiple bounced messages.

7. Watch the sending domain, not only the contact database

A perfect contact list cannot compensate for broken authentication, poor IP reputation, excessive sending volume, or malformed email infrastructure.

Use Google Postmaster Tools and your ESP's SMTP logs together.

8. Test the campaign after cleaning the list

List hygiene fixes the recipient side of campaign quality.

Template testing fixes another part of the sending workflow.

MailEditor does not validate or clean subscriber addresses. It lets you import, visually edit, reuse, and export HTML email templates for your sending platform.

Once your bounce list is clean, edit your HTML email free in MailEditor and export the finished campaign to your ESP.

Hard Bounce vs Soft Bounce: Which Should You Remove?

Remove or suppress confirmed permanent invalid recipients; retain legitimate soft-bounced recipients while the temporary condition remains retryable.

Do not reduce the rule to "delete every 5xx, keep every 4xx forever."

Use the entire diagnostic.

The cleanest email programs classify the cause before changing subscriber status.

Practical Example: Cleaning a Campaign Bounce Report

Consider an illustrative campaign sent to 10,000 recipients.

The bounce log contains:

• 12 recipients returning 5.1.1

• 20 recipients returning 4.2.2

• 30 Gmail recipients returning temporary 4.7.28 deferrals

The correct response is not to remove all 62 contacts.

The 12 5.1.1 addresses represent nonexistent destination mailboxes. Suppress them.

The 20 4.2.2 addresses have full mailboxes. Leave them available to the ESP's normal retry process.

The 30 4.7.28 responses indicate a sender-side Gmail sending-rate problem rather than proof that 30 subscribers are invalid. Reduce sending volume, inspect the sending pattern, and resume gradually after the temporary restriction clears. Google provides this specific recovery approach for 4.7.28.

This example shows why bounce classification protects both list quality and legitimate subscribers.

What Should You Fix After Cleaning Your Bounce List?

Bounce cleanup solves only one part of email deliverability.

Next, check:

• SPF authentication

• DKIM authentication

• DMARC alignment

• Sending domain reputation

• Sending IP reputation

• Spam complaints

• Unsubscribe handling

• HTML structure

• Message size

• Suspicious links

• Template rendering

If the list is clean but campaigns still miss the inbox, use MailEditor's guide to why emails land in spam. It separates authentication, sender reputation, content, and template-related causes.

You can also work through how to lower your email spam score before the next campaign.

After fixing your list and sender configuration, build or edit a clean HTML email in MailEditor, reuse your branded template, and export it to your sending workflow. MailEditor supports uploading existing HTML, visually editing the content, using prebuilt templates, and exporting the finished template.

FAQ

Question: What bounce code means an email is a hard bounce?

Answer: A 5xx SMTP response or 5.x.x enhanced status code normally represents a permanent delivery failure. 5.1.1, for example, means the destination mailbox does not exist. Read the full status code before suppressing the contact because some permanent failures relate to policy, authentication, message size, or sender configuration rather than an invalid recipient.

Question: Is a full mailbox a hard bounce or soft bounce?

Answer: A full mailbox is normally a soft bounce. RFC 3463 defines the X.2.2 mailbox-full condition as a persistent transient failure because the recipient can remove stored messages and create capacity. The ESP should normally retry the address rather than immediately suppressing it as permanently invalid.

Question: Should I delete an email address after one hard bounce?

Answer: Suppress an address after one confirmed permanent invalid-recipient failure such as 5.1.1, but inspect the status code before deleting the subscriber record. Permanent policy, authentication, sender reputation, or message-size failures can affect valid addresses. Suppression also preserves the bounce record and prevents an invalid address from being accidentally reimported.

Question: How many soft bounces should happen before removing an email?

Answer: No universal SMTP standard defines a fixed number of soft bounces after which an address must be removed. Let the ESP perform legitimate retries, then evaluate repeated failures across campaigns. Google recommends automatically unsubscribing recipients with multiple bounced messages but does not prescribe one universal numerical threshold.

Question: Can a clean email list still send messages to spam?

Answer: Yes. List hygiene addresses recipient quality, but inbox placement also depends on authentication, domain and IP reputation, recipient complaints, sending patterns, content, and message structure. Google recommends monitoring authentication, spam rate, delivery errors, IP reputation, and domain reputation through Postmaster Tools.