Регламент инцидента доставляемости

1. Для какой ситуации подходит этот регламент

Регламент нужен, чтобы при сбое доставляемости команда действовала по плану, а не искала виноватых. Он отвечает на три вопроса: кто объявляет инцидент, что делать в первый час и как зафиксировать результат.

Типовые ситуации, под которые написан документ: письма массово уходят в спам у одного или нескольких провайдеров (Gmail, Mail.ru, Яндекс, Outlook), SMTP-сервер отвечает кодом 550 5.7.1 или 421, доля жалоб в Google Postmaster Tools превысила 0,1%, процент жалоб в Mail.ru Postmaster превысил порог из правил Mail.ru для вашего объема отправки, домен или IP попал в публичный черный список.

Регламент рассчитан на маркетолога или CRM-менеджера, который отправляет рассылки, и на технического специалиста, который отвечает за DNS и инфраструктуру отправки. Агентства могут использовать его как основу для регламента контроля postmaster по клиентским доменам.

2. Критерии объявления инцидента и уровни

Инцидент объявляет дежурный ответственный по факту пересечения порога, а не по ощущению, что "стало хуже". Ниже базовые уровни, скорректируйте их под свои объемы.

3. Runbook: план действий при блокировке рассылки

Шаг 0, фиксация (5 минут). Заведите карточку инцидента: дата и время обнаружения, кто обнаружил, какой поток затронут (промо, триггеры, транзакционные), с какого домена и IP шла отправка. Все дальнейшие действия и замеры пишите туда же с отметками времени.

Шаг 1, сдерживание (15 минут). Остановите или притормозите затронутый поток: пауза кампаний в ESP, снижение скорости отправки, отключение сегментов с высокой жалобностью. Транзакционные письма (пароли, чеки) не останавливайте, если они идут с отдельного поддомена и не затронуты.

Шаг 2, диагностика (1-2 часа). Пройдите чек-лист из раздела 4: коды ответов SMTP, DNS-записи, черные списки, метрики в кабинетах postmaster, изменения за последние 72 часа (новый шаблон, новый сегмент, смена ESP, правки DNS).

Шаг 3, устранение причины. Уберите источник жалоб (сегмент, кампанию, ссылку), исправьте DNS-записи, подайте заявку на делистинг, если домен в черном списке. Каждое изменение делайте по одному и фиксируйте, иначе не поймете, что сработало.

Шаг 4, контрольный прогон. Отправьте тестовую партию на свои контрольные ящики в Gmail, Mail.ru, Яндексе и Outlook. Проверьте папку входящих, а не только факт доставки: SMTP-ответ 250 OK означает приемку сервером, а не попадание во входящие.

Шаг 5, восстановление. Возвращайте объем постепенно: начните с наиболее активных подписчиков, увеличивайте объем при стабильных метриках. Шаг 6, разбор: в течение 2 рабочих дней заполните отчет по шаблону из раздела 6 и назначьте корректирующие меры.

4. Чек-лист диагностики: письма в спаме

Пройдите пункты сверху вниз и отметьте статус каждого. Большинство причин находится на первых трех блоках.

Метрики. 1) Доля жалоб в Google Postmaster Tools за последние 7 дней. 2) "Репутация, %" в Mail.ru Postmaster: это средний процент жалоб за 30 дней, чем меньше, тем лучше. 3) Динамика доставки и жалоб по дням: скачок совпадает с конкретной рассылкой?

Аутентификация. 4) SPF: одна TXT-запись, начинается с v=spf1, нет ошибки "too many DNS lookups" (лимит 10 механизмов с запросами). Проверка: dig TXT yourdomain.ru. 5) DKIM: подпись присутствует и проходит проверку, домен d= в подписи выровнен с доменом отправителя по DMARC (обычный режим relaxed допускает поддомен, точное совпадение не обязательно). Проверка: dig TXT selector._domainkey.yourdomain.ru. 6) DMARC: запись _dmarc.yourdomain.ru существует, политика не ломает легитимный трафик.

Коды ответов. 7) Возьмите полные ответы SMTP из логов ESP: 421 или 4xx - временное ограничение, 550 5.7.1 - отказ по политике провайдера. Текст после кода часто содержит ссылку на страницу с объяснением.

Черные списки. 8) Проверьте домен и IP отправки в основных публичных списках (например, через сервис проверки черных списков). Найденное попадание фиксируйте со скриншотом.

Контент и база. 9) Новые ссылки, домены редиректов, сокращатели в письме. 10) Новые сегменты и источники базы за последнюю неделю: свежие импорты без подтверждения подписки - частый источник жалоб. 11) Работает ли ссылка отписки в один клик.

5. Заполненный пример инцидента (вымышленный)

Пример показывает, как выглядит карточка инцидента, заполненная по этому регламенту. Компания, домены и значения вымышленные.

Обратите внимание: причину нашли не по косвенным признакам, а сопоставив время скачка жалоб с конкретной кампанией. История метрик по дням в кабинетах postmaster и мониторинге делает это сопоставление вопросом минут.

6. Шаблон отчета по инциденту и чек-лист перед отправкой

Шаблон отчета по доставляемости после инцидента (заполняется в течение 2 рабочих дней): 1) Хронология: обнаружение, сдерживание, устранение, восстановление, с точным временем. 2) Затронутые потоки, домены, объемы. 3) Корневая причина и чем она подтверждена (логи, метрики). 4) Что сделано для устранения. 5) Что предотвратит повторение: пороги алертов, правила импорта базы, изменения в процессе. 6) Ответственные и сроки по каждой мере.

Чек-лист перед отправкой рассылки (профилактика инцидентов): 1) Домен из DKIM-подписи (d=) выровнен с доменом отправителя по DMARC (relaxed-режим допускает поддомен), dig TXT selector._domainkey.yourdomain.ru отвечает корректно. 2) SPF одна запись, без permerror. 3) Ссылка отписки работает и ведет на реальную отписку. 4) Новые домены ссылок в письме проверены по черным спискам. 5) Сегмент собран по правилам: есть подтверждение подписки, нет адресов старше срока согласия. 6) Тестовая отправка на контрольные ящики Gmail, Mail.ru, Яндекса, Outlook показала входящие. 7) Текущие метрики репутации в норме: жалобы Gmail ниже 0,1%, жалобы Mail.ru ниже порога для вашего объема.

7. Регламент контроля postmaster: кто и когда смотрит метрики

Чтобы инциденты не начинались с письма клиента "ваша рассылка в спаме", закрепите регулярный контроль. Минимальный регламент: ежедневно дежурный проверяет алерты мониторинга и долю жалоб; еженедельно ответственный за email смотрит динамику по дням и доставку по провайдерам; ежемесячно команда сверяет DNS-записи и актуальность порогов.

Ручная проверка работает, пока доменов и потоков мало. При нескольких доменах и ESP проще настроить автоматический сбор: PostmastersTool забирает данные Google Postmaster Tools и Mail.ru Postmaster, проверяет DNS (SPF, DKIM, DMARC, MX, черные списки) и присылает уведомление в Telegram или на почту, когда метрика пересекает порог из вашего регламента. Пороги из раздела 2 переносятся в настройки алертов один в один.

Учтите особенность данных: статистика postmaster привязана к домену d= в DKIM-подписи. Если вы меняете селектор s=, история сохраняется, а вот смена домена подписи начинает статистику с чистого листа. Фиксируйте такие изменения в журнале, иначе на разборе инцидента получите "пропавшие" данные.