Soft bounce vs hard bounce: что cold email отправителям нужно знать

Soft bounces и hard bounces выглядят похоже в cold email отчётах — оба show up как “delivery failed” — но означают разные вещи и требуют разных операционных response. Команды, относящиеся к ним одинаково, либо over-react на soft bounces (удаляя salvageable адреса), либо under-react на hard bounces (продолжая шлать на адреса, повреждающие репутацию). Эта статья — что каждый тип bounce реально означает в 2026, как каждый влияет на sender reputation и операционный response, предотвращающий bounce-driven damage. Пара к гайду по email verification тулам и чек-листу аудита доставляемости.

Hard bounce — permanent delivery failure — адрес не существует, домен отклоняет всю mail, или receiving-сервер возвращает 5xx SMTP error. Soft bounce — temporary failure — mailbox full, server temporarily down, rate-limiting, greylisting — с 4xx SMTP error. Hard bounces требуют immediate removal из списков; soft bounces требуют retry с backoff policy.

Что hard bounces реально

Hard bounce случается, когда receiving-сервер говорит “этот адрес не может accept mail, period”. Распространённые причины:

• Адрес не существует. Mailbox notarealperson@company.com никогда не был set up или был удалён.
• Домен не существует или has no MX-записи. Весь домен не может принимать mail.
• Recipient blocked sender. Receiver explicitly blocked sending domain или IP.
• Mailbox closed. Человек ушёл из компании; их mailbox был decommissioned.

SMTP-wise, hard bounces возвращают 5xx response code (550, 553, 554 и т.д.). Error message в bounce usually содержит “user unknown,” “mailbox not found,” “no such user” или похожее.

Reputation impact hard bounces: Severe. High hard-bounce rate (above 5%) говорит receiving-системам, что вы шлёте на bad список, что primary spam pattern. Большинство sending-платформ automatically suspend или rate-limit аккаунты с hard-bounce rate above 5–10%. Продакшен cold email targeting под 2% hard-bounce rate.

Операционный response на hard bounces:

1. Удалить из current кампании immediately. Не retry. Адрес permanently invalid.
2. Mark как invalid в source-списке. Обновите CRM, prospect-базу или list-источник, чтобы адрес не был re-included в future кампании.
3. Audit источник bad-адреса. Если тот же list-источник produces консистентные hard-bounce rate above norm, у list-источника есть quality problem.

Что soft bounces реально

Soft bounce случается, когда receiving-сервер говорит “я не могу deliver это right now, try again later”. Распространённые причины:

• Mailbox full. Recipient не cleaned up их inbox.
• Server temporarily down. Receiving-сервер offline или unreachable.
• Rate limiting. Вы шлёте на too many адресов в receiving-домене too fast.
• Greylisting. Receiver использует greylisting как spam-prevention технику — first attempt deferred, retry succeeds.
• Message too large. Email exceeded receiving-сервера size limit (редко для plain text cold email).
• Spam content detected. Некоторые серверы soft-bounce suspicious content, а не reject outright.

SMTP-wise, soft bounces возвращают 4xx response code (421, 450, 451 и т.д.). Error message часто содержит “try again later,” “deferred,” “rate limit exceeded” или похожее.

Reputation impact soft bounces: Moderate. Soft bounces — normal background noise — receiving-серверы expect некоторый процент temporary failures. Sustained high soft-bounce rate (above 10%) — проблема, но occasional spikes expected. Продакшен cold email трекает soft-bounce trends, но не alarmed individual events.

Операционный response на soft bounces:

1. Retry с backoff. Большинство cold email платформ automatically retry soft bounces — typically 3-5 attempt spread over 24-48 часов.
2. После retries fail, mark как suspended. Если адрес fail 3+ retries, treat как effectively invalid для этого campaign cycle. Re-attempt next cycle.
3. Investigate patterns. Если many soft bounces приходят с того же receiving-домена, check, вы hitting rate limits или whether домен использует greylisting агрессивно.

Различие в operational handling

Hard vs soft handling выглядит примерно так:

Aspect	Hard bounce	Soft bounce
Retry policy	Никогда не retry	3-5 retries с backoff
List action	Permanent removal	Temporary suspension
Reputation impact	Severe	Moderate, sustained
Target rate	Под 2%	Под 5%
Investigation trigger	Single hard bounce на verified списке	Sustained pattern above 5%
Source quality signal	High hard-bounce rate = bad source	Pattern через провайдеров = sending issue

Single biggest operational mistake: relating к soft bounces как hard bounces (удаляя salvageable contacts) или treating hard bounces как soft bounces (retrying them и accumulating reputation damage).

Как мониторить типы bounce

Продакшен cold email тулы (Smartlead, Lemlist, Apollo, Instantly) classify bounces automatically на основе SMTP response code. Classifications usually надёжные, но worth spot-checking:

• Проверьте platform’s bounce categorization. Некоторые платформы lump soft и hard bounces в single “bounced” status, что loses сигнал.
• Трекайте per-campaign hard-bounce rate отдельно. Targeting под 2% через кампанию.
• Трекайте per-source hard-bounce rate. Если list-источник A produces 1% hard bounces и source B produces 8%, разница — сигнал.
• Мониторьте soft-bounce trends over time. Sustained climbing soft-bounce rate signals receiving-системы starting treat вашу mail как suspicious.

Типичные ошибки bounce-handling

Relating все bounces как same. Lumping soft и hard в “bounced” loses operational signal и prevents proper handling.

Retrying hard bounces. Некоторые тулы или workflow retry каждый bounce; для hard bounces это просто wastes API call и accumulates damage. Никогда не retry 5xx.

Removing soft bounces immediately. Soft bounces usually transient — адрес может быть perfectly valid, но momentarily unavailable. Always allow retries before removal.

Не investigating bounce patterns. Spike в bounces — information. Продакшен-команды investigate, когда bounces deviate от baseline.

Skipping verification, thinking bounces will catch it. Verification (разобрано в best email verification tools) catches большинство invalid адресов before send. Полагание на bounce-then-remove логику означает, что reputation damage случается first.

Паттерн: soft и hard bounces требуют fundamentally разных response, и confusing them — самый распространённый bounce-handling failure. Продакшен-команды relating их отдельно, трекают per-source и используют разницу в rates как signal о list quality.