Hard Bounce a permanent delivery failure

The SMTP codes that produce a hard bounce

Receiving mail servers communicate the bounce reason as a numeric code in the 5xx range. The number tells you (and your platform) what to do next.

• 550 · Mailbox unavailable. The most common hard bounce. The address doesn't exist or was permanently closed. Suppress immediately.
• 551 · User not local. Receiver doesn't accept mail for this user. Less common but treat as permanent.
• 553 · Address syntax invalid. The address itself is malformed. Suppress.
• 554 · Transaction failed. Generic permanent failure. Could be policy-based (your IP is blocked, message is filtered as spam) rather than address-based. Worth investigating before suppressing.
• 521 · Domain doesn't accept mail. Rare. The whole domain rejects all email. Suppress.

Codes in the 4xx range (421, 450, 451, 452) are soft bounces, meaning temporary. Those should be retried with backoff, not suppressed.

Why hard bounces matter so much

Every additional hard bounce signals to mailbox providers that you don't maintain your list. They reason: a sender who keeps trying to deliver to dead addresses is probably a sender who bought, scraped, or appended that list. The reputation hit compounds. One pristine spamtrap hit on an old list can drop your domain reputation a full tier overnight.

Industry target: keep hard bounce rate below 0.5%. Below 0.2% is excellent. Above 1% starts hurting reputation. Above 5% triggers mailbox provider intervention. Transactional senders should be tighter than this since their lists are signed-up users whose addresses they collected directly.

What to do when a hard bounce happens

In order of priority:

• Suppress the address immediately. Add it to your global suppression list. Never send to it again. Every retry is a vote against your reputation.
• If the bounce code is 554 (policy/spam), investigate. This might be your IP, your content, or your authentication, not the address. Don't suppress before you understand the cause.
• Notify your CRM or downstream systems. The contact's email is dead. Mark them as such so other workflows stop sending too.
• Aggregate by domain. If you're seeing a sudden spike of 550s from one specific receiving domain, that domain may have started rejecting your mail entirely. Investigate before more sends compound the damage.

Hard bounce vs soft bounce

The mechanics are clean if you remember the temperature analogy:

• Hard bounce (5xx codes): permanent. Suppress. Don't retry.
• Soft bounce (4xx codes): temporary. Retry with exponential backoff. If the soft bounce keeps failing across days, eventually treat it as hard.

The platform you send through should be classifying every bounce in real time. The cleaner the classification, the less manual reconciliation you do. Most reputation damage from bounces is downstream of poor classification, not from the bounces themselves.

How sendmsg.io handles hard bounces

The Cortex engine on our platform parses every SMTP response in real time as it lands in our Postfix logs. Hard bounces hit a global suppression list automatically. Soft bounces enter a retry queue with exponential backoff (first retry in minutes, second in an hour, then a few hours, then 24 hours out). If a soft bounce keeps failing past that window, the address gets reclassified and suppressed pending manual override.

Hard bounce rate also feeds into the per-domain reputation temperature. Cross 1% in a rolling window and the engine applies graduated throttle controls automatically before mailbox providers do it for us at a much higher cost. The principle is upstream of reputation management: catch the slope before it becomes the cliff.