Hard vs Soft Bounces: SMTP Codes and Suppression Lists

A hard bounce is a permanent delivery failure, such as a mailbox that does not exist, and the address should be suppressed so you never send to it again. A soft bounce is a temporary failure, such as a full mailbox or a receiver throttling you, and the message should be retried with backoff. You tell them apart by the SMTP reply: 5xx codes and 5.x.x enhanced status codes (RFC 3463) are permanent, 4xx and 4.x.x are transient, but the class alone is not enough to decide whether to suppress an address.

Where bounces come from

A bounce can reach you in two ways:

1. Synchronous rejection: the receiving server refuses the message during the SMTP transaction. Your MTA sees the reply directly.
2. Asynchronous bounce: the server accepts the message (250 OK) and later fails to deliver it, then sends a Delivery Status Notification (DSN, RFC 3464) back to the envelope sender (the Return-Path).

Both must feed the same suppression logic. Asynchronous bounces are the reason you need a return-path address you actually process, which is what VERP makes easy.

Reading SMTP reply codes

An SMTP reply (RFC 5321) has a three-digit basic code. Many servers add an enhanced status code (RFC 3463, registry in RFC 5248) in the form class.subject.detail:

550 5.1.1 <jane@example.com>: Recipient address rejected: User unknown
452 4.2.2 The email account that you tried to reach is over quota
421 4.7.0 Try again later, closing connection
554 5.7.1 Message rejected due to content restrictions

• Class (2, 4, 5): success, persistent transient failure, permanent failure.
• Subject: 1 addressing, 2 mailbox, 3 mail system, 4 network and routing, 5 mail delivery protocol, 6 message content, 7 security or policy.
• Detail: the specific condition.

Common codes and what to do

The third category: policy bounces

The simple hard/soft split misses the case that matters most for reputation. A 550 5.7.1 saying your message was blocked as spam is permanent for that message, but it says nothing about whether the address is valid. If you suppress every address that returns a policy rejection, a single bad day at one provider can wipe out a large share of your Gmail or Outlook audience.

Classify bounces into three buckets:

• Address failures (hard): the mailbox or domain does not exist. Suppress permanently.
• Transient failures (soft): retry according to a schedule.
• Policy or reputation failures: do not suppress; alert a human, pause the stream if the rate is high, and look at authentication, content and complaint data.

Servers are not always consistent. Some return 550 for a full mailbox, others return 5.0.0 with only free text. Robust classifiers check the enhanced code first, then known text patterns per receiving domain, and default to the safest action.

Retry strategy for soft bounces

RFC 5321 recommends retry intervals of at least 30 minutes and giving up after at least 4 to 5 days. A sensible queue behavior:

• Exponential backoff with jitter: for example 5 min, 15 min, 30 min, 1 h, 2 h, then every 4 h.
• A maximum queue lifetime (often between 24 hours and a few days); transactional messages such as one-time codes lose their value much sooner and may deserve a shorter lifetime.
• Per-destination concurrency limits, so a deferral from one provider slows only that provider.

When the queue lifetime expires, the message becomes a final failure, but the address still did not prove invalid.

Building a suppression list

A suppression list is the set of addresses your system will refuse to send to, checked before every message is queued. It should contain:

• Hard bounces (address failures).
• Spam complaints from feedback loops.
• Unsubscribes, scoped to the stream or list the person left.
• Repeated soft bounces: for example, an address that soft-bounced on several separate sends over more than a week.
• Manual entries: role addresses you were asked to stop emailing, legal requests.

Store the reason, source, timestamp and the raw diagnostic code for each entry:

{
  "address": "jane@example.com",
  "reason": "hard_bounce",
  "status": "5.1.1",
  "diagnostic": "smtp; 550 5.1.1 User unknown",
  "stream": "*",
  "created_at": "2026-10-12T14:03:22Z"
}

Scope matters. A hard bounce applies to every stream. An unsubscribe from a newsletter should not stop password resets. A complaint usually applies to all non-transactional streams.

Normalize addresses before lookup (lowercase the domain; be careful with the local part, which RFC 5321 treats as case-sensitive even though almost no providers do), and allow removal with an audit trail when a user fixes their mailbox.

Why bounce rate matters to receivers

Mailbox providers watch how often you hit nonexistent addresses. A sender who regularly mails invalid users is either buying lists or not maintaining them, and both correlate strongly with spam. Old addresses can also be recycled into spam traps. High hard-bounce rates therefore damage reputation even when the rest of your mail is wanted.

Common mistakes

• Retrying hard bounces. Sending again to a 5.1.1 address is pure reputation cost.
• Suppressing on 5.7.x as if the address were dead.
• Ignoring asynchronous DSNs because the SMTP transaction returned 250.
• Treating auto-replies as bounces (or the reverse). Out-of-office messages are not DSNs.
• One global suppression list without reasons, making it impossible to tell an unsubscribe from a bounce.
• Validating only at send time instead of also at signup, with double opt-in for marketing lists.

Checklist

• [ ] Synchronous and asynchronous bounces processed by the same classifier
• [ ] Enhanced status codes parsed, with text fallbacks
• [ ] Address, transient and policy bounces handled differently
• [ ] Exponential backoff with a defined queue lifetime
• [ ] Suppression checked before queueing, with reason and scope
• [ ] Alerts on policy bounce spikes per receiving domain

Pidgely classifies synchronous replies and DSNs into these categories, adds hard bounces and complaints to the suppression list automatically, and emits a webhook event for each one so your application stays in sync.