What is a bounce-back email?

A bounce-back email is a delivery-status notification or non-delivery report generated after a sending system cannot complete delivery. It should include an SMTP reply, an enhanced status code when available, and diagnostic text that identifies the next investigation.

Is a 550 bounce always an invalid recipient?

No. 550 can occur at different SMTP stages and may accompany address, relay, policy, authentication, or reputation-related text. Use the enhanced code, transaction stage, and provider explanation before deciding that an address is invalid.

Should a sender retry a 4xx bounce?

Yes. A 4.x.x status is a persistent transient failure, so the sender should use its bounded retry policy and retain the original evidence. Do not reuse the exact interval from another sender without confirming your own sending platform's behavior.

Does a 250 response prove inbox placement?

No. A 250 response means the receiving SMTP server accepted responsibility for the message. It does not prove that the message reached the inbox, avoided later filtering, or was read by the recipient.

Can an Email Security Score fix a bounce?

No. It can review public SPF, DKIM, and DMARC configuration for a domain-level issue. It cannot change DNS, validate a recipient mailbox, reproduce a receiver's private policy, or repair a message automatically.

Bounce-back email: how to read the error and fix the cause

A bounce-back email is a delivery status notification that says the receiving system did not accept or could not deliver a message. Start with the unaltered notification, not the subject line. The SMTP reply class tells you whether the condition is temporary (4xx) or needs a change before retrying (5xx); the enhanced status code, remote server, and transaction stage tell you what to investigate. Fix only the cause supported by that evidence, then send a new test through the same route.

Quick takeaways

Preserve the original delivery-status notification, including the enhanced code and remote host.
Treat 4xx as a temporary condition and investigate the sender's retry behavior. Treat an unchanged 5xx as a request that needs a change before another attempt.
The middle digit of x.y.z groups the failure: address (x.1.x), mailbox (x.2.x), system (x.3.x), routing (x.4.x), protocol (x.5.x), content (x.6.x), or policy (x.7.x).
A recipient address failure, full mailbox, routing failure, and policy rejection do not have the same owner or repair.
Do not suppress an address, change DNS, or relax a policy from a generic "550" label alone.

What does the failure mean?

A bounce notice may be generated by your sending service, a relay, or the recipient's system. Gmail tells senders to open the delivery-status notification and use the error message to identify the specific problem. Google's bounce guidance separates invalid addresses, temporary inbox problems, storage limits, message filtering, sending limits, and HELO or EHLO errors.

Copy these four fields from the original notice: the basic SMTP reply, the enhanced status code, the reporting or remote MTA, and the diagnostic text. Also keep the recipient domain, timestamp, Message-ID, sending application, and any provider reference URL. Microsoft Exchange Online's non-delivery details report exposes error codes, counts, and sample message IDs so an administrator can group the same failure without losing the individual evidence.

Final-Recipient: rfc822; recipient@example.net
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.net
Diagnostic-Code: smtp; 550 5.1.1 Recipient address rejected

This is a redacted example, not a record to copy into DNS or a rule to apply automatically. In this example, 5.1.1 points to a destination mailbox address problem. It does not prove whether the address was mistyped, removed, or rejected by a recipient-specific rule.

What usually causes it?

RFC 5321 tells SMTP clients to interpret the first digit when a reply is unfamiliar. RFC 3463 adds the class.subject.detail structure used in delivery-status reporting. Read them in this order:

4.x.x is a persistent transient failure. The message may succeed later, so inspect queueing and retry behavior before declaring the recipient bad.
5.x.x is a permanent failure for the message in its current form. Identify the necessary change before retrying.

Address evidence: `x.1.x`

5.1.1 means the destination mailbox address does not exist. The notification can identify a typo or a deleted mailbox, but it can also provide less precise recipient-side text. Confirm the address before suppressing it.

Mailbox or destination capacity: `x.2.x` and `x.3.x`

x.2.x concerns mailbox state, while x.3.x concerns destination system state. A full mailbox is x.2.2; RFC 3463 describes it as persistent transient, so the leading class still determines whether the sender should retry.

Routing or connection evidence: `x.4.x`

x.4.x points to routing, directory, connection, congestion, or delivery-time evidence. It needs the named destination and route, not a generic list-cleaning action.

Protocol or content evidence: `x.5.x` and `x.6.x`

x.5.x covers SMTP protocol failures and x.6.x covers message content or media failures. The sending application, relay, command, or message construction is the relevant evidence owner.

Security or policy evidence: `x.7.x`

x.7.x covers security or policy status. It can name an authorization, authentication, content, reputation, or recipient-policy question, so the full provider text determines the repair.

