Транзакционная почта — это письма, которые сервис отправляет по конкретному событию: подтверждение регистрации, восстановление пароля, уведомление о заказе, счёт. В отличие от рассылок, их нельзя отложить или пропустить: без них пользователь не завершит действие. Поэтому проверять их нужно до запуска, и делать это по списку, а не на память. Ниже — готовый набор проверок и типичные ошибки, которые он ловит.
Какие письма относятся к транзакционным
К этой группе принято относить сообщения, которые обслуживают уже начатое действие. Человек зарегистрировался — приходит подтверждение. Забыл пароль — приходит ссылка для смены. Оформил заказ — приходит подтверждение и потом чек. Началась подписка — приходит уведомление о списании.
Общее у них то, что получатель ждёт письмо и зависит от него. Если подтверждение не придёт, регистрация не завершится. Если не придёт ссылка на смену пароля, доступ будет потерян. Это и определяет требования: такие письма должны доходить, содержать верные данные и не дублироваться без причины.
Сюда же примыкают служебные уведомления о безопасности: вход с нового устройства, смена адреса, отключение защиты. Их тоже стоит держать в одном списке проверок, потому что цена ошибки у них такая же высокая.
Проверяем, что письмо вызывается в нужный момент?
Первая часть чек-листа — про то, что письмо вообще отправляется и отправляется один раз.
| Что проверяем | Как понять, что всё в порядке |
|---|---|
| Точка срабатывания | письмо уходит после завершения действия, а не до него |
| Получатель | адрес тот, кто действие выполнил, а не последний сохранённый |
| Повтор действия | второе письмо не уходит без причины |
| Отмена действия | если действие не завершилось, письмо не отправляется |
| Отказ в операции | при ошибке приходит понятное сообщение, а не молчание |
| Частота | повторные запросы не превращаются в поток писем |
Последняя строка особенно важна и её чаще всего пропускают. Если пользователь нажал кнопку пять раз, сервис не должен отправить пять писем. Ограничение на частоту существует именно для этого, и проверять его нужно вместе с обычным сценарием, а не отдельно от него.
Что должно быть внутри письма
Вторая часть — про содержание. Здесь полезно проверять не текст на глаз, а конкретные вещи.
Подстановки. Любое место, куда подставляется значение, — имя, номер заказа, сумма, дата — должно быть заполнено. Самая частая ошибка — незаполненное поле, которое остаётся в виде служебной вставки. Заметить её можно только целенаправленной проверкой, потому что письмо при этом отправляется и выглядит «почти нормально».
Ссылки. Каждая ссылка должна вести туда, куда обещано, и открываться. Отдельно стоит проверить, что в ссылке нет адреса тестового стенда: такая ошибка не видна разработчику, который тестирует внутри своей среды, и мгновенно проявляется у первого же пользователя.
Код или значение. Если в письме есть код подтверждения, он должен совпадать с тем, который ждёт система. Если есть номер заказа — совпадать с заказом.
Время и формат. Дата и сумма должны быть в формате, понятном получателю. Стоит проверить и поведение на границах: смену месяца, разные часовые пояса, сумму с копейками.
Отписка. Даже в транзакционных письмах полезно понимать, какие из них допускают отказ от рассылки, а какие нет. Если письмо содержит кнопку отписки, она должна работать; если не содержит — это должно быть осознанным решением, а не забытой строкой.
Язык. Если сервис многоязычный, письмо должно прийти на языке пользователя. Проверять нужно не только сам перевод, но и то, что язык определяется верно: например, что смена языка в интерфейсе влияет на последующие письма.
Почему письмо приходит дважды?
Потому что повторная доставка — это нормальное свойство почты, а не ошибка. Письмо может быть передано повторно, если система не получила подтверждение приёма. Защититься от этого на стороне отправителя нельзя.
Но у двойных писем есть и вторая причина, уже целиком наша: логика, которая вызывает отправку, может сработать дважды. Так бывает, если одно и то же событие обрабатывается повторно — например, из-за повтора запроса или из-за того, что два экземпляра приложения одновременно взялись за одну задачу.
Различить эти случаи важно. От повтора доставки защиты нет, и попытка бороться с ним в коде приведёт только к усложнению. От повторной отправки защита есть, и строится она на том, что операция отправки выполняется один раз для одного события. Полезно проверять это явно: выполнить одно действие и убедиться, что отправка произошла ровно один раз, даже если запрос пришёл дважды.
Что важно разработчику: идемпотентность, отказы и журналы
Первое — сделайте отправку идемпотентной. Повторная обработка одного и того же события не должна приводить к новому письму. Это защищает и от двойного нажатия, и от повторной доставки внутри системы.
Второе — предусмотрите поведение при неудаче. Отправка может не состояться: служба недоступна, адрес отклонён, превышено ограничение. Нужно понимать, что происходит в каждом случае: повторяет ли система попытку, уведомляет ли пользователя, попадает ли письмо в очередь. Молчаливая потеря письма — худший вариант, потому что человек ждёт и не понимает, что делать.
Третье — заполняйте шаблоны безопасно. Если значение для подстановки отсутствует, лучше показать понятную фразу, чем оставить служебную метку. Пустое место в письме выглядит как небрежность, а метка — как утечка внутреннего устройства.
Четвёртое — не храните в письмах лишнего. Ссылки не должны содержать данных, по которым можно войти без пароля, если только это не одноразовая ссылка с ограниченным сроком. Номера документов, полные платёжные данные и подобные сведения в тексте письма не нужны.
Пятое — следите за журналами. При разборе ошибок полезно видеть, что письмо было отправлено, кому и когда. Но текст письма целиком в журнал писать не стоит: вместе с ним туда попадут персональные данные и одноразовые ссылки, которые сможет прочитать любой, у кого есть доступ к логам.
Шестое — проверяйте отправку на тестовом адресе, а не на настоящем. Адрес из временной почты удобен тем, что он живёт ровно до конца проверки и не создаёт переписки, которую потом придётся чистить. Такой адрес — только инструмент испытаний: выдавать его за данные реального человека нельзя.
Как убедиться, что письмо не уйдёт в спам?
Это третья часть проверки, и она самая недооценённая. Письмо может быть отправлено, выглядеть правильно — и не дойти до папки входящих.
Начинать стоит с отправителя. Система должна отправлять письма с того адреса и домена, которые настроены для этого в её конфигурации, а не с произвольного значения. Если поле подставляется из данных пользователя, ошибка приведёт к тому, что получатель увидит странного отправителя и отправит письмо в спам сам.
Дальше — содержимое. Письма, которые слишком похожи на рекламу, хуже доходят. Формулировка, обещающая выгоду, и обилие ссылок в тексте вредят доставляемости. Для транзакционного письма это лишний риск: его задача — сообщить факт, а не продать что-то.
Отдельно проверьте, что письмо корректно отображается в разных почтовых клиентах. Особенно на телефоне, где узкая колонка ломает широкие таблицы и длинные строки. Письмо, которое выглядит аккуратно в веб-интерфейсе, на телефоне может превратиться в набор обрезанных строк — и тогда человек не поймёт, что ему пришло.
И проверьте все ссылки ещё раз, уже из самого письма. Ссылка может вести на страницу, которая открывается только внутри тестовой среды: для вас она рабочая, для получателя — ошибка.
Что делать дальше
Возьмите свой список писем и пройдите по нему сверху вниз: для каждого события проверьте точку срабатывания, получателя и содержимое. Затем отправьте себе несколько писем на адрес из временной почты и посмотрите, как они выглядят на экране телефона, а не только на широком мониторе. Если вы как раз строите проверки для рассылки, посмотрите материал о сравнении разового ящика и постоянных адресов — он помогает выбрать адрес под каждую задачу.