Read the bounce reason before you clean the list
A bad address, a temporary delay and a policy block need different fixes.
A high bounce rate tells you messages failed. It doesn't tell you why.
Before deleting contacts or buying another verification run, export the failure reasons from your sending platform. Read a few actual responses, especially from the domains where failures increased.
| What the response indicates | What to do |
|---|---|
| Mailbox does not exist | Suppress the address from future sends. |
| Temporary server problem or rate limit | Let the platform retry according to its policy; investigate if it persists. |
| Authentication failure or sender policy block | Fix the sending setup or reputation problem. The recipient may be perfectly valid. |
| Mailbox full | Follow your platform's handling and watch for repeated failures. |
Platforms group failures into “hard” and “soft” bounces, but their categories can differ. Even a permanent SMTP rejection doesn't always mean the mailbox is nonexistent. The response text and any enhanced status code matter.
There's no bounce percentage that makes every campaign safe. Compare like with like: the same platform, the same kind of send, and the same definition of a bounce. Check your provider's rules too.
Verification is useful when the problem is bad recipient data. If a new import contains misspellings and closed accounts, checking the unsent portion can prevent more failures. If every rejection mentions authentication, cleaning addresses won't fix it.
Keep suppression records in the system that sends your email. Otherwise the next import may bring those addresses straight back.
Check a list before your next campaign
Upload a CSV or Excel file and get a verdict on every address. 100 free credits, no card needed.
Start for freeKeep reading
Keep a contact ID in your verification file
A simple export makes it easier to return each result to the right contact without exposing your whole CRM.
Before you connect an email verification API
Plan for unresolved checks, failed requests and changing addresses before putting verification into production.