Чому транзакційні листи вашого застосунку потрапляють у спам (і як це виправити)

Чому доставка транзакційних листів — зовсім інша справа

Між маркетинговими й транзакційними листами є принципова різниця, яку багато розробників не помічають, коли вперше всерйоз задумуються про доставлюваність. Маркетингові листи — розсилки, рекламні кампанії, анонси — надходять підписникам, які на них погодилися. Вони можуть пережити випадкові затримки й навіть зрідка потрапляння в спам. Якщо розсилка йде в спам для 2% вашого списку, це прикро, але бізнес працює далі.

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

І все ж транзакційні листи часто налаштовують менш дбайливо, ніж маркетингові кампанії. Багато розробників беруть той код надсилання пошти, який дає їхній фреймворк, замість того щоб свідомо побудувати систему листів підтвердження, налаштовують його зі спільним SMTP-сервером, деплоять, один раз тестують на власній скриньці — у якої поблажливі пороги спаму — і йдуть далі. Проблеми проявляються лише тоді, коли реальні користувачі Gmail, Outlook чи Yahoo скаржаться, що листів немає. На той момент усе вже тижнями тихо не працює в продакшені.

SPF: основа автентифікації пошти

Sender Policy Framework (SPF) — це DNS-запис TXT на вашому домені-відправнику, який повідомляє світові, які поштові сервери можуть надсилати листи від вашого імені. Коли Gmail отримує лист нібито від [email protected], він робить DNS-запит, щоб знайти SPF-запис вашого домену. Якщо IP-адреса сервера, який насправді надіслав лист, є у вашому SPF-записі, лист проходить SPF. Якщо SPF-запису немає взагалі — або сервера-відправника в ньому немає, — до листа ставляться з підозрою ще до будь-якої оцінки вмісту.

Налаштувати SPF просто, якщо знаєте, що робите. Додайте TXT-запис у DNS свого домену. Значення залежить від вашого провайдера розсилки. Якщо ви користуєтеся SendGrid: v=spf1 include:sendgrid.net ~all. Якщо AWS SES: v=spf1 include:amazonses.com ~all. Якщо Mailgun: v=spf1 include:mailgun.org ~all. Точне значення include ви знайдете в документації провайдера. Суфікс ~all означає «м’яку відмову» (soft fail) — листи з серверів, яких немає в списку, позначаються, але не відхиляються одразу. Коли переконаєтеся, що ваш SPF-запис повний і правильний, можна перейти на -all (hard fail), що вказує серверам-одержувачам повністю відхиляти неавторизовану пошту.

Одна поширена пастка — ліміт у 10 DNS-запитів. SPF-записи, що об’єднують кілька директив include:, можуть перевищити цей ліміт, і тоді SPF не проходить, навіть якщо всі ваші сервери формально є в списку. Перевірте свій SPF-запис за допомогою MXToolbox — він чітко покаже проблеми з кількістю запитів. Як SPF, DKIM і DMARC пов’язані між собою, добре пояснює документація SendGrid про автентифікацію пошти.

DKIM: криптографічний доказ, що лист ніхто не змінював

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

Без налаштованого DKIM зловмисникам значно легше підробити ваш домен — надсилати листи, що виглядають як від [email protected], але насправді надіслані кимось зовсім іншим. Саме так працюють фішингові кампанії. Спам-фільтри теж це знають, тому лист без дійсного DKIM-підпису з домену, який мав би його мати, викликає підвищену підозру. Spamhaus та інші сервіси репутації враховують історію DKIM-підписів в оцінці репутації домену.

DKIM налаштовується через вашого провайдера розсилки. Він генерує пару ключів, зберігає приватний ключ у своїй інфраструктурі й дає вам публічний ключ, який треба додати в DNS як TXT-запис. Щойно цей запис опубліковано й він поширився, кожен лист, який провайдер надсилає від вашого імені, автоматично матиме дійсний DKIM-підпис. Більшість великих провайдерів — SendGrid, Mailgun, Amazon SES, Postmark — проводять вас через цей процес під час початкового налаштування. Якщо ви це пропустили, поверніться й налаштуйте зараз.

DMARC: рівень політик, що все об’єднує

DMARC (Domain-based Message Authentication, Reporting, and Conformance) спирається на SPF і DKIM і визначає, що мають робити сервери-одержувачі, коли лист не проходить ці перевірки. Він також запроваджує «вирівнювання» (alignment) — вимогу, щоб домен у заголовку From справді збігався з доменом, який пройшов SPF або DKIM. Це не дає зловмисникам проходити перевірку SPF з одним доменом, підробляючи інший у видимій адресі відправника.

