Soft bounce vs hard bounce: build a reason-aware handling policy

Define the decision

Soft and hard are operational categories that different tools may classify differently. A temporary deferral, an invalid address and an uncertain send require different actions even if a dashboard groups them together.

Work through the procedure

1. Preserve basic and enhanced codes plus the provider explanation.
2. Separate invalid destinations, temporary refusal, content-policy failure and uncertain acceptance.
3. Suppress confirmed invalid addresses and honor opt-outs independently.
4. Bound retryable failures and investigate repeated patterns by source and provider.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Invalid mailbox: suppress address
Temporary refusal before acceptance: bounded retry policy
Lost final response: investigate uncertainty
Policy rejection: fix cause before another attempt
One generic retry button cannot safely represent all four

Read the result

The output is a handling decision with evidence, not just a renamed category. Review how the deployed application maps incoming bounce notices before assuming it implements every distinction in your policy.

Check before moving on

1. Confirm later steps cannot bypass suppression.
2. Track repeated failures from the same import source.

Limits and next action

Zintara processes recognized incoming bounce events, but this guide is not a promise of exhaustive provider-code classification. Escalate ambiguous notices with redacted originals.

Source: RFC 3463: delivery status categories