LIST QUALITY
High Email Bounce Rate: Find Invalid and Outdated Addresses
A rising bounce rate can make an entire list look unusable. Yet a bad address, a temporary delay, and a policy rejection call for different fixes. Read the failures before you delete contacts or retry the campaign.
Make sure the rate means what you think
Break a mixed North American and European list down by source, country, and receiving provider. Country alone doesn’t explain a bounce: an outdated job record and a provider policy rejection need different fixes. Keep the same attempted-message denominator and reporting window for each segment so the comparison doesn’t mistake different list sources for a regional deliverability problem. Keep invalid-address suppression in the shared system, and test that CRM syncs and new imports cannot silently add excluded contacts back.
Write down the reporting window and denominator used by your platform. For an internal review, you can count unique recipient-message attempts that failed and divide by unique recipient-message attempts. Don’t count every retry as a new contact. Keep temporary delays separate from final failures.
Give pending messages time to reach their final status. A temporary delay doesn’t tell you the mailbox is invalid. If the platform later updates the event, show that change clearly instead of counting the attempt and the final failure as two new contacts. Otherwise the report can make a small set of problems look much larger than it is.
Show how many messages failed and how many people were affected. A person receiving several follow-ups can appear in more than one event. Our metrics guide explains how to keep those measures separate. Put the reporting period and denominator beside the rate, and include failed sends when you work out what the campaign cost.
Read the reason behind the bounce
The enhanced mail status-code standard distinguishes temporary failures (4.x.x) from permanent failures (5.x.x). A 5.1.1 indicates a bad destination mailbox; security or policy errors use the x.7.x family. A policy rejection isn’t proof that an address doesn’t exist.
- Confirmed invalid mailbox: suppress it from sending and record the reason.
- Policy rejection: investigate the sender or recipient policy rather than marking the contact invalid.
- Temporary delay: follow the sending system's retry policy; do not repeatedly resubmit the same campaign.
- Unclear response: preserve the full diagnostic and ask the provider to interpret it.
The error should lead you to the next check. An invalid-mailbox response points to the contact record. An authentication failure points to the setup. A policy rejection may mean a conversation with the provider about the sending activity. ‘Hard bounce’ is a useful platform label, but it’s too broad to decide which of those jobs you need to do.
Ask how your tool handles retries and where it shows the final result. Don’t keep manually resending the same failed message while you’re unsure of the cause. That can create duplicate traffic and make the history harder to follow. Save the message identifier and time instead, so support can find the exact event rather than guess from a campaign total.
Trace bad records back to their source
Group failures by import file, collection date, and source. Check for typing mistakes, old employee records, duplicates, and transformations introduced by a spreadsheet export. A validation result shouldn’t be treated as permission to contact someone or as proof of business relevance.
Trace bad records back to the file they came from. Look for old employee addresses, guessed address patterns, duplicates, and mistakes introduced during export. Open a few rows before importing a repaired file. A spreadsheet change can accidentally merge fields or alter addresses, even when the person making it only intended to tidy the data.
Verification can help you find unusable addresses. It won’t establish that the remaining people want your message, or that you may send it. If you’re working from an old campaign export, read the old-list re-engagement guide before treating a cleaned file as a fresh audience ready for outreach.
Keep removed contacts from coming back
Keep suppression separate from a campaign list so deleting a campaign doesn’t erase it. On every import, reconcile against opt-outs and previously confirmed invalid addresses. Test that process with controlled records before restarting.
Assign one person to approve a cleaned batch and record what was excluded. If the remaining failures cluster at one recipient provider, investigate that route before buying another list. A larger list won’t explain a rejection code.
Look at the cleaned group separately and explain what changed. Did you remove invalid records, repair an import, or fix a sender configuration? A lower rate after removing bad addresses doesn’t prove the whole original list was fine. What matters is knowing the cause you corrected and keeping it from returning through the next batch.
Quick checklist: choose the right fix
| Diagnostic | Recommended handling |
|---|---|
| 5.1.1: bad destination mailbox | Suppress the confirmed invalid address; keep its source and diagnostic. |
| 4.x.x: temporary failure | Review the full response and the provider’s retry handling. |
| 5.7.x: policy or security failure | Investigate the policy response; do not label the address invalid from this alone. |
| Unrecognised or contradictory code | Ask the provider to interpret the complete diagnostic before taking bulk action. |
Reconcile final failed messages separately from repeated attempts and queued deferrals. Trace the affected records back to their import source; a temporary provider response should not automatically classify every address as invalid.
The code families come from RFC 3463, linked above, but the provider’s wording still matters. Keep a short sheet with the contact source, import date, error, next action, and person handling it. That gives you a way to fix outdated records without quietly discarding valid contacts whose messages failed for a sender-side reason.
Common mistakes
- Treating every bounce as an invalid address.
- Counting retries as new contacts.
- Accepting verification as permission.
- Allowing cleaned-out records to return through another import.
Start with the error, then fix the part responsible for it. If the list sources, sending tools, and failure reports are hard to untangle, TransmitInbox can help check them together and decide what needs to change.
Example A: 550 5.1.1 — Bad destination mailbox address Example B: 550 5.7.1 — Delivery not authorized, message refused
- Example A points toward an invalid destination address. Suppress the confirmed invalid address.
- Example B is a policy/security rejection. Read the full notice before deciding what failed; this code alone does not prove the address is invalid.
The explanatory text and provider documentation matter. Don’t retry either example blindly.
Source references
Editorial review: October 14, 2026 · TransmitInbox team. Consult the linked documentation for current requirements.