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 і не вважаються жорстким провалом. Призначте одного owner на правки suppression-листа.

Підсумок IOSOR

Bounce, complaint і deferral — три різні дії. Змішувати їх означає одночасно наповнювати spam folder і теку скарг.

Робіть: одразу suppress hard bounce і скарги; deferral повторюйте з backoff. Не робіть: вважати deferral bounce або писати на адресу після скарги.

Чи був матеріал корисним?

Пов’язані гіди