Should I remove soft bounces from my email list?

Not automatically after one temporary failure. Keep the raw response and follow your sending platform's documented retry and suppression policy. A repeated temporary failure may eventually justify suppression, but there is no universal attempt count.

What is an example of a hard bounce?

550 5.1.1 Recipient address rejected is a typical permanent address failure. Verify the address out of band and stop retrying it unchanged.

What causes a soft bounce?

Common causes include a full mailbox, a temporarily unavailable receiving server, network trouble, throttling, or a temporary policy deferral. The exact response text should determine the next step.

Can a full mailbox become a hard bounce?

Only in the sense that an ESP may eventually apply a permanent operational classification after repeated failures. The standards describe mailbox-full status as a persistent transient condition, so check that provider's current documentation rather than assuming one universal threshold.

Are all 5xx replies hard bounces?

Not necessarily as a provider label. A 5yz SMTP reply is permanent for the requested action, but the operational “hard bounce” label still comes from the sending platform. Preserve the exact code and text because the repair may involve the address, message, authentication, or policy.

Soft bounce vs hard bounce: what each means and what to do

Q: What is the difference between a soft bounce and a hard bounce?

Email platforms use hard bounce for a failure they consider permanent and soft bounce for a failure they consider temporary. Mailchimp documents this distinction for its own service. The underlying standards use reply classes instead: RFC 5321 defines a 4yz reply as a transient negative completion and a 5yz reply as a permanent negative completion. That mapping is a starting point, not the whole diagnosis. RFC 3463 adds enhanced codes such as 4.2.2 or 5.1.1, where the first digit gives the class and the remaining fields narrow the subject and condition. Provider policy, message history, and the exact diagnostic text still matter.

A hard bounce is a delivery failure the sending platform treats as permanent, such as a nonexistent address. A soft bounce is treated as temporary, such as a full mailbox or a receiving server that is unavailable. The label is useful, but the raw SMTP reply and enhanced status code are stronger evidence. Check both before suppressing an address, retrying indefinitely, or changing domain configuration.

Quick takeaways

Hard usually means do not retry that unchanged recipient and message.
Soft usually means retry according to the sending platform's policy, then reassess.
A provider's “hard” or “soft” label is an interpretation, not an SMTP standard term.
Read the reply text and enhanced status code before choosing a repair.
Do not treat one provider's retry or suppression threshold as an industry rule.

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

Email platforms use hard bounce for a failure they consider permanent and soft bounce for a failure they consider temporary. Mailchimp documents this distinction for its own service. The underlying standards use reply classes instead: RFC 5321 defines a 4yz reply as a transient negative completion and a 5yz reply as a permanent negative completion.

That mapping is a starting point, not the whole diagnosis. RFC 3463 adds enhanced codes such as 4.2.2 or 5.1.1, where the first digit gives the class and the remaining fields narrow the subject and condition. Provider policy, message history, and the exact diagnostic text still matter.

Start with the evidence, not the label

Copy the raw response before changing anything. A useful record contains the recipient, basic SMTP reply, enhanced status, provider classification, first-seen time, and repeat count.

bounce_evidence:
  recipient: "redacted@example.net"
  smtp_reply: 550
  enhanced_status: "5.1.1"
  diagnostic: "Recipient address rejected"
  provider_label: "hard bounce"
  first_seen: "2026-07-23T18:42:00Z"
  repeat_count: 1
decision:
  action: "suppress this address and verify it out of band"
  reason: "The receiver returned a permanent address-status failure."

The sample is illustrative and redacted. It is not a test address and should not be copied into a live send.

Common hard-bounce evidence

A 5yz reply means the requested mail action was not accepted and the sending client should not repeat the same request unchanged. Common examples include:

5.1.1 with text saying the recipient address does not exist.
A recipient or domain that the receiver says is invalid.
A message that exceeds a permanent administrative size limit.
A permanent policy rejection with a specific provider explanation.

The narrowest response depends on the evidence. Correct an obvious typo only when you can verify the intended address. Suppress an address the receiver says does not exist. If the rejection cites policy, authentication, content, or reputation, investigate that named condition rather than deleting the recipient.

Do not keep retrying an unchanged permanent failure. Repeated sends to an invalid address add noise and do not repair the cause.

Common soft-bounce evidence

A 4yz reply means the receiver did not complete the request at that time, but the condition may change. Common examples include:

A full mailbox reported as a persistent transient condition.
A temporary receiving-system or network problem.
Rate limiting or a temporary policy deferral.
A sender-volume spike that a provider asks you to slow down.

Let the sending platform follow its documented retry schedule. Keep the original reply, then compare later attempts. If a temporary condition persists, the platform may eventually classify or suppress it differently. That decision is provider-specific.

Google's current sender guidance, for example, tells senders facing deferrals to pause, test with a single message, and raise volume gradually after successful delivery. That is guidance for Gmail traffic, not a universal retry timetable.

Why provider labels can disagree

SMTP exposes reply codes and text. “Hard bounce” and “soft bounce” are operational labels applied by an ESP or mailbox provider. Two platforms can map unusual or ambiguous responses differently, especially when a remote system uses a generic code with more specific free-form text.

Twilio SendGrid's bounce classifications illustrate this provider layer: the platform groups responses into categories for reporting and action. Those categories are useful inside SendGrid, but they do not redefine the receiver's SMTP response or another ESP's suppression policy.

For a defensible decision, preserve both:

Receiver evidence: reply code, enhanced code, text, and remote host.
Provider interpretation: soft, hard, blocked, deferred, or another category.

What should you do after each type?

For a hard bounce, stop the unchanged retry, verify address data, and repair the named permanent cause. For a soft bounce, allow bounded retries and watch whether the same recipient, domain, or sending path keeps failing.

Use the broader common email bounce messages guide to map the exact diagnostic text. If the failure points to missing mail routing, follow the no MX record found diagnosis. Do not confuse bounce permanence with SPF hardfail versus softfail; SPF qualifiers describe authorization results, not whether a mailbox-delivery failure is temporary.

Validate through the same sending path

After a repair, send a new message from the same production system to a recipient you are authorized to test. Keep the same domain, return path, gateway, and major content path so the result exercises the failed route.

Then compare:

the new SMTP reply or successful acceptance;
the enhanced status and diagnostic text;
the sending platform's updated classification;
whether the same issue appears for one address, one recipient domain, or all traffic.

One successful test does not guarantee future inbox placement. It only shows that the tested path no longer produced the same failure.

Check domain controls only when the bounce points there

If the rejection names SPF, DKIM, DMARC, MX, or another public domain configuration problem, use the Email Security Score to inspect the published controls for the sending domain.

Check the domain's email security score

The score cannot verify whether a recipient mailbox exists, reproduce a receiver's private policy, interpret every ESP suppression rule, or prove that a retried message will be accepted.