A hard bounce generally signals a permanent delivery failure; a soft bounce usually describes a temporary one. Those labels are a starting point, not a full diagnosis. The response may point to an invalid address, a receiving-system policy, or a temporary limit. Read the reported reason before retrying, and keep the evidence with the customer record so the next campaign does not repeat the problem.
Start with the reported reason
A hard bounce generally indicates a permanent delivery problem, such as an invalid recipient. A temporary failure may involve a busy server, a full mailbox, or a deferral. Authentication and policy rejections need their own investigation rather than being treated as ordinary typos.
Review the delivery details available in your reports. Look for patterns by audience source, domain, and recent configuration changes. One isolated failure is different from a sudden cluster affecting an entire campaign.
Separate the response category from its cause
A temporary response means the receiving system has not accepted the message at that attempt and may accept a later retry. A permanent response means that attempt was rejected as a final failure. The detailed reason still matters: an invalid mailbox, an authentication problem, and a policy rejection are not the same fault merely because the report groups them as failures.
Do not reduce the diagnosis to “soft means safe to resend” and “hard means typo.” Read the available response text and ask for help when it is unclear. A busy receiver may need time, while a domain-wide authentication error needs a configuration repair. Repeatedly sending the same campaign manually can create duplicate attempts without addressing either problem.
Compare the pattern. One newly collected address failing permanently suggests a different investigation from many previously healthy addresses failing after a sender-domain change. A cluster concentrated at one receiver may point to receiver-specific handling, but it still requires evidence rather than a guess based on the domain name alone.
Keep invalid records out of routine sends
Sendvio performs pre-send email checks and marks unusable addresses Invalid rather than deleting the customer record. Preserve that status and relevant history. Do not repeatedly reimport the same address as sendable just because a campaign audience looks smaller than expected.
If a customer provides a corrected address, update it through a trustworthy process and preserve appropriate permission records. Technical validity and consent are separate checks. A new address should not silently inherit every marketing permission without considering how the correction was obtained.
Keep a compact incident record
Record the affected campaign, time range, intended audience source, failure count, denominator, and representative sanitized response details. Note recent changes to authentication, sending volume, identity, or data imports. Preserve enough information to compare a repaired test with the original failure without sharing unnecessary customer data.
For an illustrative audience of 1,000 attempted messages, 30 failures mean 3% of attempts failed under that definition. If 25 of those failures came from a recent 100-contact import, the source deserves separate attention. The overall percentage alone hides that concentration. These numbers are an example of diagnosis, not a threshold for safe sending.
Fix the source, not only the symptom
A rise in invalid signups may point to form errors, poor acquisition quality, or abusive submissions. A rise after a domain change may point to authentication. Match the response to the cause before increasing volume.
Keep the failure rate tied to a clear denominator and compare like-for-like sends. Track whether the issue improves after the fix. Retrying indiscriminately can obscure the problem and damage the experience; careful diagnosis helps preserve both useful customer history and a dependable sending audience.
After the suspected cause is repaired, use a controlled test through the affected sending path. Check the actual response and the resulting record status before expanding. Where a permanent invalid status is appropriate, do not override it merely to make the test audience larger. A corrected address supplied by the customer needs its own trustworthy update and permission review.
Close the incident with the root cause, the fix, and the prevention step. A form problem might require better collection checks; a configuration problem might require a change checklist; a poor import may need stronger source review. The valuable outcome is fewer repetitions of the same failure, not a report that looks cleaner because the problematic history was deleted.