Список подавления

Список подавления — общий для организации список адресов, которым MailInfra не доставляет письма, даже если вы передаёте их в to/cc/bcc. Защищает репутацию домена и IP от отправки на адреса, которые гарантированно вернутся ошибкой или жалобой.

Управление списком (просмотр, ручное добавление, удаление) — в дашборде: Организация → Список подавления.

Как адреса попадают в список

У каждой записи есть пара полей: reason (почему адрес заблокирован) и source (как именно он попал в список).

`source`	`reason`	Что произошло
`AUTO`	`HARD_BOUNCE`	Отскок, причина которого входит в политику автоподавления — по умолчанию адрес не существует
`AUTO`	`COMPLAINT`	Получатель пожаловался на спам (FBL)
`MANUAL`	`UNSUBSCRIBE` / `MANUAL` / любой	Добавлен через API или дашборд (например, после нажатия «Отписаться»)

Не всякий отскок с кодом 5xx уводит адрес в список — см. следующий раздел.

Какие отскоки уводят адрес в список

Код 5xx сам по себе не значит, что адрес мёртв. 550 5.1.1 no such user — мёртв. А 554 5.7.1 message rejected under suspicion of SPAM — это отказ по репутации отправителя: ящик получателя жив и исправен, письмо не понравилось фильтру. Подавлять получателя во втором случае бессмысленно — проблема не в нём.

Поэтому подавление решается категорией отскока, а не кодом. Настройка — в дашборде: Организация → Список подавления → «Что уводит адрес в подавление».

По умолчанию включены:

Категория	Почему в дефолте
`invalid-recipient`	Ящика не существует. Повторные отправки туда — прямая дорога в spamtrap
`unknown`	Нераспознанный перманентный отказ: причина неясна, поэтому осторожничаем

По умолчанию выключены категории про репутацию отправителя — content-spam-block, policy-rejection, reputation-blocklist. Такой отскок фиксируется в событиях письма (bounce_type: "spam_block") и виден в статистике, но адрес остаётся доступным для отправки.

Что нельзя отключить

invalid-recipient отключить нельзя. Отправка на несуществующие адреса бьёт по репутации общего IP-пула, то есть по другим отправителям в нём.

Жалобы на спам (FBL) и отписки подавляются всегда и в этой настройке не участвуют — это требование почтовых провайдеров.

Если отскок случился, но адрес в список не попал (категория выключена), в событии письма будет отметка suppression_skipped: true.

Как это видно в API отправки

При вызове POST /v1/emails каждый адрес из to, cc, bcc сверяется со списком. Подавлённые тихо исключаются и возвращаются в skipped_recipients:

{
  "data": {
    "id": "018e1b7a-1111-7000-aaaa-111111111111",
    "status": "QUEUED",
    "skipped_recipients": [
      { "email": "blocked@example.com", "reason": "suppressed" }
    ]
  }
}

reason: "suppressed" означает, что адрес найден в suppression list. Конкретная причина записи (HARD_BOUNCE, COMPLAINT, UNSUBSCRIBE и т.д.) доступна при просмотре самого списка, но не раскрывается в ответе отправки.

Если все получатели подавлены — письмо не создаётся, ответ 422:

{
  "error": {
    "code": "all_recipients_suppressed",
    "message": "All recipients are in the suppression list"
  }
}

Причины подавления

Значение	Когда возникает
`HARD_BOUNCE`	Адрес не существует или домен не принимает почту
`COMPLAINT`	Получатель пометил письмо как спам
`UNSUBSCRIBE`	Получатель отписался (через ваш сайт или ссылку отписки)
`MANUAL`	Добавлен оператором

Удаление из списка

Удалять адрес стоит только если вы уверены, что причина исчезла: пользователь подтвердил, что хочет получать письма; адрес действительно существует. Повторная отправка на несуществующий адрес ухудшает репутацию домена и IP.

HARD_BOUNCE особенно: если адрес действительно умер, его повторная попытка снова закончится bounce — и подавление вернётся.

API списка подавления

