Письма восстановления пароля не приходят? Пользователи молчат

Письмо восстановления пароля — это то, о чём никто не думает до момента, когда оно сломается. И никто не заметит, когда сломается молча. Стандартный дашборд вашего сервиса показывает доставлено: 99.4% и зелёную галочку. Что дашборд не показывает — куда именно попали эти 99.4% писем: в Входящие, в Спам, в Промоакции или в гостевой лист провайдера, который отбросит письмо через три часа, а пользователь к этому времени уже сдался и ушёл к конкуренту.

Это самый жестокий вид утечки, потому что он невидим в каждой метрике, на которую вы смотрите. Пользователь ничего не скажет. Письмо ушло. Пользователь есть в БД. Провайдер показывает, что письмо принято. А человек перестал пользоваться вашим продуктом, потому что не смог вернуться в аккаунт.

Почему пользователи молчат

Когда письмо восстановления не приходит, в голове пользователя за двадцать секунд происходит примерно следующее:

1. Нажимает «Забыл пароль», вводит почту, ждёт.
2. Обновляет входящие. Ничего нет.
3. Смотрит спам. Может, там, а может, ничего.
4. Пробует ещё раз. То же самое.
5. Сдаётся. Закрывает вкладку.

Шага 6, где он пишет тикет в поддержку, никогда не будет. Логика по умолчанию — молчание. Добавьте рядом кнопку конкурента в поиске Google, и аккаунт потерян без единого сигнала.

Почему письма сброса блокируются сильнее, чем маркетинг

Парадоксально, но трансакционная почта не автоматически доверяется. Gmail, Outlook и Yahoo не различают noreply@yourapp.com и newsletter@yourapp.com — фильтры смотрят на репутацию домена, выравнивание DKIM/SPF/DMARC, репутацию IP и вовлечённость получателя.

Письма восстановления пароля имеют несколько черт, которые работают против них в спам-фильтрах:

• Короткое, шаблонное содержимое. Фильтры связывают короткие тексты с одинаковым контентом для тысяч получателей — это то же самое, что массовые рассылки.
• Длинные случайные токены. URL с 64-символьным hex-токеном выглядит подозрительно для некоторых фильтров, особенно если домен ссылки отличается от домена в From.
• Срочный язык. «Действительно 15 минут», «Сейчас же», «Не делитесь этой ссылкой» — всё это триггерит эвристики, настроенные против фишинга.
• Ноль сигналов вовлечения. На письма не отвечают, редко пересылают, открывают за долю секунды. Фильтры интерпретируют отсутствие вовлечения как низкокачественную почту.

Что реально измеряет дашборд провайдера

Любой провайдер — SendGrid, Postmark, Mailgun, SES, Resend — отчитывается по трём основным метрикам: доставлено, отскочило и жалобы. Ни одна из них не отвечает на вопрос, который вас реально волнует: попало ли письмо в входящие?

«Доставлено» означает, что сервер получателя вернул 2xx-ответ. Это не значит, что Gmail положил письмо в папку Входящие. Gmail может принять письмо и молча положить его в Спам или Промоакции, а провайдер всё равно учтёт это как доставленное. С точки зрения провайдера, всё, что дальше передачи — не его проблема.

# что видит провайдер               # что видит пользователь
доставлено: 99.4%                    Входящие:    61%
отскочило:   0.4%                    Промоакции:  18%
жалобы:      0.2%                    Спам:        19%
                                     Не получит:   2%

Единственный способ узнать реальное соотношение Входящие/Спам/Промоакции — отправить настоящий шаблон сброса пароля на контролируемые ящики у каждого провайдера и прочитать заголовки, чтобы увидеть, куда письмо реально попало.

Простая схема мониторинга сброса пароля

Шаг 1. Отправляем реальный шаблон, не сглаженный тест

Самая большая ошибка — тестировать на чистом теле. Ваш спам-скор зависит от точного HTML, который получат пользователи — точная кнопка, точный текст, точный домен ссылки. Тестируйте с фиксчей, который рендерит реальный шаблон с одноразовым токеном.

Шаг 2. Покрываем каждого провайдера, которым пользуются ваши юзеры

Для потребительского продукта это минимум Gmail, Outlook.com / Hotmail, Yahoo, iCloud, AOL. Для CIS-аудитории добавьте Mail.ru, Yandex, Rambler. Для B2B добавьте Office 365, Google Workspace (отличается от потребительского Gmail), Zoho, Fastmail.

Шаг 3. Запускаем каждый час или после деплоя

Доставляемость падает постепенно. Проверка раз в месяц пропустит трёхдневный штраф от Gmail. Проверка каждый час — или минимум после деплоя — поймает регрессию до того, как она оттянет неделю пользователей.

# пример: POST после каждого деплоя
curl -X POST https://check.live-direct-marketing.online/api/tests \
  -H "Content-Type: application/json" \
  -d '{
    "email": "reset-probe@yourapp.com",
    "subject": "Сброс пароля",
    "html": "<отрендеренный шаблон>"
  }'

Чиним то, что покажет тест

Если отчёт размещения показывает больше пары процентов в Спаме у какого-то провайдера, решение обычно попадает в одну из трёх категорий:

• Разрывы в аутентификации. SPF защищает IP, DKIM подписывает домен, DMARC выравнивает их. Отсутствие любого одного — самая частая причина попадания писем сброса в спам, особенно в Gmail и Yahoo после требований 2024 года для массовых отправителей. Чеклист SPF/DKIM/DMARC.
• Смешанный трафик на одном домене. Отправляйте трансакцию с поддомена (auth.yourapp.com) отдельно от маркетинга (news.yourapp.com). Одна плохая маркетинговая кампания не должна сжечь репутацию сброса пароля.
• Красные флаги в шаблоне. Уберите срочность заглавными, сделайте так, чтобы домен ссылки совпадал с From-доменом, убирайте встроенные картинки где возможно. Минимальный HTML-шаблон с текстовой альтернативой всегда перебивает красиво оформленный для трансакционной почты.

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