Treat each bounce as a delivery diagnosis. Start with the recipient-level event, read the server's code and explanation, and decide whether the address is unreachable, the delivery failure is temporary, or the recipient server refused delivery. A bounce is an automated message reporting that a previous message was not delivered or had another delivery problem.1 Feedback can arrive immediately or days later after the sending system finishes its retries.2 One send can bounce for some recipients and be delivered to others.3 Classify the event first, then choose the action. A label alone does not tell you what to do next.
Read the failure in order
Run every delivery failure through the same sequence. Preserve the raw response before assigning a type because its wording often explains what the label leaves unclear.
A message whose From field contains mailer-daemon or Mail Delivery Subsystem can be checked as an automatically generated delivery failure.4 Returned messages may also be called Non-Delivery Reports or Delivery Status Notifications.5
| Stage | What you are trying to learn | Example question |
|---|---|---|
| Confirm the event | Whether this recipient has a bounce event6 | Did this recipient receive the message? |
| Capture the response | The code and explanation returned by the recipient server7 | What code and explanation did the server return? |
| Classify the outcome | Whether the result is temporary or permanent | Is this something that can clear, or does the address require correction? |
| Interpret the cause | What the response says about the address, mailbox, domain, or recipient server | Does the text point to the address, the server, or a delivery policy? |
| Choose handling | Which path this recipient now needs | Should this record be corrected, watched, or held out of routine sends? |
Keep the recipient, response code, response text, and timing together. That record lets you revisit a classification when the server's wording and the platform's label disagree.
Hard bounces
Use this branch when the response points to an address that cannot receive mail on an ongoing basis. Check the address and domain record before changing its sending treatment.
Hard bounces indicate invalid addresses or addresses that do not exist.8 They can also occur when an address or host server no longer exists, or when the address is invalid or misspelled.9
A response that names an invalid mailbox or invalid domain belongs in this branch. Those category names are used for hard bounces.10 An inactive mailbox can mean the address is disabled, abandoned, or no longer exists on the recipient's server.11
Route the record to correction or suppression handling when the response supports a permanent address problem. Keep the server wording with the record so a bad address, a changed domain, and a disabled mailbox remain distinguishable.
Soft bounces
Use this branch when delivery failed for a condition that may clear. The address can remain usable, so check the cause before deciding what happens next.
A soft bounce is a temporary failure affecting a valid email address.12 In most cases, the address is valid, the message reached the recipient's mail server, and that server rejected it.13
Common causes include a full mailbox, DNS problems, and a server outage.14 An email is deferred before it becomes a soft bounce.15 Read the response for the condition that caused the deferral, then give the record a handling path that matches it.
A temporary result still needs a stopping rule. Repeated soft bounces can lead mailboxes to reject email, just as hard bounces can.16
Blocks and response codes
Treat a block as a recipient-server diagnosis and keep it separate from an address-quality diagnosis until you have read the response. The same broad outcome can appear under different category names, so keep the raw code and text attached to the event.
A hard-bounce result can mean that the recipient email server blocked delivery.17 Recipient-server-error is also used as a bounce category.18 These labels describe the handling path, while the server response helps you decide whether the issue is an invalid address, a temporary server condition, or a policy refusal.
The SMTP Enhanced Status Codes Registry supports success, persistent transient failure, and permanent failure classes for delivery and bounce measures.19 For reporting, document how temporary 4.X.X and permanent 5.X.X outcomes enter your classification instead of treating every delivery status as equivalent.20
Read the code with its description and store both with the event. Then map the result to your own hard, soft, or blocked handling path. A code without its explanation can hide why a recipient server refused delivery.
Count the outcome
Use reporting to keep address problems, temporary conditions, and server refusals separate. The count should help you decide what to correct and what to watch.
Hard and soft bounces both affect sender IP reputation because email service providers consider total bounce rate when deciding whether email reaches a user's inbox.21 Total bounce rate is calculated by adding the hard bounce rate and the soft bounce rate.22
Keep the response-code detail beside those totals. A hard or soft rate tells you how much failed, while the code and explanation tell you where to investigate.
What not to do
These mistakes remove the distinctions that make bounce handling useful.
- Using one provider's label as a universal rule ignores that ISPs use their own rating systems and definitions.23
- Leaving domain authentication and DMARC unconfigured skips a recommended step for preventing bounces.24
- Using a free email service address as the From address skips the recommendation to use an address from a private domain.25
- A workflow that assumes perfect bounce prediction is unsafe. Mailchimp cannot predict whether an email will bounce.26