The basic code is not a diagnosis by itself. RFC 5321 permits several error replies at different SMTP stages, and a provider can add its own explanatory text. Preserve that text rather than reducing every event to "hard bounce" or "soft bounce." For a narrower classification reference, see soft bounce vs hard bounce.

How do I diagnose the failure?

1. Preserve the original notification

Keep the DSN or SMTP log, enhanced status, remote MTA, diagnostic text, recipient domain, timestamp, Message-ID, and sending application together. A subject line such as "message failed" is not enough evidence to repair a route or suppress an address.

2. Identify the reply class and transaction stage

Mark the event 4.x.x or 5.x.x, then determine whether the failure happened during connection, MAIL, RCPT, or DATA. That separates a temporary queue decision from a change the sender must make.

3. Match the enhanced subject to the evidence owner

Use x.1.x for addressing, x.2.x or x.3.x for mailbox and system state, x.4.x for route evidence, x.5.x or x.6.x for the sending path, and x.7.x for the named policy.

4. Check the provider's exact guidance

Follow the reference URL and text in the notice when the receiver provides it. Compare a repeated failure by the exact code, domain, sending route, and provider rather than assuming two 550 replies have the same cause.

Start with the unaltered DSN or SMTP log
|
|-- 4.x.x? --> Keep the message in the sender's bounded retry path.
|              Check whether the same route later reaches 250 acceptance.
|
`-- 5.x.x? --> Read the enhanced subject and the diagnostic text.
                |
                |-- x.1.x address --> Confirm the recipient address with its owner.
                |-- x.2.x mailbox --> Wait for recipient or administrator action.
                |-- x.3.x / x.4.x --> Check the named route, DNS, or remote service.
                |-- x.5.x / x.6.x --> Repair the sending application's protocol or message.
                `-- x.7.x policy --> Identify the named policy before changing identity or content.

This tree assigns the first investigation. It does not replace the recipient's policy, a provider's detailed error reference, or evidence from the original message path.

How do I fix it?

Address evidence: `5.1.x`

Correct a spelling error or confirm the current address with the recipient. Do not change the recipient domain's DNS, and do not immediately suppress every address that returns a 550. A destination address can be invalid, but a recipient-side policy may also use a broad rejection code. For repeated confirmed invalid-address responses, follow your documented list-hygiene and consent policy.

Mailbox or destination capacity: `4.2.x`, `5.2.x`, or `x.3.x`

Leave the recipient's storage or disabled account to the recipient or its administrator. Google notes that a recipient who is out of Google storage must clear space before receiving new mail. A temporary service or inbox issue should remain in the sending system's retry path rather than triggering a permanent suppression decision.

Routing or connection evidence: `x.4.x`

Check the exact recipient domain and the route named in the failure. Confirm MX resolution, the selected target, and whether the failure occurred before the recipient accepted the message. A no MX record found bounce needs DNS and SMTP route evidence; it is not repaired by changing SPF, DKIM, or DMARC.

Protocol or content evidence: `x.5.x` or `x.6.x`

Repair the sending application or relay path that produced the rejected command, argument, recipient count, format, or message size. For example, Gmail documents that an invalid HELO or EHLO argument needs the sending server to present a valid fully qualified name or IP-address identity. Test the same application and relay that produced the failure, not a personal mailbox that bypasses that path.

Security or policy evidence: `x.7.x`

Read the full provider text and linked guidance before changing authentication, volume, links, or content. The x.7.x family includes security and policy status, but it does not prove an SPF, DKIM, or DMARC failure on its own. When the evidence names a public domain-authentication or configuration issue, Palisade's Email Security Score can inspect public domain configuration. Use the Email Security Score as the contextual next action. It cannot validate a recipient address, reproduce a receiver's private policy, or explain every message-level rejection.

If the bounce points to an authentication result, compare the sender's published records with DMARC requirements before making a controlled change. Keep changes to DNS, sending platforms, and enforcement policies under human review.

How do I validate the repair?

After a repair, submit a new controlled message from the same sending application, authenticated domain, envelope sender, relay, and recipient-provider path. Compare the new SMTP result with the original stage and code. A 250 response means the next SMTP server accepted responsibility for the message; it does not prove inbox placement or a reader action.

For a transient condition, review the sender's queue after its normal retry interval and retain the raw status text. For a permanent condition, verify the changed address, route, application, or policy with a fresh message. Store the before-and-after code, Message-ID, provider reference, and recipient-provider result together so a later recurrence can be compared by exact evidence.

The email deliverability guide contains focused guides for the message, DNS, and authentication failures that this broad diagnostic flow can uncover.

Bounce-back email: how to read the error and fix the cause

Quick takeaways

What does the failure mean?