Транзакционные письма не доходят: как найти причину и починить

1. Почему сервисные письма критичнее маркетинговых

Транзакционные письма (подтверждение заказа, восстановление пароля, код входа, уведомление об оплате) запрашивает сам получатель. Клиент ждет письмо в течение минут, и если оно не пришло, заказ срывается, сессия поддержки удлиняется, а доверие к сервису падает.

Парадокс в том, что сервисные письма часто отправляются с той же инфраструктуры, что и промо-рассылки: тот же домен, тот же IP, тот же ESP. Фильтры Gmail и Mail.ru оценивают отправителя в целом, поэтому жалобы на маркетинговые письма ухудшают доставку и транзакционных.

Вторая частая причина: технические письма с сайта отправляются скриптом напрямую с веб-сервера, без SPF, DKIM и DMARC. Такие письма почтовики либо кладут в спам, либо отклоняют с ошибкой вида 550 5.7.26 у Gmail.

2. Дерево диагностики: с чего начать

Прежде чем менять настройки, определите, на каком этапе теряется письмо. Для этого отправьте тестовое письмо на ящики в Gmail, Mail.ru и Яндексе и сверьтесь с таблицей.

Важно не путать две ситуации: сервер получателя ответил 250 OK (письмо принято) и письмо попало во входящие. Accepted не равен inbox: письмо может быть принято и молча отфильтровано в спам. Подробнее об этом расхождении в статье про <a href="/blog/delivery-ne-ravno-inbox">SMTP accepted и реальную доставку</a>.

3. Шаг 1: проверка аутентификации домена

Транзакционные письма обязаны проходить SPF, DKIM и DMARC. С 2024 года Google требует это от всех массовых отправителей, а отказ с кодом 550 5.7.26 означает, что письмо не прошло проверки аутентификации.

Проверьте записи командами dig:

dig TXT example.com +short (ищите запись, начинающуюся с v=spf1, она должна быть одна); dig TXT selector._domainkey.example.com +short (публичный ключ DKIM, selector замените на свой); dig TXT _dmarc.example.com +short (запись v=DMARC1 с политикой p=).

Типичный рабочий набор для домена, который шлет через ESP:

SPF: v=spf1 include:spf.esp-provider.ru -all. DKIM: CNAME или TXT-запись с ключом, выданным ESP. DMARC: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com.

Если ошибок в записях нет, а письмо все равно в спаме, смотрите разбор ситуации <a href="/blog/spf-dkim-dmarc-pass-no-inbox">SPF, DKIM и DMARC проходят, но письмо в спаме</a>. Проверить записи домена можно через <a href="/tools/email-domain-check">проверку домена</a> и <a href="/tools/dmarc-check">проверку DMARC</a>.

4. Шаг 2: репутация и жалобы

Если аутентификация в порядке, следующий слой: репутация домена и IP в глазах почтовика. Здесь первичны данные самих почтовых платформ, а не сторонние тесты.

Для Gmail подключите Google Postmaster Tools и смотрите долю жалоб (spam rate). Google указывает ориентиры: держите долю жалоб ниже 0,1%, значение 0,3% и выше считается недопустимым и ведет к фильтрации. В API v2 дополнительно доступны доли прохождения SPF, DKIM, DMARC и соответствие требованиям отправителей.

Для Mail.ru подключите Mail.ru Postmaster. Метрика "Репутация, %" показывает средний процент жалоб за 30 дней, меньше лучше. Пороги зависят от месячного объема отправок:

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

5. Шаг 3: разделяем сервисные письма и рассылки

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

1. Поддомены под потоки. Транзакционные письма отправляйте с поддомена вида notify.example.com или order.example.com, маркетинговые с promo.example.com, корпоративную почту оставьте на основном домене. У каждого поддомена свои SPF и DKIM, DMARC можно покрыть одной записью на основном домене с политикой для поддоменов (sp=).

2. Разные отправители. Адрес отправителя для сервисных писем: order@notify.example.com. Для рассылок: news@promo.example.com. Это помогает и фильтрам, и получателям различать потоки.

3. Разные IP или пулы у ESP. Крупные ESP позволяют выделить транзакционный трафик в отдельный пул. Если объемы небольшие, достаточно разделения по поддоменам.

4. Никакой рекламы внутри транзакционных писем. Вставка промо-блоков в письмо подтверждения заказа повышает жалобы и смешивает потоки в глазах фильтра.

Подробнее про архитектуру потоков: <a href="/blog/poddomeny-i-potoki-email">поддомены и потоки email</a>.

6. Шаг 4: контент письма и поведение получателей

Когда аутентификация и репутация чистые, а конкретный тип писем (например, только код подтверждения) все равно в спаме, смотрите в само письмо.

Типичные триггеры для сервисных писем: ссылка ведет на домен, отличный от домена отправителя; используется сокращатель ссылок; письмо состоит из одной картинки; есть вложение (PDF с чеком фильтры проверяют жестче); тема письма содержит слова, характерные для фишинга, без имени бренда.

Отдельная причина, специфичная для транзакционного трафика: письма уходят на несуществующие или опечаточные адреса (пользователь ошибся при регистрации). Рост жестких отказов ухудшает репутацию. Включите подтверждение адреса при регистрации и обрабатывайте отказы: жесткие адреса удаляйте сразу. Про типы отказов: <a href="/blog/bounce-hard-soft">возвраты и отказы</a>.

7. Как проверить, что проблема решена

После изменений проверку делайте в три приема.

Первый: отправьте реальное тестовое письмо с боевого потока на свои ящики в Gmail, Mail.ru и Яндексе. Откройте оригинал письма и посмотрите заголовки: строки Authentication-Results должны показывать spf=pass, dkim=pass, dmarc=pass. Разобрать заголовки поможет <a href="/tools/email-header-analyzer">анализатор заголовков письма</a>, он работает в браузере.

Второй: сверьте Postmaster-метрики через 3-7 дней. В Google Postmaster Tools должна расти доля прохождения SPF, DKIM, DMARC и снижаться доля жалоб. В Mail.ru Postmaster смотрите доставку и процент жалоб по дням.

Третий: настройте постоянный контроль, а не разовую проверку. PostmastersTool собирает данные Google Postmaster Tools и Mail.ru Postmaster, проверяет DNS-записи доменов (SPF, DKIM, DMARC, MX, черные списки), принимает DMARC-отчеты и присылает уведомления о пересечении порогов в Telegram или на почту. Так вы узнаете о деградации транзакционного потока до жалоб клиентов.