Правильний підхід до DMARC — запроваджувати його поступово. Почніть із політики лише для моніторингу: v=DMARC1; p=none; rua=mailto:[email protected]. p=none каже серверам-одержувачам нічого не робити з листами, що не пройшли перевірку, а лише надсилати вам звіти. Ці зведені звіти покажуть, які сервери надсилають пошту від вашого імені і чи проходять вони SPF і DKIM. Переглядайте їх кілька тижнів, перш ніж змінювати політику.

Коли переконаєтеся, що вся легітимна пошта проходить перевірку, переходьте на p=quarantine (листи, що не пройшли перевірку, ідуть у спам), а згодом на p=reject (такі листи відхиляються повністю). Такий поступовий перехід захищає репутацію домену від підробок і дає час виявити легітимні джерела пошти, які ви могли пропустити. Політика DMARC p=reject разом із пройденими SPF і DKIM робить ефективне видавання себе за ваш домен майже неможливим.

Репутація IP: чому важить сервер-відправник

Навіть з ідеальними SPF, DKIM і DMARC ваші листи можуть потрапляти в спам, якщо IP-адреса, з якої їх надіслано, має погану репутацію. Сервери-одержувачі ведуть — або перевіряють у сторонніх сервісах — чорні списки й оцінки репутації IP-адрес відправників. До листів з IP, який має історію розсилання спаму або є в чорних списках сервісів на кшталт Spamhaus, ставитимуться з підозрою незалежно від налаштувань автентифікації.

Якщо ви використовуєте спільну IP-адресу від спільного хостингу чи дешевого SMTP-сервісу, ваша репутація пов’язана з усіма іншими, хто користується цим IP. Один спамер у тому самому спільному пулі може зруйнувати доставлюваність для всіх відправників на цьому IP. Це один із найвагоміших аргументів на користь спеціалізованого провайдера транзакційної пошти — SendGrid, Amazon SES, Postmark, Mailgun — замість надсилання листів прямо з сервера застосунку чи через спільний SMTP-сервіс.

Новий IP для розсилки також доведеться поступово «прогріти». Різкий сплеск обсягу листів зі свіжого IP для серверів-одержувачів виглядає як поведінка спамера. Почніть із менших обсягів і збільшуйте їх поступово протягом днів чи тижнів. Більшість спеціалізованих провайдерів автоматично прогрівають IP, якщо ви у спільному пулі, або дають графік прогріву, якщо у вас виділений IP.

Вміст і тема листа: що спрацьовує на фільтри

Окрім автентифікації та репутації IP, спам-фільтри оцінюють і сам вміст листа. Певні шаблони стабільно призводять до класифікації як спам. Спам-слова в темі — «FREE», «GUARANTEED», «ACT NOW», надлишок знаків оклику, ВЕЛИКІ ЛІТЕРИ — очевидні, і більшість розробників їх уникає. Менш очевидні: надто розмиті теми («Важливе повідомлення для вас»), надто тривожні («Ваш акаунт буде закрито») або надто рекламні для того, що має бути транзакційним листом.

Важить і співвідношення тексту та зображень. Лист, що складається переважно із зображень і мінімуму тексту, — класичний шаблон спаму: масові розсильники використовують зображення, щоб приховати ключові слова від текстових фільтрів. Транзакційні листи мають бути переважно текстовими, з мінімумом зображень. Зламаний HTML — незакриті теги, некоректні атрибути — ще одна тривожна ознака. Завжди надсилайте текстову версію разом з HTML. Спам-фільтри ставляться до листів лише з HTML з підвищеною підозрою, а корпоративні поштові системи часто взагалі вирізають HTML.

Як правильно тестувати доставку листів

Найшвидший і найпрактичніший спосіб перевірити доставку — надіслати тестовий лист на свіжу скриньку тимчасової пошти й перевірити і «Вхідні», і «Спам». Це дає миттєвий однозначний відгук: доходить лист до вхідних чи його відфільтровано. На відміну від тестування з вашим власним Gmail — де ви, можливо, вже в білому списку як частий відправник, — свіжа тимчасова адреса не має жодної історії з вашим доменом, тож точніше імітує перший контакт нового користувача.

Варто перевіряти, що лист підтвердження справді надходить, щоразу, коли ви змінюєте щось, що може вплинути на доставку: міняєте провайдера розсилки, суттєво оновлюєте HTML-шаблон, змінюєте домен-відправник, додаєте новий піддомен для розсилки чи деплоїте в нове середовище (staging, продакшен). Це займає дві хвилини й дає беззаперечний доказ. Альтернатива — чекати, поки користувачі поскаржаться, — означає, що проблеми з доставкою вже тихо тривали невідомо скільки часу.

