Email Bounce Back Guide: Hard vs Soft Bounces, Suppression, and Recovery

An email bounce back is a notice that a message could not be delivered to one or more recipients. Before resending, check the recipient address, the error, and whether the sending service has stopped trying. A misspelled address needs a correction; a temporary delay may already be in the provider's retry queue.

A hard bounce usually means a permanent rejection of the message as submitted. A soft bounce describes a temporary delivery problem. Those labels are useful, but the delivery report contains the detail you need to decide what to do next.

What an email bounce back means

Your mail app may call it an undeliverable message, a non-delivery report, or a delivery status notification (DSN). Open the details or original message source if the visible notice only says delivery failed. For an application send, find the matching message in your provider's delivery log.

A failed submission and a later bounce reach you differently. An SMTP server can reject a message during the send, while a service that has already accepted it can report a subsequent failure by email or an event. A successful API submission alone does not establish delivery to the recipient. SMTP delivery responsibilities explain this distinction.

Read a bounce-back message

Suppose you send a message to two colleagues: one address no longer exists, and the other mailbox is full. This synthetic example shows the message/delivery-status part of a DSN, with one block for each recipient:

Reporting-MTA: dns; outbound.example.com

Final-Recipient: rfc822; alex@example.net
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 Mailbox does not exist

Final-Recipient: rfc822; sam@example.net
Action: delayed
Status: 4.2.2
Diagnostic-Code: smtp; 452 4.2.2 Mailbox full

Read each block separately:

• Final-Recipient identifies the address this result applies to. If forwarding changed the address, also check Original-Recipient when present.
• Action tells you what the sending system is doing: failed means it has stopped trying; delayed means attempts will continue.
• Status describes the condition using an enhanced status code, such as 5.1.1 for a nonexistent mailbox or 4.2.2 for a full mailbox.
• Diagnostic-Code, when supplied, preserves the transport's more detailed explanation. Keep the whole value when asking an administrator for help.

Here, correct or suppress Alex's invalid address. Sam's message remains pending, so sending another copy could create a duplicate when the mailbox becomes available. The field definitions and separate recipient blocks come from the DSN format.

Hard bounce vs soft bounce

The first digit of an SMTP rejection distinguishes temporary 4xx from permanent 5xx responses. Enhanced codes such as 4.2.2 or 5.7.1 add detail. Do not interpret every 550 as an invalid address: permanent rejection can also concern sender policy or message content.

Reported condition	What it means	What to do
5.1.1	The destination mailbox does not exist	Stop sending to that address and obtain a correction
5.7.1	Delivery is not authorized or the message was refused	Read the diagnostic and investigate the stated policy
4.2.2	The mailbox is full	Check whether the provider is still retrying
4.4.1	The sending system could not reach the destination host	Check the provider's delivery log and the affected domain

These meanings follow the enhanced status code definitions. Providers may group their bounce events differently, so keep the original code and explanation alongside the provider's label.

A temporary error can become a final failure

Status: 4.2.2 alone does not tell you whether another attempt is scheduled. A provider can eventually give up on a temporary problem and issue Action: failed. The DSN specification explicitly allows a 4.x.x status with either delayed or failed.

Check the action and the provider's current message status before resending. When the provider still owns the queued message, let its retry policy run. If delivery has ended, resolve the cause and decide whether the message is still useful: a password-reset link may have expired while a receipt can still be needed.

Bounce triage workflow

Start with the failed recipient and diagnostic from the report. Then compare other failures from the same send. One bad address suggests a different investigation from every recipient at one domain failing after a sender change.

Invalid recipient

Compare the failed address with the address the person supplied, including spelling and the domain. For a confirmed nonexistent mailbox, suppress further sends to that address and ask for a correction through another available contact method. Do not guess a nearby address and send someone else's message to it.

A permanent policy rejection needs a separate response. Suppressing every recipient behind a 5.7.1 error can remove valid contacts while leaving the actual sender problem untouched.

Several recipients fail with the same error

Read the receiver's diagnostic before changing DNS or message content. If it names an authentication failure, check the sending domain's SPF, DKIM and DMARC alignment. If it names a size limit or blocked attachment, address that message requirement instead.

Compare the affected domain, sending service and message type with successful sends. A recent relay or DNS change is useful evidence; a bounce spike by itself does not identify its cause. Give your mail administrator the original diagnostic and the provider's message reference so they can investigate the same attempt.

Test suppression and recovery separately

A corrected send tests delivery. It does not show that your application stops retrying an invalid recipient or handles a delayed event correctly. Reproducing those cases with ordinary customer addresses is unreliable because you do not control the receiving server's response.

MailSlurp is an email testing platform with SMTP inboxes and rules that simulate temporary and permanent rejections. Use the bounce simulation example to exercise both responses, remove the rule, and check that a subsequent message arrives. For MailSlurp send events, the account-webhook guide explains how to receive bounce notifications.

How to prevent email bounces

Check addresses when people enter them and let them correct obvious mistakes. Email address verification can identify some address and domain problems before a send, while delivery events tell you what happened to the actual message. Keep confirmed invalid addresses suppressed, and test sender-domain changes with a controlled recipient before using them for customer messages.

What if you receive a bounce for an email you never sent?

Check your sent folder and sending service's logs before treating it as one of your failures. A delivery notice can be forged, and a forged sender address on someone else's message can direct a real notice to you. Do not suppress a contact or change credentials solely because an unexpected bounce asks you to; investigate it through your mail service. The DSN security discussion describes this risk.