The reply is evidence, while the dashboard label is an interpretation
Sending platforms often reduce delivery events to ‘soft bounce’, ‘hard bounce’ or ‘blocked’. Those labels can help with list management, but they are not the protocol reply. Preserve the three-digit SMTP code, any dotted enhanced status code, the receiver’s text, the time, recipient domain, sending route and message identifier.
The useful reframe is that a bounce describes a transaction. RFC 5321 defines replies beginning with 4 as transient negative completion and replies beginning with 5 as permanent negative completion. RFC 5321 Permanent means the same request should not simply be repeated unchanged. It does not mean the person or domain can never receive mail again.
RFC 3463 adds an enhanced status code with class, subject and detail components. RFC 3463 A reply such as 550 5.1.1 therefore contains two related codes plus explanatory text. Keep all of them. Receiver-specific text can point to authentication, policy, content, rate or account issues that the broad class cannot distinguish.
Save the complete event before any retry
Export the delivery event or save the delivery-status notification. Record the UTC timestamp, sender feature, campaign or transaction ID, recipient domain, sending IP if shown, envelope sender domain, full reply and queue state. Identify whether the failure came during connection, recipient acceptance, message acceptance or after an earlier successful hand-off.
Check whether your service is still retrying. RFC 5321 expects queued mail to be retried after delays and eventually returned or expired according to queue handling. SMTP queue handling Starting a fresh send while the original remains queued can create duplicates if both later succeed. Pause new attempts until you know the state.
A bounce can contain recipient addresses, original subjects, message fragments and internal hosts. Keep the unredacted copy in a restricted incident location. Share a redacted extract that preserves codes, timestamps and route identifiers but removes unrelated personal or confidential data.
If the event does not match an outbound message in your system, stop. Do not click repair links in an unexpected notification. Open the known provider console independently and investigate whether the report is delayed, forged or belongs to another account.
Read the code, the words and the point of failure together
Begin with the first digit. A 4xx reply says the requested action did not happen now but may succeed later. A 5xx reply says the request was not accepted and should not be repeated in the same form. Then read the enhanced code. Its first digit carries a similar success, temporary or permanent class, while later digits narrow the subject and detail. Enhanced status-code structure
Do not force mismatched information into a generic rule. A receiver may return a broad SMTP code with more specific text, or your platform may show the final event after its own retries have expired. Keep the raw reply and ask the provider how its dashboard classification was produced.
Notice when the receiver accepted responsibility. An SMTP success means the receiving system accepted the message for delivery, not that it reached an inbox or was read. A later delivery-status notification can still report a downstream failure. Conversely, a rejection during SMTP is not evidence about inbox filtering because the receiver never accepted the message.
This distinction prevents content changes being applied to nonexistent-address errors and DNS changes being applied to post-acceptance placement complaints.
The same five-digit code can mean something different depending on where it appears and which RFC it follows, and the human-readable text beside it is often the more useful part. A 550 with the word 'policy' points to an authentication or recipient decision, while the same class with a specific sub-code can describe greylisting or a content block. Read code, words and the point of failure together before you decide which system owns the fault.
read a full email headerFind the scope before deciding who owns the fault
Group events by recipient provider, reply text, sending IP, application route and time window. One 5.1.1 for one address has a different owner from every invoice failing at one provider after an authentication change. A mixture of codes should remain separate groups rather than being averaged into a campaign bounce rate.
Compare a known working event from the same route. If only one mailbox fails, verify the address through an existing authorised channel. If one receiver domain fails, check that receiver’s official guidance and your provider’s event logs. If every destination fails from one application, inspect that application’s hand-off and authentication. If all routes fail, look for shared DNS, account, billing or platform changes.
Assign an owner to each group: list administrator for confirmed invalid destinations, DNS or messaging owner for authentication, application owner for malformed messages, sending provider for queue and network behaviour, and security owner for suspected compromise.
Do not rotate domains, IP addresses or From addresses to get around policy responses. That hides the evidence and may worsen reputation. The trade-off in pausing traffic is delayed communication, but uncontrolled sending can multiply failures and duplicates. Use another established business channel for urgent contact while the route is contained.
Where invalid or risky addresses recur, integrate a cleaner into your workflow with email list verification guidance before the next send.
Match common code families to a bounded action
Addressing failures: RFC 3463 describes X.1.1 as a bad destination mailbox address. RFC 3463 mailbox status Suppress the exact address from the affected list and seek correction through an authorised route. Do not guess another person’s address.
Mailbox capacity: X.2.2 describes a full mailbox and is associated with persistent transient treatment in the standard. Preserve the actual class the receiver sent. Let the provider manage permitted queue attempts rather than launching manual duplicates.
Routing or system trouble: X.4 subjects relate to network or routing status, while X.3 concerns destination system status. Check whether the effect is provider-wide before changing content or recipients.
Security or policy: X.7 covers security or policy status. Authentication failure, unauthorised delivery and content policy need different remedies, so retain the detail and receiver text. A 5.7.1 does not prove the mailbox is nonexistent.
Codes guide triage; they do not replace the receiver’s current documentation or the evidence from your exact event.
When the reply points to a published SPF fault, use the guide to repair a broken SPF record safely before retrying the message.
Choose one reversible correction owned by the affected route
Write a hypothesis that connects the evidence to the change. Examples include ‘the address was confirmed obsolete’, ‘the invoice service used an unauthorised envelope identity’, ‘the receiver deferred this IP and the provider is controlling its queue’, or ‘the application generated an invalid recipient’.
For an invalid address, suppress it and preserve the source of the correction. For authentication, inspect the failed message identities and provider configuration before editing DNS. For a temporary deferral, ask the sending provider for queue age, retry schedule and expiry; reduce new traffic where needed. For receiver policy, use the official URL or diagnostic token in the reply and involve the provider.
Record the old state, proposed change, approver, time and rollback condition. Make only the correction supported by the group. Deleting a list because one mailbox failed loses legitimate contacts. Adding an IP because an error mentions it can authorise the wrong service. Repeatedly resending a 5xx request without a change contradicts the protocol meaning and can create noise. SMTP reply semantics
Stop if the owner, route or meaning remains uncertain. Escalate with the untouched response rather than experimenting in production.
Run one controlled check after the cause changes
Confirm the original event is no longer queued. For a route-level repair, send one plain, non-sensitive message through the same application, account, envelope configuration and visible From address to a mailbox you control at the affected receiver. For a corrected recipient address, obtain the correction first and avoid using a customer as a technical test target.
Record whether the receiver accepts the message, the new reply if it does not, and the provider event ID. If authentication was involved, inspect the delivered header and compare SPF, DKIM and DMARC results with the failure. If a temporary deferral was involved, let the managed queue operate and verify that the original event either succeeds once or expires cleanly.
The same-route requirement matters. Success from a staff mailbox does not prove a website form is fixed, and acceptance by one provider does not prove the provider named in the failure now accepts. Also verify that ordinary traffic on an adjacent working route remains unchanged.
If the code changes, preserve the new event and reconsider the hypothesis. It is progress only in the sense that the receiver supplied different evidence; it is not permission to make several more changes at once.
Close on evidence, or escalate before risk spreads
Close the incident when the original queue state is known, the affected scope is documented, the owned correction is recorded, a same-route check produces the expected result and suppressions remain intact. Note any later monitoring date. Acceptance proves hand-off, not inbox placement, so keep placement complaints in a separate investigation.
Escalate to the sending provider with UTC times, event IDs, recipient-domain groups, full redacted replies, route identities, queue state and the one correction tried. Ask a specific question about the code and hand-off it controls. Escalate internally if the failure affects safety-critical or contractual messages, personal data is exposed, or a DNS change could disrupt several systems.
Stop all manual retries if the original is still queued, failures spread quickly, a suspected compromised account is sending, or you cannot distinguish a temporary reply from a platform’s final classification. Preserve evidence and contain the affected stream.
The cost of waiting for evidence is visible delay. The benefit is avoiding duplicates, accidental authorisation and damage to working routes. A bounce is resolved by explaining and verifying the transaction that failed, not by making the warning disappear from a dashboard.