Мониторинг доставляемости писем: как настроить без ошибок
Письмо может быть принято почтовым сервером и всё равно попасть в спам. Чтобы замечать проблему до падения продаж, отслеживайте не одну цифру, а связку сигналов: от SPF, DKIM и DMARC до жалоб и отказов у конкретных провайдеров.
Почтовый сервер ответил «принято», но письма уже уходят в спам: так выглядит сбой, который не заметит мониторинг только по SMTP-коду 250. Настройте проверку аутентификации, жалоб, отказов и репутации отдельно для крупных почтовых провайдеров. Тогда проблема обнаружится до того, как перестанут доходить письма с чеками, сбросом пароля или предложениями магазина.
Сначала определите, что именно мониторить
Доставляемость — не то же самое, что доставка. Успешный SMTP-ответ означает, что принимающий сервер согласился обработать сообщение. Он не подтверждает, что письмо окажется во входящих, будет показано пользователю или вообще не попадёт в спам. Поэтому отчёт «доставлено 99%» сам по себе почти ничего не говорит о размещении писем в папках.
Для рабочей картины нужны три слоя сигналов:
- Техническая доставка: доля принятых, отклонённых и временно отложенных писем, сгруппированная по провайдеру и типу сообщения.
- Репутация и жалобы: жалобы получателей на спам, сведения из инструментов почтовых провайдеров, динамика блокировок.
- Аутентификация и содержимое: результаты SPF, DKIM и DMARC, корректность домена отправителя, ссылки и формат письма.
Разделяйте потоки: транзакционные письма и рассылки не должны сливаться в один график. Отказ подписаться на новости не равен проблеме с письмом для сброса пароля, а общий процент успешной отправки может скрыть сбой одного потока или одного провайдера.
Выберите сигналы, а не красивый дашборд
Не существует универсального порога, который гарантирует попадание во входящие. Ориентиры зависят от типа писем, объёма, провайдера и истории домена. Сначала соберите базовый уровень на собственном трафике, затем ставьте тревогу на резкое отклонение и на абсолютные значения там, где провайдер публикует рекомендации.
| Сигнал | Что показывает | Как использовать |
|---|---|---|
| Отказы SMTP | Письма, которые сервер не принял | Группировать по коду ответа и провайдеру; отдельно разбирать постоянные и временные отказы |
| Жалобы на спам | Реакцию получателей и риск ухудшения репутации | Следить за данными Postmaster-инструментов и сопоставлять их с конкретной рассылкой |
| SPF, DKIM, DMARC | Прошла ли проверка домена и совпадают ли домены отправителя | Проверять до массового запуска и после изменений DNS или почтовой платформы |
| Отложенные письма | Временные ограничения, серые списки или перегрузку | Смотреть на рост очереди, время до повтора и итоговый отказ, а не только на первый ответ сервера |
| Открытия и клики | Поведение части аудитории | Использовать как вспомогательный сигнал: блокировка изображений и защита приватности искажают открытия |
Выравнивание домена1 важно для DMARC: домен в видимом адресе отправителя должен согласовываться с доменом, прошедшим SPF или DKIM. Успешная проверка SPF сама по себе не гарантирует такого совпадения.
Выберите способ наблюдения
Обычно нужны сразу несколько источников. Они измеряют разные вещи и не заменяют друг друга.
| Подход | Что даёт | Чем платите |
|---|---|---|
| Логи ESP или почтового сервиса | Коды ответов, отказы, попытки повторной отправки, идентификаторы сообщений | Провайдер может показывать только собственный трафик; метрики не всегда отражают папку получателя |
| Инструменты почтовых провайдеров | Репутацию домена и IP, ошибки аутентификации, жалобы или агрегированные показатели | Данные могут быть неполными, запаздывать и появляться только при достаточном объёме почты |
| Тестовые ящики и проверка размещения | Снимок того, куда пришло письмо на выбранных адресах | Небольшая тестовая выборка не воспроизводит поведение всей аудитории и не заменяет метрики реального трафика |
| Собственная аналитика событий | Связь почтового события с типом письма, кампанией и действиями пользователя | Нужно нормализовать ответы разных провайдеров и аккуратно хранить персональные данные |
Для Gmail используйте Google Postmaster Tools, если у вас есть достаточный объём отправки и подтверждённый домен. Для других провайдеров ищите их официальные панели и отчёты. Тестовые ящики полезны перед релизом шаблона, но не делайте вывод о доставляемости по одному письму на личный адрес.
Настройте мониторинг по шагам
- Инвентаризируйте отправителей. Запишите все домены и сервисы, которые отправляют почту от вашего имени: приложение, CRM, поддержка, рассылка. Проверка пройдена, если для каждого потока понятно, кто владеет настройками и где смотреть логи.
- Проверьте SPF, DKIM и DMARC. Сверьте DNS-записи с документацией каждого сервиса отправки и проверьте выравнивание доменов. Начинайте с наблюдения DMARC-отчётов, не меняя политику вслепую: проверка пройдена, если письма всех легитимных отправителей проходят ожидаемую аутентификацию.
- Сведите события в одну схему. Храните время, провайдера-получателя, тип письма, результат, код ответа и идентификатор сообщения. Не записывайте тело письма и адрес получателя без необходимости. Проверка пройдена, если по одному событию можно понять, какой поток и какой провайдер затронут.
- Разделите метрики. Считайте доставку, постоянные отказы, временные отказы и жалобы отдельно для транзакционных писем и рассылок, а затем — для крупных провайдеров. Проверка пройдена, если резкий рост ошибок на одном провайдере не теряется в общем среднем.
- Поставьте оповещения и назначьте владельца. Используйте скользящее окно и сравнение с обычным уровнем, чтобы единичный всплеск не будил команду. Для жалоб учитывайте рекомендации самого провайдера. Проверка пройдена, если тревога содержит затронутый поток, провайдера, масштаб и ссылку на логи.
- Проведите контролируемый тест. Отправьте письмо на адреса у разных провайдеров, проверьте заголовки, аутентификацию, ссылки и отображение. Проверка пройдена, если тест подтверждает техническую корректность, а реальные метрики после запуска не ухудшаются.
Мониторинг доставляемости должен отвечать не на вопрос «сколько писем отправили», а на вопрос «какой поток перестал доходить, у кого и по какой причине».
Что ломается чаще всего
Один процент скрывает локальный сбой
Если общий показатель приёма равен 98%, это может означать как небольшое равномерное число отказов, так и почти полный сбой у конкретного провайдера. Разбивайте метрики минимум по домену получателя и типу письма. При этом не дробите отчёт так сильно, чтобы в группах оставались единичные события: такой график шумит и раскрывает лишние данные.
Повторная отправка маскирует отказ
Временный ответ не всегда означает окончательную потерю письма: почтовая система может повторить попытку. Но бесконечные повторы раздувают очередь и задерживают важные сообщения. Отслеживайте время ожидания, число попыток и конечный результат; правила повторов задавайте по документации вашего провайдера, а не по единому числу для всех кодов.
Тестирование не равно измерению аудитории
Проверка нескольких тестовых ящиков помогает заметить сломанный DKIM, неверную ссылку или попадание конкретного шаблона в спам. Она не доказывает, что массовая рассылка будет размещена так же: у реальных получателей другая история взаимодействия, а у домена — другая репутация и нагрузка.
Открытия выглядят точнее, чем есть
Пиксель открытия может загружаться автоматически, а изображения — блокироваться. Поэтому не используйте процент открытий как единственное доказательство попадания во входящие. Сопоставляйте его с кликами, конверсиями, жалобами и данными провайдера, учитывая, что и эти сигналы имеют ограничения.
Что делать дальше
Начните с инвентаризации отправителей и проверьте аутентификацию каждого потока. Затем соберите базовые показатели хотя бы по основным провайдерам и настройте тревогу на устойчивое отклонение, а не на единичный скачок. После каждого изменения DNS, почтовой платформы, шаблона или объёма отправки сверяйте логи и отчёты провайдера. В проде в первую очередь измеряйте жалобы, постоянные отказы и задержку транзакционных писем.
1 Выравнивание домена — соответствие домена, видимого получателю в поле From, домену, который прошёл проверку SPF или DKIM по правилам DMARC.
Аналитик звонков: Разбор записи звонка по этапам сделки: где сорвалось, что упущено, три исправляемые рекомендации с цитатами.
Спросить за 90 ₽Источники: Google: Email sender guidelines, DMARC: RFC 7489
Частые вопросы
Если SMTP отвечает 250, письмо точно попадёт во входящие?
С чего начать, если писем стало меньше доходить?
Нужны ли тестовые ящики, если есть логи ESP?
Можно ли оповещать команду по проценту открытий?
Что делать, если жалоб стало больше, но общая доставка не изменилась?
Как часто проверять DNS-аутентификацию?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.