Hard vs soft bounces
Hard bounce — permanent failure (SMTP 5xx). The address does not exist, the domain has no MX record, the receiving server has banned the message outright. Retrying is pointless and actively harmful to your reputation.
Soft bounce — temporary failure (SMTP 4xx). The mailbox is full, the server is overloaded, greylisting is in effect. Retry with backoff; most resolve within minutes to hours.
What counts as a healthy bounce rate
For transactional mail (password resets, receipts) bounce rate above 2% suggests address-quality problems — typo-bounces from sign-up forms, abandoned accounts, recipients churning addresses.
For marketing mail providers like Gmail and Yahoo's 2024 bulk-sender rules cap healthy bounce rate at 0.3% — sustained higher than that and they start rate-limiting your sending IPs.
A bounce-rate spike of 5%+ on a transactional stream usually indicates a process failure — a CSV import went wrong, a test environment is sending real mail, a leaked API key is being abused.
Suppression: never send to a hard-bounced address again
Hard bounces must land on a suppression list immediately. The address does not work — re-sending wastes your reputation budget for no possible benefit.
SNDR maintains the suppression list automatically and checks it on every send. Your code can also bypass the API entirely by checking suppression status before queueing a send.
Common bounce SMTP codes
550 5.1.1 — "user unknown" / "mailbox does not exist". The most common hard bounce.
550 5.4.1 — "recipient address rejected". Often spam-filter rejection; can be either reputation-driven (hard bounce in effect) or content-driven (soft bounce in effect).
421 4.7.0 — "temporary rate limit". Slow down; retry later.
451 4.7.1 — "greylisted". Retry in a few minutes; should pass on the second attempt.
554 5.7.1 — "spam policy rejection". Effectively a hard bounce caused by your reputation, not the address.
How SNDR reports bounces
Every bounce fires an email.bounced webhook event with the email_id and the raw SMTP error string. The dashboard shows a per-recipient-domain breakdown so a spike at Gmail (but not Outlook) immediately points at a reputation issue with one ISP rather than your whole list.
Hard bounces add the recipient to the suppression list automatically. Your code can also query /v1/suppressions to bulk-cross-reference your CRM.