OTP-письма попадают в спам: как финтех теряет клиентов при входе

Из всех трансакционных писем коды подтверждения — самые неумолимые. Счёт на спаме — досадно. Сброс пароля на спаме — раздражает. Но OTP на спаме означает, что клиент не может войти прямо сейчас, не может провести платёж, не может верифицировать карту. Он переделает попытку, получит то же самое, и в итоге откажется или напишет в поддержку. Любой из этих путей стоит денег.

Почему фильтры не верят коротким письмам с кодами

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

Ещё хуже, что OTP-письма идут из автоматов с минимальной персонализацией. Нет имени адресата в теле. Нет контекста предыдущего общения. Нет обычного подвала с контактами. Для Байесова или нейросетевого фильтра такое письмо выглядит как шаблон — и шаблоны от неизвестных отправителей помещаются в карантин ровно для этого.

Добавьте финансовый стек ключевых слов — «подтвердить», «аккаунт», «транзакция», «верифицировать» — и получите сообщение, которое набирает высокий балл по всем фишинговым эвристикам.

Штраф за выдачу под известный бренд

Финтех — самая подделываемая категория в фишинге. PayPal, Coinbase, Revolut, Wise, все крупные банки — тысячи фишинговых шаблонов в день за каждый. Mail-провайдеры отвечают жёсткими эвристиками к письмам, выглядящим как приходящие из этих брендов, и слово «выглядят» распространяется и на похожие домены.

Если ваш финтех называется «Кэшли» и на прошлой неделе фишеры использовали «Кэшили», ваш домен может получить штраф подозрения по лексической близости. Редко документировано, но видно в данных по размещению: новые финтех-бренды почти всегда стартуют с худшей inbox rate, чем эквивалентные SaaS-бренды, даже при идентичной аутентификации.

Защита двойная: выстройте цепь аутентификации, исключающую подделку (DMARC на reject, BIMI с проверенным логотипом), и отделите критичный трафик аутентификации от всего остального.

Отдельный поддомен для аутентификации

Самый мощный ход для OTP-доставимости — отдельный поддомен. Отправляйте аутентификацию с auth.example.com, маркетинг с news.example.com, а счета и платежи с billing.example.com. Каждый поддомен развивает собственную репутацию в глазах провайдеров.

Почему это критично: если маркетинговый лист провалится на квартал и репутация домена упадёт, OTP-письма обычно пострадают от коллатерального урона. При разделении поддоменов auth-поддомен изолирован — у него свой паттерн отправки, своя сигнатура взаимодействия (фактически 100% доставка, почти нулевые жалобы), и Gmail оценит его именно по этому.

Настройте отдельные SPF-include'ы, отдельные DKIM-ключи для каждого поддомена, и DMARC-политику, применяемую к организационному домену но проверяемую последовательно у всех поддоменов.

Отдельный IP для трансакционной почты

Поверх разделения поддоменов трансакционный поток должен идти с другого IP, чем маркетинг. Большинство ESP предлагают это как платный уровень — Postmark, SparkPost Transactional, SendGrid с dedicated IP — и это стоит деньги. Shared IP, обслуживающий и ваши OTP, и чей-то чужой newsletter, это постоянная рулетка репутации.

Для высокообъёмных финтехов два dedicated IP — минимум: один для аутентификации (OTP, сброс пароля, алерты логина) и один для трансакционных (счета, выписки, KYC). Разогревайте их как отдельные активы репутации.

SMS-fallback, срабатывающий на самом деле

Какой бы хорошей ни была ваша почтовая настройка, OTP-доставка никогда не будет 100%. Кто-то упадёт на спам, кто-то попадёт под корпоративные фильтры, кто-то просто будет на деградировавшем почтовом ящике. Решение — fallback-канал, срабатывающий автоматически.

Практический паттерн: отправьте OTP по email и запустите таймер на 30 секунд. Если пользователь не завершил верификацию за 30 секунд — отправьте тот же OTP по SMS (или push, если у вас установленное приложение). Отследите, какой канал сработал. После трёх отказов на email переведите пользователя на SMS-first на 30 дней.

Этот паттерн требует, чтобы система OTP поддерживала мультиканальную доставку и отслеживала события завершения — это инженерная работа, не просто настройка. Но для финтеха математика всегда сходится: один восстановленный пользователь окупает SMS-бюджет на месяцы.

BIMI для визуального доверия

BIMI (Brand Indicators for Message Identification) показывает ваш проверенный логотип рядом с письмами в поддерживающих клиентах. Для финтеха сигнал доверия значительный: пользователь Gmail, видящий ваш проверенный логотип, гораздо менее вероятно спутает легитимный OTP с фишингом, гораздо менее вероятно его удалит, и гораздо более вероятно поиграет с будущими письмами от вас.

BIMI требует DMARC на p=quarantine или p=reject и Verified Mark Certificate (VMC) для максимального отображения в Gmail. VMC стоит около $1500 в год, что круглое число для любого финтеха, реально верифицирующего пользователей на объёме. Настройте.

Как тестировать OTP-доставимость

OTP-тестирование имеет одно критическое отличие от обычных проверок: нельзя полагаться на обобщённый seed-список. OTP-генератор должен буквально отправить реальный код на реальный адрес, и нужно проверить не просто доставку но и время прохождения.

• Запустите реальные OTP-отправки из вашей production-системы на seed-ящики Gmail, Outlook, Yahoo, ProtonMail и минимум один региональный провайдер (Yandex если Европа/Россия, QQ если APAC).
• Измеряйте end-to-end время доставки. Код, прибывший на 90 секунд позже, функционально неудача для пользователя, ожидающего мгновенную верификацию.
• Проверяйте размещение, не просто доставку. Доставка на спам — это доставка, но пользователь никогда не увидит её вовремя.
• Мониторьте еженедельно минимум. OTP-доставимость деградирует медленно и беззвучно — ежеквартальный обзор слишком поздно.

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