Как отправлять письма из приложения, чтобы они попадали во «Входящие»

Чтобы надежно отправлять письма из приложения, используйте сервис рассылки, а не свой почтовый ящик, отправляйте письма с адреса на собственном домене и добавьте DNS-записи, которые выдает сервис, чтобы проходили SPF, DKIM и DMARC. Держите транзакционные письма (сброс пароля, чеки, подтверждения) отдельно от маркетинговых, отправляйте каждое только тем, кто его ждет, и обрабатывайте отказы доставки и отписки. Сначала добейтесь правильной аутентификации: это самая частая причина, по которой письма приложения попадают в спам.

Транзакционные и маркетинговые письма

В коде эти два типа писем выглядят похоже, но почтовые сервисы и закон относятся к ним очень по-разному.

Разделяйте их. Если маркетинговая кампания получает жалобы на спам, вы не хотите, чтобы из-за нее страдали письма для сброса пароля с того же потока. Частый подход — отдельные поддомены: например, mail.example.com для писем аккаунта и news.example.com для рассылок. Некоторые сервисы разделяют эти потоки внутри себя. Например, Postmark описывает свои транзакционные и массовые «потоки сообщений» как работающие на отдельной инфраструктуре отправки (по состоянию на сентябрь 2026 года).

Выбор сервиса

Приложение не должно отправлять письма само со своего сервера. Сервисы рассылки берут на себя инфраструктуру, репутацию IP-адресов, повторные попытки и обработку отказов. Известные варианты: Postmark, Resend, SendGrid, Amazon SES и Mailgun. У каждого есть HTTP API и доступ по SMTP. Цены и тарифы меняются, поэтому сравнивайте их на сайтах провайдеров.

На что смотреть:

• Специализация. Одни сервисы сосредоточены на транзакционной почте, другие объединяют транзакционные и маркетинговые письма.
• Удобство для разработчика. Понятный API, официальные библиотеки для вашего языка, полезные логи, которые показывают, доставлено ли письмо, отклонено или отмечено как спам.
• Вебхуки для отказов, жалоб и доставок, чтобы приложение могло на них реагировать.
• Шаблоны: хранятся у провайдера или в вашем коде. Шаблоны в коде можно версионировать и тестировать.
• Регион и обработка данных, если есть требования к месту обработки данных.
• Стоимость при вашем объеме, включая то, что происходит после превышения бесплатного лимита.

Для рассылок по списку часто лучше подходит отдельный сервис новостных рассылок или email-маркетинга, чем встроенные в приложение функции кампаний.

Настройте домен отправителя

Отправляйте письма с собственного домена, например hello@example.com, а не с адреса Gmail или Outlook. Почта с бесплатного адреса, отправленная через сторонний сервис, не проходит проверки аутентификации и с большой вероятностью будет отфильтрована.

Рассмотрите отдельный поддомен только для отправки. Например, Resend рекомендует отправлять письма с поддоменов вроде updates.example.com, чтобы изолировать репутацию отправки (по состоянию на сентябрь 2026 года). Это также отделяет почтовые DNS-записи от записей основного сайта.

Затем провайдер выдаст DNS-записи, которые нужно добавить там, где управляется DNS вашего домена. Если DNS для вас в новинку, сначала прочитайте как работают домены и DNS.

SPF

SPF (Sender Policy Framework) — это TXT-запись со списком серверов, которым разрешено отправлять письма от имени вашего домена. Получатель проверяет, есть ли отправляющий сервер в этом списке.

• У домена должна быть только одна SPF-запись. Если вы подключаете провайдера, добавьте его в существующую запись, а не создавайте вторую.
• При проверке SPF допускает не более 10 DNS-запросов. Длинные цепочки include: могут превысить этот лимит и привести к сбоям.
• Многие провайдеры настраивают SPF на поддомене для обратного пути, который просят создать, поэтому основную SPF-запись вы можете и не трогать.

DKIM

DKIM (DomainKeys Identified Mail) добавляет к каждому письму криптографическую подпись. Провайдер подписывает письмо закрытым ключом, а вы публикуете соответствующий открытый ключ как DNS-запись (TXT или CNAME, в зависимости от провайдера). Получатель проверяет подпись, чтобы убедиться, что письмо отправлено авторизованным отправителем и по дороге не было изменено.

Шаг «подтвердить домен» у провайдера в основном касается DKIM. Не пропускайте его.

DMARC

DMARC связывает остальные два механизма. Это TXT-запись по адресу _dmarc.yourdomain.com, которая сообщает получателям:

• Выравнивание: домен в видимом адресе отправителя должен совпадать с доменом, который прошел проверку SPF или DKIM.
• Политику: что делать с письмами, не прошедшими проверку, — p=none (только отчеты), p=quarantine (считать подозрительными, часто в спам) или p=reject (отклонять).
• Отчеты: куда отправлять сводные отчеты (rua=), чтобы видеть, кто отправляет письма от вашего домена.

Разумный путь — начать с p=none и адреса для отчетов, убедиться, что ваша легитимная почта проходит проверку, затем перейти к quarantine, а в итоге к reject. Строгая политика также сильно затрудняет подделку вашего домена.

Что требует Gmail

По состоянию на сентябрь 2026 года правила отправителей Google выглядят так:

