When an email fails to deliver, your ESP records either a bounce or a deferred status. These three categories don’t carry the same reputation impact and don’t call for the same action. Understanding the difference prevents you from removing contacts unnecessarily, or worse, keeping them when you should delete them.

Watch out for the most common trap: there’s a widespread assumption that hard bounce = 5xx code and soft bounce = 4xx code. It’s a useful shortcut, but an oversimplification. In reality:

  • 5xx means: the message won’t get through as-is (the cause could be the recipient address, the content, the sending IP, a filtering policy…)
  • 4xx means: retrying might work

In practice, bounces are a jungle, some operators return 4xx codes for addresses that are permanently gone, others return 5xx for what’s actually a temporary rejection. It’s the ESP that interprets the code, the error message, and the sending history to classify the bounce as hard or soft, not the SMTP code alone.


Hard Bounce: Permanent Failure

A hard bounce is a delivery failure that your ESP classifies as permanent, the address doesn’t exist, the domain is gone, or the recipient’s policy systematically rejects your sends. The receiving server typically responds with a 5xx code, but an ESP can also classify a bounce as “hard” after repeated 4xx failures on the same address with no improvement.

Typical SMTP Codes

550 5.1.1 The email account that you tried to reach does not exist
550 5.7.1 Message rejected due to spam policy
551 User not local
553 User does not exist

Common Causes

  • Non-existent email address: typo at signup, deactivated address
  • Non-existent domain or missing MX: the domain expired or never configured email reception
  • Sending IP or domain on a blocklist: the receiving server rejects all email from your infrastructure
  • Address rejected by domain policy: some corporate domains reject unauthenticated emails or those from non-whitelisted senders

Reputation Impact

Hard bounce is the most negative signal for your sender reputation. Regularly sending to invalid addresses signals to filters that you don’t maintain your lists.

The basic rule, but not blindly: immediately remove addresses that are non-existent or undeliverable (550 user does not exist, domain with no MX). For bounces caused by a sender-side problem (blocklisted IP, filtering policy, rejected content), fix the root cause first, the address itself may be perfectly valid. The “hard bounce = delete immediately” rule can cost you legitimate contacts if the bounce originated from your own infrastructure.


Soft Bounce: Temporary Failure

A soft bounce is a temporary delivery failure. The receiving server responds with a 4xx code, meaning “can’t do it right now, try again later.”

Typical SMTP Codes

421 Service temporarily unavailable
452 4.2.2 Mailbox full
452 4.3.1 Insufficient system resources
451 Temporary local problem

Common Causes

  • Mailbox full: the recipient exceeded their storage quota (code 452)
  • Receiving SMTP server unavailable: maintenance, temporary overload
  • Message too large: exceeds maximum accepted size
  • Greylisting: some servers temporarily reject unknown senders (see “deferred” below)

Reputation Impact

Less severe than a hard bounce. Your ESP will automatically retry according to a retry policy (often every hour for 24–72 hours). If all retries fail, the email becomes permanently undelivered and the error may be reclassified.

Worth monitoring: an address that generates repeated soft bounces over several weeks (mailbox always full, domain often unavailable) should be removed. A permanently full mailbox is rarely an active one.


Deferred: Delivery Postponed, Not Rejected

A deferred status is often confused with a bounce, but there’s a fundamental distinction: a bounce is a final status (the email was definitively accepted or rejected), a deferred is transitory, delivery will be retried.

In practice, a deferred is most often triggered by a 4xx response (sometimes a 5xx if the ESP judges it appropriate), causing the sending mail server to put the message back in the queue for a later attempt. The delay between retries grows progressively, this is exponential backoff: a few minutes, then 15 min, 1h, 4h, until the maximum retry window expires (typically 24–72h depending on the ESP). If no attempt succeeds within that window, the email is permanently undelivered.

The mechanisms that trigger a deferred are the same as those that can trigger a soft bounce, the difference lies in how the ESP interprets the response and decides to retry:

Greylisting

The receiving server temporarily refuses a first contact with a 4xx, waits for the sender to retry (something spambots rarely do), then accepts the message on the second attempt.

Example SMTP response:

451 4.7.0 Try again later, closing connection

Throttling (Rate Limiting)

The receiving server accepts your emails but limits simultaneous connections or messages per hour. Emails exceeding the quota are queued on the sender side.

Example: Gmail accepts a maximum number of connections from a given IP. If you send 500,000 emails at the same time, the last ones will be deferred.

Key Difference from Soft Bounce

Soft bounceDeferred
Returned codeImmediate 4xx4xx on retry, or connection accepted but message delayed
Meaning“I can’t accept this”“I can’t process this right now”
ActionAutomatic retry by ESPAutomatic retry + rate reduction
Reputation impactLow to moderateVery low (normal behavior at high volume)

Reputation Impact

Deferred is largely benign. It’s a normal mechanism for large volumes. However, a high deferred rate on a specific IP may indicate that it’s being throttled by mailbox providers, an early warning sign that your reputation is degrading.


Summary Table

TypeSMTP CodePermanenceRecommended Action
Hard bounce5xxPermanentRemove immediately
Soft bounce4xxTemporaryAuto-retry, monitor repetitions
Deferred4xx or noneTemporaryAuto-retry, watch for throttling

ESPs and industry best practices suggest list hygiene rules:

  • Hard bounces on non-existent/undeliverable addresses: immediate removal, investigate the cause if the bounce originates from a sender-side issue (blocklisted IP, domain policy)
  • Repeated soft bounces: after 3–5 consecutive soft bounces on the same address (some ESPs auto-reclassify as hard), removal recommended
  • Chronic inactives (no opens, no clicks, no errors): segment separately (re-engagement campaign, then removal)

Diagnosing a Bounce

The SMTP code alone isn’t always enough, the associated error message is often more informative.

In SenderAudit, the “Headers” tab on your analysis results shows the full relay chain and raw SMTP message content. If you receive a Delivery Status Notification (DSN/NDR), analyzing its headers lets you pinpoint exactly where the rejection originated.

Identify the cause of your bounces with SenderAudit’s free Header Analyzer, paste your headers and get a structured reading of the relay chain.