Окрім перевірки «вхідні чи спам», скористайтеся перевіркою стану пошти від MXToolbox, щоб оцінити загальний стан домену: SPF, DKIM, DMARC, статус у чорних списках і налаштування MX-записів в одному місці. Зробіть це частиною чек-листа перед запуском для кожного нового застосунку чи домену-відправника. Також перегляньте рекомендації OWASP щодо найкращих практик безпеки, пов’язаних з електронною поштою.

Відмови та скарги на спам: метрики, які мають значення

Дві метрики непропорційно сильно впливають на довгострокову доставлюваність: частка відмов (bounce rate) і частка скарг на спам. Частка відмов понад 2% повідомляє серверам-одержувачам і вашому провайдеру, що ви надсилаєте на багато некоректних або неіснуючих адрес — а це шаблон, пов’язаний із купленими базами адрес і спам-операціями. Навіть якщо все інше ви робите правильно, висока частка відмов спричинить проблеми з доставкою. Видаляйте адреси з жорсткими відмовами зі списку розсилки одразу й назавжди.

Частка скарг на спам понад 0,1% (одна скарга на тисячу надісланих листів) — поріг, після якого більшість провайдерів розсилки починають обмежувати ваш акаунт. Gmail Postmaster Tools напряму показує частку скарг, якщо ви його налаштували. Відстежуйте ці метрики в панелі свого провайдера. Якщо частка скарг зростає, з’ясуйте чому: чи не надсилаєте ви листи користувачам, які явно не давали згоди? Чи не надто часто ви пишете? Чи немає розбіжності між тим, що користувачі очікували, і тим, що вони отримують?

Повний чек-лист доставлюваності

• SPF-запис: DNS-запис TXT на домені-відправнику з переліком усіх авторизованих серверів. Перевірте за допомогою MXToolbox.
• DKIM: криптографічний підпис, налаштований через провайдера розсилки, публічний ключ опубліковано в DNS.
• DMARC: почніть із моніторингу p=none, після аналізу зведених звітів переходьте на p=quarantine, а потім на p=reject.
• Спеціалізований провайдер розсилки: SendGrid, SES, Postmark чи Mailgun — не сервер застосунку й не спільний SMTP.
• Чисті теми листів: конкретні, доречні, без спам-слів, без надлишку розділових знаків чи великих літер.
• HTML + простий текст: завжди додавайте обидві версії. Ніколи не надсилайте листи лише з HTML.
• Без скорочувачів посилань: використовуйте повні прямі URL у тексті листа й у посиланнях підтвердження.
• Посилання для відписки: додавайте навіть у транзакційні листи, де це доречно, — деякі провайдери цього вимагають.
• Фізична адреса: вимагається CAN-SPAM та подібними правилами в багатьох юрисдикціях.
• Обробка жорстких відмов: видаляйте адресу одразу; ніколи не повторюйте надсилання після жорсткої відмови.
• Моніторинг скарг: налаштуйте Gmail Postmaster Tools; стежте за панеллю з часткою скарг.
• Тестування скриньки: надсилайте тестові листи на свіжі тимчасові скриньки перед кожним деплоєм і після будь-якої зміни шаблону чи конфігурації.
• Перевірка стану в MXToolbox: включіть її в чек-лист перед запуском для кожного нового домену й середовища.

Коли варто перейти на спеціалізований сервіс транзакційної пошти

Якщо ваш застосунок надсилає хоч якісь листи, які користувач мусить отримати, щоб усе працювало, — посилання для підтвердження, скидання пароля й квитанції, якими завершується повний шлях реєстрації та оплати, — вам варто з першого дня користуватися спеціалізованим провайдером транзакційної пошти. Це недорого (часто безкоштовно до десятків тисяч листів на місяць), надійність значно вища, ніж у саморобного SMTP, а інфраструктуру доставлюваності — спільні пули IP з керованою репутацією, автоматичний DKIM-підпис, обробку відмов і скарг — підтримують команди, чия робота полягає саме в тому, щоб листи потрапляли у вхідні.

Найпоширеніша помилка «зроби сам» — запускати поштовий сервер на тому самому IP, що й вебзастосунок, або користуватися вбудованим SMTP дешевого хостинг-провайдера. Такі IP регулярно потрапляють у чорні списки сервісів на кшталт Spamhaus, бо хостинг спільний із недобросовісними користувачами. Перехід на спеціалізованого провайдера транзакційної пошти зазвичай займає пів дня й одразу покращує доставлюваність. Це одне з найефективніших інфраструктурних покращень, доступних невеликій команді. Командам, які дбають про приватність, варто також ознайомитися з рекомендаціями Electronic Frontier Foundation щодо відповідального поводження з даними користувачів, коли йдеться про пошту. Крім того, перевірка адрес за відомими базами витоків через Have I Been Pwned може доповнити ваш захист від шахрайства під час створення нових акаунтів.