A bounce is a diagnosis, not a verdict.

“Bounced” sounds like a completed diagnosis. In many dashboards it is only a drawer containing several different facts: the mailbox may not exist, the receiving server may be busy, the message may be too large, authentication may have failed, or a policy may have rejected the sender. The drawer is useful for counting. It is dangerous for deciding.

Imagine a hospital that replaces every test result with one word: unwell. The label is true, but it destroys the part that determines what happens next. Email software often does the same thing when it turns every 5xx response into “bad contact” or every temporary failure into a fresh send.

A bounce is not an opinion about a person. It is evidence about one delivery attempt.

This distinction follows the message past the acceptance receipt described in Delivery is a receipt, not a result. Acceptance, temporary delay, final failure, inbox placement, and attention are separate facts. Keeping them separate is the beginning of useful deliverability evidence.

A structured Delivery Status Notification describes the result per recipient. Its Action says what the reporting mail transfer agent did. Its enhanced Status classifies the condition. Its raw Diagnostic-Code preserves the provider’s explanation. Each answers a different question.

RFC 3464 is unusually practical here: a delayed report is not a reason to remove a subscriber. It also cautions that even permanent-looking failures can sometimes come from a temporary condition. Preserve the original recipient and diagnostic instead of forcing imperfect evidence into a confident label.

The second number in an enhanced status code is especially revealing. X.1.x concerns addressing; X.2.x, the mailbox; X.4.x, routing or network conditions; X.6.x, content or media; and X.7.x, security or policy. “Permanent” does not automatically mean “recipient does not exist.”

SMTP calls a 4xx reply a transient negative completion. The requested action did not happen, but the same request may work later. A busy receiving server, temporary routing failure, full mailbox, or rate limit can all live in this family. The correct response is time, not force.

Your mail provider normally owns that retry loop. Do not react to one delay event by submitting a second application message while the original remains queued. That recreates the duplicate-send risk from A retry is not permission to send twice, only one layer later.

1. 01

   Keep one message identity

   Retries belong to the existing recipient attempt, not a newly manufactured email.

2. 02

   Back off by destination

   A receiving domain asking for less pressure should not be answered with more parallel connections.

3. 03

   Give the message an expiry

   A security code may become useless in minutes; a receipt can tolerate a longer delivery window.

4. 04

   Escalate the pattern

   A sudden cluster of deferrals deserves domain and stream diagnosis, not thousands of identical retries.

Google’s current sender guidance makes the same operational point at the traffic level: when messages begin bouncing or being deferred, reduce volume until SMTP errors fall, then increase slowly. Retry policy and sender reputation meet at the receiving server. Backoff is part of deliverability.

A 5xx reply means the exact SMTP request should not simply be repeated. Something must change. The popular mistake is assuming that something is always the recipient address. The enhanced code tells you where to look.

Yahoo’s published error guidance illustrates why the distinction matters. Its permanent errors can reflect an invalid address, failed authentication, rejected content, reputation, or another policy condition. One response class contains several owners and several remedies.

An invalid destination should stop future attempts to that address. A policy rejection should pause or repair the affected stream, identity, or domain. Deleting contacts in response to a sender-side fault hides the fault and shrinks the audience without solving it. Repeating the unchanged message ignores the receiver and may make the fault worse.

Suppression is often stored as one boolean. That is enough to stop a send, but not enough to understand why it stopped or whether a corrected address can safely return. A useful suppression record keeps its evidence attached.

Recipient

The exact original and normalized address affected by the delivery result.

Reason

Invalid mailbox, complaint, unsubscribe, policy hold, or another distinct cause.

Evidence

Action, enhanced code, raw diagnostic, provider, and message identity.

Time

When the failure occurred, when the state changed, and whether review is due.

Scope

The workspace, channel, stream, or address to which the decision applies.

Correction

Who changed the address or state, what they verified, and what superseded the old evidence.

This is where delivery data becomes audience state. The Moosewave audience system resolves suppression before a campaign or automation sends, while the field note on who you leave out explains why that decision belongs before creative work.

During a platform migration, carry suppression reasons and provenance, not only a flat list of addresses. Otherwise a careful historical decision arrives in the new system as an unexplained prohibition, or disappears and exposes the address to another send.

The first view of a bounce belongs to one recipient. The next view belongs to the system around it. Ten nonexistent addresses from one imported list point toward acquisition quality. A wave of 4.7.x deferrals at one mailbox provider points toward traffic, reputation, or policy. One content rejection across every domain points back to the template.

Group outcomes by mailbox provider, sending domain, IP, message stream, template, campaign, integration, and acquisition source. Compare counts with rates and rates with enough volume to mean something. The honest question is not merely “How many bounced?” It is “Which condition changed, for whom, and after what?”

This is why sender reputation is better understood as memory than as a universal number. The history described in Sender reputation is memory, not a score accumulates from the choices around each failure. The analytics workspace makes those patterns visible without pretending that one aggregate can explain every receiver.

Connected data matters too. A corrected account email, CRM update, support conversation, and commerce event should not become competing truths. Moosewave’s integrations preserve the source and chronology of those changes so an automation can respond to current evidence.

The useful default is deliberately small: wait when the mail system is still trying, retry only when a transient window has ended and the message remains useful, repair sender-side faults, and suppress confirmed invalid destinations. Ambiguity gets a visible review state.

Delivery events can arrive more than once or out of order. The previous field note, A webhook tells you what happened, explains how to verify, deduplicate, acknowledge, and reconcile that evidence. This table begins after the event is trustworthy.

Moosewave keeps delivery state per recipient, even when one API request or campaign contains many. Every outcome retains its original event, provider message ID, action, normalized enhanced code, raw diagnostic, attempts, timestamps, and decision history. One failed recipient never erases the successful or delayed states of the others.

Transient failures remain on the existing message timeline while bounded provider retries continue. Confirmed invalid destinations create an attributed audience suppression before another sending path can reach them. Content and policy failures open repair work against the message or sending identity instead of blaming the recipient. Unknown evidence remains visible for review.

Those states are shared with lifecycle automations, audiences, analytics, and every connected source. A flow can exit a suppressed address, pause a troubled domain, or wait for a corrected profile without inventing a second version of what happened.

Open the interactive product walkthrough to follow a send from intent through delivery evidence and audience state. Good bounce handling does not make failure disappear. It makes the next decision proportionate to what the receiver actually said.