• Все отправители писем на личные адреса Gmail должны использовать SPF или DKIM, корректные прямые и обратные DNS-записи для серверов отправки, TLS, а уровень спам-жалоб в Postmaster Tools должен быть ниже 0,3%.
• Массовые отправители (больше 5000 писем в день на Gmail) должны использовать SPF и DKIM, запись DMARC (политика p=none допустима), выравнивание домена отправителя, а также отписку в один клик и видимую ссылку на отписку в маркетинговых и подписных письмах.

Серверные части настраивает провайдер. DNS-записи и обработку отписок делаете вы. Даже если вы далеки от 5000 писем в день, соблюдение правил для массовых отправителей — самый простой способ оставаться в безопасности.

Встройте отправку в приложение

Когда домен подтвержден:

1. Сохраните API-ключ как секрет на стороне сервера, никогда не в коде фронтенда. См. что такое переменные окружения и секреты.
2. Отправляйте письма с сервера после того, как действие, которое запускает письмо, успешно выполнено.
3. Не заставляйте пользователя ждать письмо. Для всего, что сложнее самого простого приложения, ставьте отправку в очередь и повторяйте попытку при временных ошибках, чтобы медленный ответ провайдера не тормозил регистрацию.
4. Записывайте результат — ID сообщения и статус у провайдера, — но не логируйте ключ и полные тексты писем с персональными данными.
5. Обрабатывайте вебхуки для отказов и жалоб: перестаньте писать на адреса, которые получили жесткий отказ или были отмечены как спам.

Пример промпта с основными требованиями:

Отправляй транзакционные письма через [PROVIDER], используя серверный секрет [ENV_NAME], от имени «Acme hello@mail.acme.com». Отправляй приветственное письмо после регистрации и подтверждение бронирования после сохранения брони. Храни шаблоны в коде, с текстовой версией рядом с HTML. Ставь отправку в очередь и повторяй временные ошибки до трех раз. Логируй ошибки провайдера, но никогда не ключ API. Добавь эндпоинт вебхука, который помечает адреса как недоставляемые при жестких отказах и жалобах, и пропускает их в будущем.

Письма аккаунта — ссылки для подтверждения, ссылки для входа и сброс пароля — относятся к входу в систему. Как добавить вход в приложение объясняет, как эти сценарии связаны между собой. Сделайте такие ссылки одноразовыми и короткоживущими.

Привычки для доставляемости

Аутентификация помогает письму считаться надежным. Поведение помогает оставаться во «Входящих».

• Отправляйте только то, что ждут. Подтвержденные регистрации, явное согласие на маркетинговые письма, никаких купленных списков.
• Упрощайте отписку во всем, что не является строго транзакционным, и выполняйте ее сразу.
• Прогревайте новые домены. Совсем новый домен, который в первый день рассылает тысячи писем, выглядит подозрительно. Начинайте с транзакционной почты и постепенно наращивайте объем.
• Чистите списки. Немедленно удаляйте адреса с жесткими отказами и подумайте об удалении тех, кто давно ничего не открывал.
• Пишите по-человечески. Понятная тема, узнаваемое имя отправителя, текстовая часть, немного картинок и ссылки на ваш домен. Не используйте сокращатели ссылок.
• Следите за показателями. Добавьте домен в Google Postmaster Tools и время от времени читайте отчеты DMARC.
• Указывайте настоящий адрес для ответа, который кто-то читает. Ответы — хороший сигнал и полезная обратная связь.

Тестирование без рассылки спама

• Используйте тестовый режим или песочницу провайдера, если она есть, или отправляйте письма на адреса, которые принадлежат вам.
• В разработке отправляйте письма в тестовый ящик, принимающий всю почту, а не реальным пользователям. База с настоящими на вид адресами — простой способ случайно написать посторонним людям.
• Проверьте каждый шаблон в нескольких клиентах: Gmail в браузере, почтовое приложение на телефоне, Outlook, а также в темной теме.
• Посмотрите заголовки тестового письма: они показывают, прошли ли SPF, DKIM и DMARC.

Правовые основы

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

Чек-лист по письмам

• Выбран сервис рассылки; API-ключ хранится как серверный секрет
• Отправка с собственного домена или поддомена, а не с бесплатного ящика
• Добавлены записи SPF, DKIM и DMARC, и они проходят проверку
• Транзакционная и маркетинговая почта разделены
• Отправка ставится в очередь с повторами; результаты логируются
• Обрабатываются вебхуки отказов и жалоб
• Есть отписка в нетранзакционных письмах, и она работает сразу
• Шаблоны проверены в нескольких клиентах; тестовые письма не доходят до реальных пользователей

Отправка писем из приложения Mythex

Mythex не включает встроенного сервиса отправки писем для создаваемых вами приложений, поэтому провайдера, например Resend, SendGrid или Postmark, подключаете вы. Сохраните его API-ключ как секрет проекта: агент может запросить его через карточку с секретами в чате. Нужные письма опишите обычными словами. Стартовый промпт есть в документации, в разделе отправка email из приложения. Если вы купили домен через Mythex на тарифе Pro, TXT- и CNAME-записи провайдера добавляются в настройках DNS домена. См. пользовательские домены.

Вопросы