Hard Bounce vs Soft Bounce: What’s the Difference and How Do You Fix Them?

A hard bounce is an email delivery failure treated as permanent. A soft bounce is caused by a temporary delivery problem, but that does not mean the email will eventually arrive. The right response is not simply “delete hard bounces and retry soft bounces.” You need to read the error and decide whether to suppress the address, let your provider retry, or investigate the rejection.

For example, 550 5.1.1 can identify a nonexistent mailbox. 550 5.7.1 can reject a message because of a policy even when the mailbox is valid. And a temporary 4xx error can become a final failed delivery if the sending system gives up retrying.

Table of Contents

30 sections Show

Hard Bounce vs Soft Bounce: What Changes for the Sender?

Question	Hard bounce	Soft bounce
What happened?	Delivery failed for a condition treated as permanent.	A temporary condition prevented delivery.
Typical SMTP reply	5xx	4xx
Common example	Recipient does not exist, or delivery is refused by policy.	Mailbox is full, server is unavailable, or delivery is deferred.
Does it prove the address is invalid?	No. A valid recipient can be rejected by policy.	No. A temporary response does not verify the mailbox.
Is the message still being retried?	Usually not after a final permanent rejection.	Possibly. Check the message’s actual queue or event status.
What should you do?	Suppress confirmed invalid destinations; investigate other permanent refusals.	Check retry status, identify the temporary cause, and review the outcome.

Hard Bounces Can Also Affect Valid Email Addresses

A nonexistent mailbox is a straightforward hard-bounce case. If the final recipient really is invalid, repeated sends to that address serve no useful purpose.

A policy rejection is different. A receiving server might permanently refuse the message because of an authorization rule, security filter, or sending configuration. That does not establish that the person’s address is wrong.

A Soft Bounce Means Temporary Failure, Not Guaranteed Delivery

A full mailbox or temporarily unavailable server might accept the email later. It might also remain unavailable until the sending platform stops retrying.

Bounces also differ from poor inbox placement. A message accepted by a receiving server can still land in spam, and a drop in opens does not prove delivery failed. If your problem is a sudden engagement decline rather than an explicit bounce, see why email open rates drop.

What Do SMTP 4xx, 5xx, and 5.x.x Codes Actually Tell You?

Read the SMTP Reply, Enhanced Code, and Diagnostic Text Together

An email’s bounce report, sometimes called a nondelivery report (NDR) or delivery status notification (DSN), may include several distinct clues:

• SMTP reply: A three-digit response such as 550 or 452. Replies beginning with 4 indicate a temporary negative response at that attempt; 5 indicates a permanent negative response.
• Enhanced status: A dotted code such as 5.1.1 or 5.7.1. It describes the category and more specific reason.
• Diagnostic text: The receiving system’s explanation, such as User unknown or Delivery not authorized. This can identify a provider-specific rule that the numbers alone do not explain.
• DSN action: delayed means the reporting system intends to keep attempting delivery. failed means it has abandoned delivery of that message.

Also compare Original-Recipient with Final-Recipient when available. Forwarding can change the destination before a rejection occurs.

Common Bounce Codes and the Correct First Action

Code or example	What it indicates	First action
550 5.1.1	Bad destination mailbox address	Confirm which recipient failed, then suppress a verified invalid destination.
550 5.1.2	Bad destination system address	Check the domain and routing; do not guess a corrected address.
452 4.2.2	Mailbox full	Check whether the message is queued for provider-managed retries.
451 4.3.0	Temporary mail system problem without a more specific status	Read the diagnostic and check the provider’s retry state.
550 5.7.1	Delivery not authorized or refused by policy	Investigate the specific policy reason before another send.
4.4.7 in a DSN	Delivery time expired	Check Action; the current message may have failed after retries ended.

Why a Final Bounce Can Still Have a 4.x.x Status

Consider a server that temporarily refuses each delivery attempt. The sender retries according to its queue policy, but the problem persists. Eventually, it abandons the message and issues a report with Action: failed and a 4.x.x status.

There is no contradiction. The underlying condition was considered temporary, while the outcome for that particular message is final. You must check both fields before telling someone that an email is still on its way.

How to Fix Hard and Soft Bounces in 7 Steps

Step 1. Find the Full Bounce Report for the Failed Recipient

