Як надсилати електронні листи з вашого застосунку (і потрапляти у вхідні)

Щоб надсилати листи з застосунку надійно, використовуйте провайдера розсилки, а не власну поштову скриньку, надсилайте з адреси на власному домені й додайте 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, який повідомляє одержувачам:

• Вирівнювання: домен у видимій адресі From має збігатися з доменом, який пройшов перевірку 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 %.
• Масові відправники (понад 5 000 повідомлень на день на Gmail) мають використовувати SPF і DKIM, запис DMARC (політика p=none допустима), вирівнювання домену From, а також відписку в один клік і видиме посилання для відписки в маркетингових та підписних повідомленнях.

Провайдер бере на себе серверні частини. DNS-записи й обробка відписок — за вами. Навіть якщо ви далекі від 5 000 на день, виконання правил для масових відправників — найпростіший спосіб бути в безпеці.

Вбудуйте відправлення в застосунок

Після перевірки домену:

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

Приклад промпту, що охоплює основи:

Надсилай транзакційні листи через [PROVIDER] із серверним секретом [ENV_NAME], від імені "Acme hello@mail.acme.com". Надсилай вітальний лист після реєстрації та підтвердження бронювання після збереження бронювання. Тримай шаблони в коді, з текстовою версією поруч із HTML. Став відправлення в чергу і повторюй тимчасові збої до трьох разів. Журналюй помилки з відповіддю провайдера, але ніколи не записуй API-ключ. Додай кінцеву точку вебхука, яка позначає адреси як недоставні при постійних відмовах і скаргах, і пропускай ці адреси надалі.

Листи облікового запису — посилання для підтвердження, посилання для входу та скидання пароля — є частиною входу. Як додати вхід до застосунку пояснює, як ці процеси пов'язані між собою; робіть такі посилання одноразовими й короткочасними.

Звички для доставюваності

Автентифікація допомагає вважатися надійним відправником. Поведінка утримує вас у вхідних.

• Надсилайте лише те, чого очікують. Підтверджені реєстрації, чітка згода на маркетингові листи, жодних купованих списків.
• Робіть відписку простою для всього, що не є строго транзакційним, і виконуйте її одразу.
• Прогрівайте нові домени. Зовсім новий домен, що надсилає тисячі листів у перший день, виглядає підозріло. Починайте з транзакційної пошти й поступово збільшуйте обсяг.
• Тримайте списки чистими. Одразу видаляйте адреси з постійними відмовами і розгляньте видалення людей, які довго нічого не відкривали.
• Пишіть по-людськи. Чітка тема, впізнаване ім'я відправника, текстова частина, мало зображень і посилання на ваш власний домен. Уникайте скорочувачів посилань.
• Моніторте. Зареєструйте домен у Google Postmaster Tools і час від часу читайте звіти DMARC.
• Використовуйте справжню адресу для відповіді, яку хтось читає. Відповіді — хороший сигнал і корисний зворотний зв'язок.

Тестування без спаму для нікого

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

Юридичні основи

Правила відрізняються залежно від країни. Загалом маркетингові листи в багатьох місцях потребують згоди, мають ідентифікувати відправника та пропонувати робочу відписку; транзакційні листи розглядаються інакше, але не слід використовувати їх, щоб непомітно додати рекламу. Якщо ви збираєте адреси зі сторінки листа очікування, вкажіть, що й коли ви надсилатимете та зберігатимете, і як саме людина приєдналася. Якщо сумніваєтеся, перевірте правила для місць, де знаходяться ваші користувачі.

Чек-лист для листів

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

Надсилання листів із застосунку Mythex

Mythex не включає вбудованої служби надсилання листів для застосунків, які ви створюєте, тож вам потрібен провайдер, наприклад Resend, SendGrid або Postmark. Збережіть його API-ключ як секрет проєкту — агент може попросити його за допомогою картки секретів у чаті — і опишіть потрібні листи звичайними словами. У документації є стартовий промпт у розділі надсилання листів із застосунку. Якщо ви купили домен через Mythex на тарифі Pro, можна додати TXT- і CNAME-записи провайдера в налаштуваннях DNS домену; див. власні домени.

Запитання