Письмо подтверждения заказа в спаме: потерянный доход

Покупатель нажимает кнопку "Купить". Деньги прошли. На экране появляется "Спасибо за покупку". В следующую минуту между вашей checkout-системой и ящиком клиента где-то теряется письмо подтверждения. Когда оно не приходит совсем, или приходит, но в спам — начинается предсказуемая цепочка убытков, и большинство из них никогда не появятся в дашборде вашей почтовой платформы.

Это проблема, которую магазины недооценивают, потому что изнутри всё выглядит нормально. Заказы приходят. На дашборде горит «письмо отправлено». Платежная система Яндекс.Касса или Stripe отправляют свои квитанции на своей инфраструктуре и вообще не зависят от вашей репутации домена. На странице "Спасибо" правильно отображается номер заказа. Всё нормально. Кроме того, что клиент письмо не видит.

Сколько стоит одно потерянное подтверждение

Вот что на самом деле теряет магазин на каждом подтверждении, упавшем в спам:

• Звонок в поддержку. «Мой заказ прошёл?» — один из топ-3 запросов в любую техподдержку e-commerce. Полная стоимость одного тикета с учётом ЗП, систем, аутсорса — от 150 до 400 рублей. Звонок обходится в 3 раза дороже.
• Повторный заказ. Значительная часть клиентов, не видев подтверждение, попробует заказать снова, предположив, что первая попытка провалилась. Теперь вы должны либо вернуть деньги (теряете комиссии обоих платежей), либо отправить дубль товара (затраты на доставку + лог обратно, когда покупатель поймёт).
• Риск чарджбека. Встревоженный клиент, не нашедший подтверждение, иногда звонит в банк раньше, чем вам. Чарджбек обходится в 500–1500 рублей плюс штрафы процессора, к тому же накапливаются против вашего risk score.
• Негативный отзыв. «Не получил письмо подтверждения» — один из самых частых жалоб на Яндекс.Карты, 2GIS и Avvo для магазинов. Один отзыв влияет на десятки будущих покупателей.
• Потеря lifetime value. Клиент, у которого был запутанный первый заказ, статистически менее вероятно вернётся. Разница между довольным и растерянным покупателем отчётливо видна на графиках retention по когортам.

Всё вместе одно потерянное подтверждение обходится магазину в 600–2000 рублей прямого убытка плюс снижение LTV. Потеряйте хотя бы один процент подтверждений из тысячи заказов в месяц — цифра становится неудобной быстро.

Почему письма подтверждения попадают в спам чаще, чем кажется

Несколько факторов толкают письмо-подтверждение в фильтры:

1. Шаблон набит ценами и ссылками. Подтверждение с 12 SKU, фото товаров и ссылками отслеживания выглядит в глазах фильтра как маркетинговая рассылка.
2. Путаница с отправителем. Много магазинов отправляют подтверждение через свой ESP (Mailchimp, Convertkit, GetResponse) на shared IP пулу, который также носит маркетинг. Репутация от рекламных рассылок растекается по трансакционным письмам в одном потоке.
3. Несоответствие From-домена. Клиент заказал наshop.example.ru, а подтверждение приходит отgetresponse-mail.com. DMARC это не любит, и фильтры тоже.
4. Форматирование цен и скидок. Крупные суммы, коды скидок, фразы вроде «скидка 50% на следующий заказ» часто появляются в подтверждениях. Фильтры, которые изучали эти паттерны на спам-рассылках, применяют их и сюда.

Как реально измерить доставку подтверждения

Логика теста проста: разместите тестовый заказ с seed-адресом, затем посмотрите заголовки и папку пришедшего подтверждения. Вручную это утомительно. Автоматизация — это работа на полчаса.

Способ A: seed-адреса как реальные клиенты

Разместите реальные заказы (с возвратом денег) с seed-адресами на каждый крупный провайдер: Gmail, Mail.ru, Yandex, Outlook, Yahoo. Смотрите заголовки пришедшего подтверждения, определяйте, в какой папке оно лежит. Работает для любой платформы, требует немного скриптинга.

Способ B: отправить свой HTML в тест доставки

Большинство платформ позволяют экспортировать отрендеренный HTML реального подтверждения. Загрузите этот HTML в сервис проверки доставки, который отправит одно письмо на seed-ящики по всем провайдерам и покажет, где оно приземлилось.

curl -X POST https://check.live-direct-marketing.online/api/tests \
  -H "Content-Type: application/json" \
  -d '{
    "email": "order-check@example.ru",
    "subject": "Подтверждение заказа №10042",
    "html": "<ваш HTML подтверждения>"
  }'
# → вернёт ссылку на результаты и размещение в каждом провайдере за ~15 минут

Способ C: непрерывный мониторинг в CI при деплоях

Если вы часто меняете шаблон подтверждения, встройте тест доставки в CI так, чтобы регрессия в deliverability ломала билд, как и ошибка в unit-тестах.

Как чинить. По приоритету

• Выравнить DKIM/SPF/DMARC. Большинство магазинов настраивают эти записи на маркетинговом субдомене, но не на трансакционном. Невыравненный DMARC на подтверждении заказа — самая частая причина спама в Gmail и Yahoo. Используйте чеклист SPF/DKIM/DMARC.
• Разделить трансакционное и маркетинговое. Используйте отдельный субдомен для подтверждений (orders.shop.ru vs news.shop.ru). Неудачная чёрная пятница на маркетинговом не должна утопить ваши подтверждения на две недели.
• Урезать шаблон. Подтверждению не нужны hero-картинки, карусели рекомендаций, баннеры со скидками. Каждый элемент повышает шанс, что фильтр классифицирует письмо как рекламу.
• Матчить From домену магазина. Клиент только что отдал деньгиshop.ru; письмо должно приходить отorders@shop.ru, не от third-party сервиса. Настройте custom sending domain в вашем ESP.
• Мониторить, не предполагать. После каждой смены DNS или шаблона перезапустите тест доставки. Держите дашборд — скрытые регрессии — это вся проблема.

Частые вопросы