Deliverability
Investigating a sudden rise in bounced emails
Investigate a sudden bounce spike using SMTP replies, recipient groups, sending routes and a controlled follow-up.
When bounces rise suddenly, pause any planned repeat to the affected audience and inspect the receiver’s replies. Establish how many messages were attempted, which failed and whether failures cluster by recipient domain, error text or sending route. A headline rate or a platform’s “hard” and “soft” labels may conceal different causes.
Confirm what changed
Compare attempted-message and bounce counts with a relevant earlier send, using the same platform definitions. Check whether the audience, list source or mix of recipient domains changed.
Note when failures began and whether they coincide with a new import, sending service or authentication change. A problem confined to one recipient domain should not be treated as list-wide without further evidence.
Read the full reply
An SMTP reply starting with 4 is a temporary negative response to a request; one starting with 5 is a permanent negative response to that request. A 4xx response may be retried and need not become a final bounce.
A 5xx response can still identify a correctable configuration fault. Enhanced codes and reply text add detail, while a platform’s bounce category may be approximate.
| Reply pattern | First check | Next action |
|---|---|---|
| Address or mailbox does not exist | Source and age of the address | Suppress addresses confirmed invalid and correct capture errors. |
| Temporary mailbox or server problem | Existing retry status and affected recipient domains | Let the sending service’s managed retry process run; avoid a duplicate campaign. |
| Authentication or policy rejection | The affected route’s From, SPF, DKIM and DMARC identities | Repair the confirmed route or policy fault before retrying. |
| Rate limiting or unusual volume | Timing, volume and the receiver’s stated reason | Follow receiver guidance and the sender’s retry controls. |
These are starting points, not universal meanings for every code. Read the accompanying text.
SMTP Reply Codes: Temporary vs Permanent Bounces
- 4xx Response (Temporary)
- Retry allowed; not a final bounce. May indicate server or mailbox issues.
- 5xx Response (Permanent)
- Final rejection. May require configuration fixes or address suppression.
Find the common factor
Preserve the campaign report and exact diagnostic replies that the platform makes available. Record send time, campaign or automation, recipient domain, sending route, reply code and text, and final platform status. Group these records before changing the setup.
Mailchimp’s guidance says reading bounce headers (SMTP replies) can provide insight into why an address hard bounced. Check your platform’s available reports and capture the details you need while they are available.
Invalid-address replies concentrated after one upload suggest a source-data problem. Similar authentication rejections across campaigns using one service suggest a route problem.
Temporary failures concentrated at one receiver call for receiver-specific investigation and attention to retry state. Verify each hypothesis against the replies.
Check that no retry or new campaign reintroduces unsubscribed or otherwise excluded contacts. Before sending again, check that you have the recipient’s permission and that the message is expected.
Steps to Investigate a Sudden Bounce Spike
- Compare send and bounce counts with a prior campaignUse same platform definitions for consistency.
- Check for recent changes in audience, list source, or domainsLook for new imports or sending service updates.
- Review full SMTP reply text and enhanced codesAvoid relying solely on platform labels like 'hard' or 'soft'.
- Group records by domain, route, time, and error typeIdentify patterns such as authentication failures across one route.
- Verify no excluded contacts are being resentEnsure permission and message expectation are confirmed.
Correct and verify
Record the supported cause, correction and messages still pending. Suppress confirmed invalid addresses, repair configuration faults with the relevant provider, and avoid resending to people already reached.
After the change, inspect the next appropriate send by recipient domain and error type. Compare the underlying audience as well as its bounce rate; a smaller rate from a different population does not alone prove the fault was fixed.
