Hard Bounce vs Soft Bounce: Causes and What to Do Next

A hard bounce is a persistent delivery failure; a soft bounce describes a temporary delivery problem. The distinction helps you decide whether to suppress an address, allow a controlled retry or investigate a wider sending issue.

The label alone is not the whole diagnosis. Read the reason supplied by your email platform and receiving server. A mailbox problem needs a different response from a sender authentication failure, and neither should be confused with an unsubscribe.

Hard bounce vs soft bounce at a glance

	Hard bounce	Soft bounce
Typical meaning	Persistent delivery failure	Temporary delivery problem
Common example	The recipient mailbox does not exist	A full mailbox or temporary server problem
First action	Read the reason and stop repeated sends to a confirmed invalid address	Check the provider’s retry behaviour and watch for recurrence
What to avoid	Importing the same failed address into every new campaign	Assuming one temporary failure proves the address is permanently unusable

Email platforms classify and retry failures differently. Amazon SES’s delivery guidance, for example, distinguishes persistent failures from temporary problems and explains its retry handling. Use your own provider’s current documentation for the operational rules.

What causes a hard bounce?

An address may never have existed, may contain a mistake or may refer to a mailbox that has been removed. Domains can also cease to receive mail. The diagnostic message provides the evidence for the next step.

Do not reduce every permanent rejection to “the customer is fake”. A legitimate person may have changed jobs or mistyped an address. Equally, a permanent rejection associated with policy or sender configuration needs investigation rather than a blind correction to the recipient record.

What causes a soft bounce?

Temporary failures can occur when a mailbox is full, a receiving server is busy or a connection times out. The sending platform may already be attempting delivery again.

Check what the platform will do before launching a second manual send. Repeatedly submitting the same message can create duplicates if the original attempt later succeeds.

If temporary problems recur, look for patterns. A single affected contact may need individual review; a sharp rise across one domain may suggest a provider-level or sending configuration issue.

How to investigate an email that bounced

1. Capture the reason, not just the label

Keep the address, event time, campaign reference and diagnostic reason in your investigation record. Avoid forwarding a full customer export when a small set of examples will answer the question.

Your provider’s report may include a broad category, a server response and a final delivery outcome. Read them together. An early delay and a final failure are not necessarily separate recipient events.

2. Decide whether it is an address issue

A clearly mistyped domain or a missing mailbox points towards recipient data quality. Check against a reliable source before changing it. Do not guess a corrected address and send marketing to someone who may be a different person.

For a confirmed permanent address failure, remove the address from future send audiences and retain the appropriate suppression record so a later import does not reintroduce it.

3. Check for a wider sending issue

If many apparently unrelated addresses fail at once, review your platform status, sender authentication and recent changes in sending behaviour. Address validation cannot repair a broken sending configuration or guarantee acceptance by a recipient’s provider.

A platform’s “delivered” status also does not necessarily mean the message reached the main inbox or was read. Keep the delivery event distinct from engagement.

4. Let retries follow a controlled policy

Use your email provider’s documented retry process and monitor final outcomes. Set an internal review rule for contacts that repeatedly soft bounce across campaigns. The right threshold depends on the platform, sending pattern and diagnostic reasons.

Do not use a universal number of retries borrowed from an unrelated tool as though it were a rule for all email systems.

A practical example

A business sends an announcement to an older customer segment. Some addresses return mailbox-not-found errors, while several contacts at one company are delayed by a temporary server problem.

The mailbox-not-found group needs suppression from subsequent campaigns unless reliable updated details are obtained. The delayed group needs monitoring under the platform’s retry policy. Exporting both groups as “bad addresses” and deleting every record would discard useful distinctions.

Where email validation helps

DataSoap email verification helps assess contact data before sending. It can identify formatting and technical address problems and flag categories that need different handling.

Run it before using an old file, after importing a new source or within a capture process. Then apply suppression and audience rules to the results. For a broader preparation workflow, use the email list hygiene checklist.

Validation is preventive information, not a guarantee that the next message will be accepted. Sending reputation, content and recipient-side decisions still matter.

Measure bounces consistently

Compare campaigns using the same definitions and reporting window. Check whether the denominator is attempted messages, accepted sends or unique recipients, and whether temporary failures are counted before or after retries finish.

Track the source of failed addresses as well as the headline rate. A new enquiry form producing many mistakes needs a different fix from an old database that has not been used for years.

Frequently asked questions

Does a soft bounce mean the address is valid?

No. It means the reported failure is temporary in that context. Review the full reason and later outcome rather than treating the label as proof.

Should we delete a customer after a hard bounce?

Suppressing an unusable email address is different from deleting a customer account. Consider the record’s other purposes and retention rules separately.

Can we send a test email to every questionable address?

That creates more delivery attempts and may repeat the same problem. Use suitable validation, reliable customer updates and the platform’s diagnostic information instead.

Fix the cause before the next send

Separate permanent address failures, temporary delays and sender-side problems. Keep the reasons available to the people maintaining the list. Explore DataSoap email validation to review older or newly imported contact data before the next campaign.