Open the delivery-event details in your email service, or inspect the returned NDR. Capture the recipient, SMTP reply, enhanced status, diagnostic text, message identifier, and any attempt history. If present, record Action, Original-Recipient, and Final-Recipient.

Do not rely solely on a dashboard’s “hard” or “soft” label. Different services use those labels differently, and a short summary can hide the reason you actually need. If your platform does not show enough information, consult its documentation or support for the underlying response.

Step 2. Check Whether Delivery Is Delayed or Has Failed

Look for a queued, deferred, pending, delivered, blocked, or failed event. For a standards-formatted DSN, Action: delayed says the reporting server is still trying; Action: failed says it has stopped.

A temporary response does not mean the provider is still retrying now. Likewise, a permanent rejection does not tell you whether the problem is an invalid recipient or a policy. Establish the message’s final state before making another attempt.

Step 3. Suppress Addresses Confirmed to Be Invalid

When the evidence establishes that the intended mailbox does not exist, exclude that address from future sends. Store the address, suppression reason, and source of the decision so another campaign or integration does not reintroduce it.

Check for forwarding first if the report shows different original and final recipients. If the address looks mistyped, obtain the correct one through an appropriate source rather than inventing a likely spelling or repeatedly emailing the invalid version. Keep unsubscribes excluded regardless of bounce classification.

Step 4. Let Temporary Failures Follow Your Provider’s Retry Process

For a mailbox-full or temporary server error, inspect whether delivery remains queued. If your sending service is already retrying, manually resending the same email may create duplicate attempts without resolving the underlying problem.

Review any receiver-specific diagnostic or retry guidance and your provider’s documented queue behavior. Then check whether the message was accepted or eventually failed. There is no universal retry interval or maximum number of attempts that applies to every email platform. Do not promise delivery simply because an error begins with 4.

Step 5. Investigate Policy Rejections Before Resending

Treat 550 5.7.1 as a reason to investigate, not evidence that the mailbox is nonexistent. Read the complete rejection text. It may identify authentication requirements, recipient-organization restrictions, routing problems, or a sending policy.

If the diagnostic actually points to authentication or infrastructure, inspect the relevant SPF, DKIM, DMARC, or DNS configuration. BrandJet’s Email Deliverability Checker reviews domain records and blacklist status. It is not a recipient-mailbox verifier or a delivery guarantee.

Avoid changing DNS records merely to make a bounce disappear. Fix the issue supported by the evidence, and follow the receiving provider’s guidance before considering another send.

Step 6. Review Repeated Soft Bounces Before Future Campaigns

Separate one-off deferrals, eventual deliveries, and repeated final failures. Review the event history for that address and whether similar failures affect many recipients at the same domain.

If an address remains unreachable, consider temporarily pausing future campaigns to it while you investigate. Some platforms automatically reclassify repeated soft bounces or exclude contacts after their own limits. Apply the provider’s documented behavior, not a made-up rule such as “suppress after three soft bounces.”

For wider issues involving list quality and sender configuration, see how to manage email deliverability.

Step 7. Preserve Bounce and Unsubscribe Suppressions Across Platforms

Switching email services must not turn previously excluded recipients into sendable contacts. Before enabling a campaign in the new system, preserve the old service’s available suppression records and the reasons behind them.

Keep confirmed invalid addresses, unsubscribes, complaints, and temporary review holds distinguishable. Import or synchronize the applicable exclusions into the destination platform, verify that a sample of excluded records stays excluded, and check that CRM syncs or enrichment jobs cannot silently reactivate them.

A successful contact import only proves that records moved. It does not prove your suppression rules moved with them.

Worked Bounce Reports: What Should You Do Next?

The following are illustrative nondelivery reports, not records of live sends. They show how different combinations of fields change the decision.

Example 1. An Unknown Recipient Returns 550 5.1.1

Final-Recipient: rfc822; recipient@example.com
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown

Decision: The report identifies a nonexistent destination mailbox and a final failed message. If this is the intended recipient with no forwarding ambiguity, suppress the address. Do not resend unchanged.

Example 2. A Full Mailbox Returns 452 4.2.2

Final-Recipient: rfc822; recipient@example.com
Action: delayed
Status: 4.2.2
Diagnostic-Code: smtp; 452 4.2.2 Mailbox full

Decision: The message is delayed, not yet declared a final failure. Check the provider’s queue and let its retry process operate. A later successful delivery is possible, not assured.