Список подавления общий для всей организации, поэтому базовый префикс — /v1/organizations/{organization_id}/suppressions. Управление — часть Management API.

Метод	Путь	Минимальная роль	Что делает
`GET`	`/suppressions`	`VIEWER`	Список с фильтрацией
`POST`	`/suppressions`	`DEVELOPER`	Добавить адрес вручную
`DELETE`	`/suppressions/{id}`	`DEVELOPER`	Удалить запись
`GET`	`/suppressions/policy`	`VIEWER`	Текущая политика автоподавления
`PUT`	`/suppressions/policy`	`ADMIN`	Заменить политику

Просмотр

GET /v1/organizations/{organization_id}/suppressions
Authorization: Bearer <session_token>

Поддерживает фильтры:

Параметр	Тип	Описание
`email`	`string`	Поиск по конкретному адресу
`reason`	`HARD_BOUNCE \| COMPLAINT \| UNSUBSCRIBE \| MANUAL`	Фильтр по причине
`limit`	`int`	1–500, по умолчанию 100

GET /v1/.../suppressions?email=user@example.com
GET /v1/.../suppressions?reason=HARD_BOUNCE&limit=50

Ответ:

{
  "data": [
    {
      "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "email": "user@example.com",
      "reason": "HARD_BOUNCE",
      "source": "AUTO",
      "notes": null,
      "created_at": "2026-05-11T20:00:00Z"
    }
  ]
}

Политика автоподавления

GET /v1/organizations/{organization_id}/suppressions/policy
Authorization: Bearer <session_token>

Ответ:

{
  "data": {
    "categories": ["invalid-recipient", "unknown"],
    "available": ["auth-failure", "connection-error", "content-spam-block", "dns-mx-failure", "greylisting", "invalid-recipient", "mailbox-full", "message-too-large", "policy-rejection", "rate-limited", "reputation-blocklist", "unknown"],
    "mandatory": ["invalid-recipient"]
  }
}

available — все категории, которые можно включить, mandatory — те, что отключить нельзя. Оба поля приходят с сервера, поэтому список не нужно хардкодить у себя.

Изменение — полная замена набора, а не патч:

PUT /v1/organizations/{organization_id}/suppressions/policy
Authorization: Bearer <session_token>
Content-Type: application/json

{
  "categories": ["invalid-recipient", "unknown", "content-spam-block"]
}

Запрос без обязательной категории вернёт 422:

{
  "error": {
    "code": "validation_error",
    "message": "Categories cannot be disabled: invalid-recipient. ..."
  }
}

Ручное добавление

Пригодится для серверной реализации кнопки «Отписаться» на вашем сайте: пользователь нажимает — вы кладёте адрес в список подавления, MailInfra перестаёт ему писать.

POST /v1/organizations/{organization_id}/suppressions
Authorization: Bearer <session_token>
Content-Type: application/json

{
  "email": "user@example.com",
  "reason": "UNSUBSCRIBE",
  "notes": "Пользователь отписался через форму на сайте"
}

Поле	Тип	По умолчанию	Описание
`email`	`string`	—	Адрес, который добавляем
`reason`	`HARD_BOUNCE \| COMPLAINT \| UNSUBSCRIBE \| MANUAL`	`MANUAL`	Причина подавления
`notes`	`string \| null`	`null`	Свободный комментарий, виден только в дашборде

В ответе вернётся запись с source: "MANUAL" — поле source отличает ручные записи от автоматических (source: "AUTO"), которые MailInfra ставит на bounce и FBL.

Удаление

DELETE /v1/organizations/{organization_id}/suppressions/{suppression_id}
Authorization: Bearer <session_token>

После удаления адрес снова попадает в выборку при отправке. Не удаляйте HARD_BOUNCE без явной причины — см. предупреждение выше.

Как адреса попадают в список​

Какие отскоки уводят адрес в список​

Как это видно в API отправки​

Причины подавления​

Удаление из списка​

API списка подавления​

Просмотр​

Политика автоподавления​

Ручное добавление​

Удаление​