Read delivery errors, separate pending retries from final failures, and decide whether to stop an address, fix a sending route or wait for the original message.
An outreach email fails, and someone on the team clicks send again. Before doing that, check whether the mail service is still trying, whether the recipient address is wrong, or whether your own sending setup needs attention. Those situations need different decisions.
A useful bounce review ends with an owner and a next action. This guide explains the technical signals behind that decision, then proposes a practical workflow for agencies managing several clients or senders. The workflow is an editorial recommendation, not a promise that any provider will accept a message.
Read the full failure, not just “bounced”
Open the original delivery report or your sending provider's message log. Save the message identifier, affected recipient, sending mailbox, time with time zone, current delivery state and complete error text. A screenshot showing only “failed” is not enough to diagnose the cause.
You may see two codes together, such as 550 5.1.1. The three-digit number is the SMTP reply; the dotted number is an enhanced status code. Enhanced codes describe a class of result, a subject and a more specific condition. For example, the X.1.1 family concerns a nonexistent destination mailbox, while X.2.2 concerns mailbox capacity. The actual returned class and diagnostic still matter. RFC 3463: enhanced status codes.
Keep the original error alongside your team's plain-language explanation. “Recipient unavailable” can hide a typo, a full mailbox or a sending restriction, and the next person investigating should not have to reconstruct which one occurred.
First decide whether delivery is still pending
SMTP distinguishes temporary failures, generally reported as 4xx, from permanent request failures reported as 5xx. A temporary failure can be retried; a permanent failure should not trigger repetition of the unchanged request. Correcting the underlying problem can make a later attempt appropriate. These are delivery protocol rules, not a schedule for manually resending outreach. RFC 5321, section 4.2.1.
The delivery report's action adds another piece of information:
- Delayed: the reporting mail system is still attempting delivery.
- Failed: that system has abandoned delivery to this recipient.
- Delivered: delivery is reported, but this does not establish that the person read the message.
A 4.x.x status can appear in a final failed report after the sender gives up retrying. Do not leave a contact marked “waiting” just because the code starts with four. Check the latest action or provider state as well. RFC 3464, section 2.3.3.
While the original message remains queued, pause its outreach follow-up. Ask the mail administrator or provider to confirm retry handling instead of creating a second copy of the same message.
Choose a response from the exact diagnosis
Google's SMTP reference illustrates why one generic “hard bounce” rule is too crude. It lists 550 5.1.1 for a missing account and 550 5.7.26 for several authentication failures. It also distinguishes 452 4.2.2 for storage exhaustion from 552 5.2.2 for a mailbox that is out of storage and inactive. Read the complete diagnostic for your message. Gmail SMTP errors and codes.
Use the following operational decisions after establishing the cause. These are suggested team actions, not additional definitions of the codes.
| What the evidence establishes | Immediate action | Condition for reconsidering |
|---|---|---|
| The destination address does not exist | Stop that address in active sequences; check it against the original contact source | A confirmed correction or replacement address |
| The original message is still queued after a temporary rejection | Hold follow-ups and monitor that message | A final delivery outcome or a provider-directed action |
| Delivery ended because of mailbox capacity | Hold further outreach to that address | Evidence that the mailbox is available and a reviewed resend decision |
| Sender authentication is failing | Pause affected sending and assign the mail administrator | The identified configuration problem is fixed and a controlled test passes |
| The diagnostic identifies a content or recipient-policy block | Stop automatic retries and review the specific rule with the appropriate administrator | The cause is understood and the intended message is allowed |
| The report is incomplete or contradictory | Put the message on hold and request the full provider log | Enough evidence to classify the failure |
Stopping an address does not require deleting the person's CRM record. Preserve the relationship history and mark why that address is unavailable. Keep an explicit opt-out separate: a technical repair is not a reason to reverse someone's request to stop contact.
Check whether several failures share one cause
Before editing a whole lead list, group failures by sending mailbox, route, recipient domain, diagnostic and time window. This is a troubleshooting method: a cluster suggests where to investigate, but does not prove the cause.
If unrelated recipients fail through the same sender after a configuration change, inspect that route first. If one address fails while other messages through the same route succeed, investigate that recipient. Neither pattern warrants guessing replacement addresses or switching identities to get around a rejection.
For an authentication diagnosis, use the email authentication checklist to inspect the sending path. Keep the incident focused on the observed error; do not change unrelated DNS records simply because an email bounced.
Assign one person to coordinate the incident. Other team members should know which mailbox or sequence is paused and where to record new evidence. This avoids several operators independently resending the same failed messages.
An illustrative agency incident
Suppose a fictional agency sees failed messages for three unrelated prospects. Each was sent through one client mailbox after its sending configuration changed. The logs identify the same authentication problem.
The agency pauses that route and holds its scheduled follow-ups. It keeps the contact records intact, assigns the mail administrator and records the affected message IDs. After correcting the configuration, the administrator sends a controlled test to a mailbox the team owns and inspects the result.
Only then does the campaign owner review which failed messages should be sent again. They first check that the provider has no pending copy, that the contact remains eligible for outreach and that the message is still relevant. A successful test supports that narrow delivery check; it does not guarantee acceptance by every recipient system.
If the evidence had instead identified one nonexistent recipient address, the action would have been to stop that address and verify the contact source. This example is fictional and contains no customer performance result.
Keep a small incident record
Use a shared record with these fields:
- Identity: client, sender, recipient and provider message ID.
- Evidence: timestamp, latest state, exact code and diagnostic, with a link to the restricted log.
- Decision: waiting, address stopped, configuration repair or manual review.
- Ownership: responsible person and next review time.
- Resolution: what changed, what was tested and which messages were released or left stopped.
Avoid copying full email bodies or unrelated personal data into a general operations sheet. A short record with a log reference is easier to review and less likely to expose private conversations.
At the next review, reconcile pending incidents with the provider's latest state. A team member should be able to answer three questions without reading an entire support thread: is the original message still being attempted, what condition prevents delivery, and who owns the next action?