Example 3. A Policy Rule Returns 550 5.7.1

Final-Recipient: rfc822; recipient@example.com
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp; 550 5.7.1 Delivery not authorized

Decision: The message was refused permanently under a policy or authorization rule. Nothing here proves the mailbox is invalid. Look for more specific provider information, correct the identified cause, and do not blindly repeat the send.

Example 4. A Temporary Problem Ends in a Final Failure

Final-Recipient: rfc822; recipient@example.com
Action: failed
Status: 4.4.7
Diagnostic-Code: smtp; 451 4.3.0 Temporary mail system failure

Decision: The attempt history has ended with delivery time expired. The final outcome is failure even though the last reported underlying error was temporary. Investigate before deciding whether a separate future send is appropriate.

Example 5. A Forwarded Address Changes the Destination

Original-Recipient: rfc822; alex@example.com
Final-Recipient: rfc822; old-alias@example.net
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown

Decision: The reported invalid mailbox is the final destination, not necessarily the original address. Investigate the forwarding path before marking alex@example.com permanently invalid.

When Will Your Email Platform Stop Retrying or Suppress the Address?

The answer depends on the service and the event type. These documented examples illustrate why one platform’s rules should not be used as a universal sending policy.

Platform	How its documented behavior differs
Mailchimp	Repeated soft bounces can lead to an address being cleaned. Its documented allowance is seven soft bounces without subscriber activity and up to 15 with previous activity.
HubSpot marketing email	A temporary issue can appear as a pending bounce while HubSpot retries for up to 72 hours. If not delivered, it becomes a soft bounce. Hard and global bounces have different exclusions.
Twilio SendGrid	It retries deferred messages for up to 72 hours. An unresolved deferral then becomes a block event, which is not the same as a hard-bounce suppression.
Mailgun	It distinguishes a still-active deferral from a final soft bounce. A final soft-bounced message is not automatically resent, but the recipient is not automatically suppressed for that reason.

Before changing a contact’s status, determine whether the platform shows a retry event, final message outcome, or recipient-level exclusion. Marketing and connected-inbox sends may show different details.

FAQ

What is the main difference between a hard bounce and a soft bounce?

A hard bounce indicates a delivery problem treated as permanent, while a soft bounce indicates a temporary problem. Typically, the SMTP reply starts with 5 for permanent refusal and 4 for a temporary response. The actual next action depends on the enhanced code, diagnostic text, and whether delivery is still being attempted.

Does a hard bounce always mean the email address is invalid?

No. A hard bounce can mean the recipient mailbox does not exist, but it can also reflect a permanent policy or authorization refusal. A 5.1.1 invalid-recipient report requires different action from a 5.7.1 policy rejection. Read the complete response before suppressing an address as nonexistent.

Is a 550 SMTP error always a hard bounce?

550 is a permanent negative SMTP reply, so it commonly leads to a hard-bounce classification. But it does not explain why the message was rejected. 550 5.1.1 can indicate an invalid mailbox, while 550 5.7.1 can indicate a policy refusal affecting a potentially valid recipient.

What does a 550 5.7.1 email bounce mean?

It means delivery was refused for a policy or authorization reason. The receiving server may provide additional text describing the restriction. It does not by itself prove failed SPF, DKIM, or DMARC checks, or that the recipient is nonexistent. Investigate the specific reason before attempting another send.

Should you resend an email after a soft bounce?

First check whether the original message is still queued for automatic retries. If it is, manually sending a duplicate is usually unnecessary. If delivery has already failed, review the reason, provider policy, and recipient history before deciding on a new message. A temporary error does not guarantee eventual acceptance.

How many soft bounces should happen before you suppress an address?

There is no single threshold that applies to every sender. Some services automatically exclude recipients after repeated soft bounces, while others distinguish deferrals from final failures. Follow your provider’s rules and review persistent problems. A temporary pause can be appropriate without incorrectly labeling the mailbox permanently invalid.

What happens to bounced and unsubscribed contacts when you switch email platforms?

Do not assume the destination platform inherits the original service’s exclusions. Preserve and transfer applicable hard-bounce, unsubscribe, complaint, and other suppression records before sending. Keep the reasons attached, validate exclusions after import, and prevent integrations from reactivating them. Never retry permanently invalid or unsubscribed addresses just because the platform changed.