NotiSend — российский ESP, выросший из решения для транзакционных уведомлений. Платформа закрывает классический стек: SMTP-relay, REST API, webhook-уведомления, шаблоны, логирование, SMS/Viber как дополнительные каналы. Основной use-case — именно transactional email: регистрации, подтверждения заказов, коды подтверждения, reset password, системные уведомления.
Транзакционные письма особенно больно страдают от Spam-placement: пользователь не получает OTP-код — не проходит регистрацию. NotiSend показывает delivered 98%+ на своих отчётах, но реальный inbox rate на Mail.ru, Yandex, Gmail может быть 60–80%. Seed-адреса в рассылке выявляют это за 5 минут.
Почему placement для transactional критичнее, чем для маркетинга
В маркетинговой рассылке попадание 20% писем в Promotions или Spam — неприятно, но не фатально. Оставшиеся 80% дадут метрики, проведут клиента по воронке. Транзакционные письма устроены иначе: каждое письмо критично для конкретного пользователя.
- OTP-код в Spam — пользователь не логинится, не оплачивает, уходит к конкуренту.
- Password reset в Promotions — клиент пишет в саппорт, увеличивает costs и negatively повлияет на NPS.
- Order confirmation в Spam — клиент думает, что оплата не прошла, делает chargeback.
- Invoice / receipt в Spam — бухгалтерский и compliance-риск для B2B.
Именно поэтому для NotiSend seed-тестирование — не опциональная гигиена, а обязательная часть production pipeline.
Интеграция seed-адресов через API
В отличие от маркетинговых ESP, где seed-лист — это просто ещё одна аудитория, транзакционные платформы не имеют «списков получателей». Письма улетают через API по событию. Значит, seed-адреса надо встраивать в код вызова API.
Подход 1: BCC-поле
Самый простой вариант — дублировать каждое транзакционное письмо на seed-адреса через BCC. NotiSend API поддерживает BCC в запросе:
POST /api/v1/email/send
{
"from": { "email": "noreply@yourdomain.com" },
"to": [{ "email": "user@example.com" }],
"bcc": [
{ "email": "seed-gmail-01@seedbox.example" },
{ "email": "seed-mailru-01@seedbox.example" },
{ "email": "seed-yandex-01@seedbox.example" }
],
"subject": "Ваш код подтверждения: 42817",
"html": "..."
}Минус подхода — BCC-копия содержит реальные данные пользователя (OTP, имя). Для compliance-чувствительных отраслей (банки, медицина, e-gov) это недопустимо.
Подход 2: Параллельный тестовый канал
Более чистый способ: перед деплоем новой версии шаблона отправлять dummy-payload только на seed-адреса, с фиктивным OTP и фиктивными персональными данными. Это делается через отдельный API-вызов, например:
POST /api/v1/email/send
{
"from": { "email": "noreply@yourdomain.com" },
"to": [
{ "email": "seed-gmail-01@seedbox.example" },
{ "email": "seed-mailru-01@seedbox.example" },
...
],
"subject": "[TEST] Ваш код подтверждения: 00000",
"html": "<html>...</html>"
}Этот подход встраивается в CI/CD: при каждом деплое шаблона запускается seed-рассылка, результаты собираются из Inbox Check API, и pipeline fails, если Inbox rate ниже threshold.
Бесплатный инструмент Inbox Check генерирует 20+ свежих seed-адресов в Gmail, Outlook, Yahoo, Mail.ru, Yandex, ProtonMail и других. Без регистрации, без карты.
Разбор результатов по ключевым провайдерам
Gmail
Для transactional письма целевое состояние — Primary, не Promotions. Gmail умеет отличать транзакционные письма от маркетинговых на основе: уникальности контента, наличия One-Click Unsubscribe (для transactional он не нужен и даже вреден), низкой периодичности на конкретного получателя. Если ваш OTP стабильно уходит в Promotions — проверьте, не включили ли вы List-Unsubscribe header в шаблон.
Mail.ru
Mail.ru не различает transactional и bulk чётко — классификация идёт по содержимому и sender reputation. Для transactional писем целевое — «Входящие» с Inbox rate ≥ 90%. Если seed-тест показывает «Рассылки» — письмо выглядит как маркетинг. Причины: много изображений, CTA-кнопки, футер с promo-блоком.
Yandex
Yandex аккуратнее с transactional: если From стабилен и шаблон не похож на маркетинг, письма идут в Inbox. Проблема обычно всплывает, когда B2C-сервис начинает слать и маркетинг, и transactional с одного домена — reputation «размывается», и transactional начинает попадать в Spam.
Outlook / Hotmail
Outlook самый жёсткий для transactional. SmartScreen часто классифицирует автоматические письма как Junk. Минимальный фикс — DKIM на sending-домене, DMARC p=quarantine, регистрация в SNDS и JMRP.
Стратегия разделения доменов
Базовая практика для любого сервиса, отправляющего и маркетинг, и transactional через NotiSend: разные subdomain для разных типов писем.
mail.yourdomain.com → маркетинг (newsletters, промо)
notify.yourdomain.com → transactional (OTP, receipts)
support.yourdomain.com → человеческая перепискаТакое разделение даёт три независимых reputation-профиля. Если маркетинговая рассылка уйдёт в проблемы и domain reputation упадёт на mail.yourdomain.com, ваши OTP-письма сnotify.yourdomain.com останутся в Inbox.
Отправка OTP с того же домена, что и маркетинг, — самая частая ошибка на CIS-рынке. Один плохой релиз маркетинга убивает reputation всего домена — и следом ложится вход в приложение. Разделение поддоменов стоит 10 минут работы в DNS и окупается первой же инцидентной неделей.
Автоматизация проверки
На production-масштабе ручной seed-тест перед каждым релизом — не работает. Нужна автоматизация:
- В CI/CD (GitHub Actions, GitLab CI) при deploy новой версии шаблона — запускайте скрипт, который через NotiSend API отправляет dummy-payload на seed-адреса.
- Скрипт вызывает Inbox Check API через 2–3 минуты и получает JSON с результатами по каждому провайдеру.
- Если Inbox rate на любом ключевом провайдере (Gmail, Mail.ru, Yandex) ниже threshold (например, 85%) — pipeline fails, деплой откатывается, в Slack летит alert.
- Раз в неделю — scheduled-job, гоняющий все живые шаблоны транзакционных писем через seed-тест. Так вы ловите drift от изменения reputation, не связанных с вашими релизами.