IOSOR

IOSOR База знаний

Bounce vs complaint vs deferral: что делать до жалобы в spam folder

B2B-гайд по триажу bounce, complaint и deferral для transactional email — ownership, правила suppression, prepaid-честность и честный live vs in setup.

Три события доставки выглядят похоже в сыром логе, но значат три совершенно разные вещи: bounce, complaint и deferral. Команды, которые валят их в одну кучу, либо продолжают долбить мёртвые адреса, пока репутация не рухнет, либо панически suppress-ят хорошие адреса из-за временного сбоя.

IOSOR относится к transactional email как к prepaid white-label возможности рядом с messaging: каждая отправка — строка debit, ownership suppression назван, а рынок честно остаётся in setup, пока обработка bounce/complaint/deferral реально не обкатана — а не предполагается по демо-аккаунту.

Три сигнала, три разных пожара

Bounce говорит, что сообщение не доставлено. Complaint говорит, что доставлено, и получатель пометил как нежелательное. Deferral говорит, что принимающая система попросила повторить позже. Спутать любую пару даёт неверный фикс — retry hard bounce жжёт репутацию так же, как игнорирование complaint.

Bounce: hard vs soft, и что путают команды

Тип Значение Верное действие
Hard bounce Адрес не существует / постоянный отказ Suppress немедленно, не повторять
Soft bounce Временная проблема (ящик полон, лимит размера) Ограниченный retry с backoff, затем suppress
Block bounce Политика receiver отклонила отправителя Разбирать auth/репутацию, не адрес

Частая ошибка — считать каждый bounce «повторить позже»: hard bounce, повторённый на живой домен, — прямой путь превратить чистую репутацию в фильтруемую.

Complaint (FBL): самый быстрый способ сжечь домен

Complaint значит, что реальный получатель сказал своему mailbox-провайдеру, что письмо нежеланное. Complaints весят репутационно больше, чем bounce, потому что это человеческое суждение, а не техническая ошибка. Один адрес, одна жалоба, одно немедленное suppression — никаких «посмотрим, повторится ли».

Deferral: сигнал throttling, а не провал

Deferral — принимающая система просит замедлиться или повторить позже, часто по rate, а не по content. Панический suppress адресов после deferral тратит легитимную аудиторию. Верный ответ — backoff и pacing, а не чистка списков.

Соберите коды bounce, источники complaint и паттерны deferral на одной странице с owner и действием на каждую строку. Если появился новый код ошибки, которого никто не узнаёт, — направьте его названному owner до того, как автоматика решит сама.

Suppression должен быть единым источником правды, общим для transactional и любого другого mail-пути — не таблицей, которую один инженер держит локально. Недокументированная логика suppression — это как команды случайно повторно шлют hard bounce через месяцы и заново учат урок.

Красные флаги

  • Один suppression-лист смешивает hard bounce, soft bounce и complaint
  • Complaint обрабатывается так же, как deferral
  • Нет named owner для изменений suppression-листа
  • Retry hard bounce «на всякий случай»
  • Live-бейдж на рынке с непроверенной обработкой bounce/complaint
  • Ошибки раскрывают upstream mail-инфраструктуру конечным пользователям

Старт с IOSOR

Снимите неделю событий bounce, complaint и deferral и разложите по трём корзинам до роста объёма. Подтвердите, что hard bounce сразу уходят в suppress и никогда не повторяются. Подтвердите, что каждая жалоба пишет постоянный suppress. Подтвердите, что deferral повторяются с backoff и не считаются жёстким провалом.

Итог IOSOR

Bounce, complaint и deferral — три разные операции. Смешивать их значит одновременно наполнять spam folder и папку жалоб.

Делайте: сразу suppress hard bounce и жалобы; deferral повторяйте с backoff. Не делайте: считать deferral bounce или писать на адрес после жалобы.

Был ли материал полезен?

Связанные гайды