Email bounce codes: find the right next step

A campaign label such as “bounced” is a starting point. Open the underlying report and find the message, recipient and time to which it belongs. Save the original evidence before editing the contact or campaign. If you cannot join the report to a particular submission, record that gap instead of assigning the nearest-looking event.

Microsoft's Exchange Online documentation separates the explanation for the sender from diagnostic details such as the generating server, rejected recipient, SMTP response and original headers. A report can concern more than one recipient. Preserve those individual outcomes rather than giving every address the first error shown.

For a useful investigation, collect the campaign and step, sending account, envelope recipient, original submission time, latest attempt and current queue status. Use the system's identifiers where available. Keep confidential headers and contact details in the authorised support record; share only the fields needed for the investigation.

This guide begins when you have a delivery failure or delay to interpret. If the only observation is a low reply count, use the broader troubleshooting guide first. If the task is approving a list before import, use List Verification. Neither observation should be relabelled as a confirmed bounce.

SMTP replies use three digits, such as 452 or 550. RFC 5321 distinguishes temporary negative replies beginning with 4 from permanent negative replies beginning with 5. A permanent reply does not invite the identical request to be repeated unchanged.

Enhanced status codes add a dotted class, subject and detail, such as 5.1.1. RFC 3463 distinguishes temporary conditions from failures unlikely to resolve while the message or destination remains unchanged. The additional digits narrow the reported issue; they do not replace the accompanying explanation.

Keep the raw code strings intact. A sending tool's hard/soft label may simplify several conditions into one category. Before using it to remove a contact or restart a campaign, check how that product defines the label and what the actual report establishes.

The example below is an invented message/delivery-status part, not a complete email or a report from Inbox Leads. Its domains, recipient, wording and times are fictional. The retry deadline illustrates one configured queue policy; it is not a recommended or universal retry period.

Read Action with Status. Under RFC 3464, delayed means further attempts are intended; failed means the reporting system has abandoned them. A failed report can still carry a 4.x status when a temporary condition outlasts the retry policy. The first digit alone cannot tell you that mail remains queued.

Before acting on an old delay notice, check the latest sender record. The queue may have progressed while someone was reading the email. Record the time of that check and the owner who made it, so another operator does not launch a second submission based on stale evidence.

Use the code to narrow the next check, then verify the explanation against the receiving system's current documentation. Google's published examples distinguish 550 / 5.1.1 for a missing account, 452 / 4.2.2 for storage exhaustion and 421 / 4.7.28 for rate-related restrictions. These are specific examples, not a dictionary for every receiving service.

The table turns those observations into operating questions. Assign a responsible person and preserve the original result. If the code, text and log appear inconsistent, escalate the complete record; do not choose the interpretation that makes it easiest to continue sending.

Establish which system owns retries for the original submission. An operator may see a delay in a sending tool while the transport already has a later attempt scheduled. Manually pressing send again can create a separate message with its own future attempts. Check the tool and transport behaviour rather than assuming that one visible button controls both.

Use a short event timeline. The fictional example below continues the report above and records the outcome at three review points. It keeps the original message identity throughout; the count of attempts does not become a count of three different messages.

If the system has abandoned delivery, close that original attempt history accurately. Any later submission needs its own decision: what changed, why contact remains appropriate, and how duplicates will be prevented. Preserve exclusions and recipient stop requests even when a technical condition has been corrected.

You do not need to invent a universal retry interval to operate this process. Record the actual service policy, the receiver's documented response and the next review time. Where a pause or cancellation is required, verify the resulting queue state instead of stopping at the control's label.

A misspelled recipient needs a different owner from a route-wide configuration fault. For a contact issue, check the source record, explain any correction and apply the appropriate exclusion or hold to future imports. Do not generate nearby address guesses and send until one is accepted.

For a sending issue, give the technical owner the smallest useful evidence set: the affected route, representative message, exact diagnostic, first observed time and recent changes. Identify whether it affects one destination, one account or a wider group. That scope determines what should pause and what evidence the repair must produce.

Keep the repair decision separate from the commercial decision to contact someone. A working address is not evidence of relevance or a reason to disregard a stop request. Similarly, a repaired authentication setting does not justify automatically releasing every held campaign without reviewing its own state.

Write an acceptance condition before the change. “The documented fault is corrected and an authorised controlled check behaves as expected” is more useful than “the dashboard looks better”. Name who can approve the next step and what would cause the hold to remain.

After an authorised correction, use a controlled check appropriate to the fault. Record the message version, route, test recipient you are permitted to use, time and observed result. If the symptom remains, retain that result and return it to the owner. Avoid changing several unrelated settings merely to obtain a different outcome.

A successful check supports a narrow conclusion about the setup tested. It does not establish inbox placement for the whole audience or prove that every old contact can now receive mail. Use the delivery-versus-placement guide when reporting destination evidence, and the authentication guide when examining message identities.

Keep the earlier failure in the incident history. A new successful message is a new observation, not a reason to rewrite what happened to the original submission. This also makes team handovers clearer: another operator can see the problem, the correction and the verification without reconstructing them from chat messages.

Finish with a useful operational note: what was affected, what was corrected, which queue entries remain held, and who will review the next eligible activity. If evidence is still missing, name it. An unresolved case with a clear owner is more actionable than a favourable status with no explanation.

Copy this record into your team's working notes. Use references to controlled logs rather than pasting unnecessary personal information into a shared document. Update the record when a later event changes the queue outcome, and keep the earlier review timestamp available.

The worksheet is complete when someone else can understand the original observation, reproduce the key checks and identify the next permitted action. It is a way to organise a real investigation, not a substitute for the system's delivery history.