Back to blog
Deliverability··4 min read·WillItInbox Team

Bounces decoded: hard, soft, block, and how to handle each

What every SMTP bounce code actually means, which ones to retry, and the suppression rules that keep your reputation intact.

BouncesDeliverabilitySMTP

A bounce is a delivery failure with a story. Treat them all the same — retry forever, never suppress — and your reputation collapses in weeks. Read them properly, and they're the single best signal you have about list health and infrastructure problems.

The two-tier code system

Every bounce comes with two codes: the basic SMTP reply (5xx or 4xx) and an enhanced status code (5.1.1, 4.7.1, etc., from RFC 3463). The SMTP code tells you whether to retry. The enhanced code tells you why.

ClassMeaning
2.x.xSuccess
4.x.xPersistent transient failure (retry)
5.x.xPermanent failure (suppress)
Enhanced status code structure: class.subject.detail

Hard bounces (5xx) — suppress immediately

CodeMeaningAction
550 5.1.1Mailbox does not existSuppress permanently
550 5.1.10Recipient address rejectedSuppress
550 5.4.1Recipient address rejected — relay deniedLikely typo
552 5.2.2Mailbox fullSoft-treat: retry once, then suppress if persists
553 5.1.3Bad destination address syntaxSuppress
Common hard bounce codes and what they mean.

Soft bounces (4xx) — retry with backoff

CodeMeaningStrategy
421 4.7.0Service temporarily unavailableStandard retry
450 4.2.1Mailbox temporarily unavailableStandard retry
451 4.7.1GreylistedWait 5–15 min, retry
452 4.2.2Mailbox fullRetry slowly, suppress after 5 days
421 4.7.0Try again later (rate limit)Honor backoff signal
Common soft bounce codes.

Standard retry strategy: 4 attempts over 72 hours with exponential backoff (15min, 1h, 6h, 24h). After that, suppress. Most ESPs do this automatically; if you're hand-rolling, set a time-based ceiling and stop.

Block bounces — the dangerous middle ground

Block bounces look like 5xx but indicate reputation problems, not bad addresses. They mean the receiver is rejecting your IP or domain, not the recipient. Suppressing the address won't help; you have to fix reputation.

CodeMeaningReal fix
550 5.7.1Message blocked due to policyCheck authentication, content, IP reputation
550 5.7.26DMARC policy not alignedFix DMARC alignment
554 5.7.1Spam content detectedAudit content; check SpamAssassin score
421 4.7.0 IP throttledSending too fastSlow down, distribute IPs
550 5.7.605 (Microsoft)DBL hitCheck Spamhaus listing

Designing a bounce handler

What every bounce processor should do

  1. 01

    Parse the SMTP code AND enhanced code

    Don't rely on regex over English failure text — it's inconsistent across receivers. The numeric codes are standardized.

  2. 02

    Categorize: hard, soft, block

    Hard → suppress. Soft → retry queue. Block → alert and investigate.

  3. 03

    Suppress on hard, with timestamp and reason

    Store why a recipient was suppressed. Future debugging is impossible without this.

  4. 04

    Backoff and ceiling for soft

    Standard: 4 retries over 72 hours. After ceiling, suppress with a different reason code ("prolonged soft").

  5. 05

    Alert on spike

    Sudden bounce rate change is the earliest warning of an infrastructure problem. Alert on >2x baseline within an hour.

The bounce rate ceiling

Major receivers throttle senders whose bounce rate exceeds about 5% over a rolling 24-hour window. Healthy lists run under 2%. If you're above 5%, you're either sending to a bought list or your suppression isn't working — both reputation-fatal.

Frequently asked questions

Keep reading