Чому листи з сайту потрапляють у спам

Найдорожча поломка на сайті — та, яку ніхто не бачить. Форма відправляється, зелений напис «Дякуємо, ми зв'яжемося» з'являється, відвідувач іде задоволений. Лист із заявкою при цьому лежить у «Спамі» або не існує взагалі. Власник дізнається про це через місяць, коли клієнт передзвонює з питанням «то ви взагалі працюєте?».

Тут ідеться саме про листи, які відправляє сайт. Заявка з форми зворотного зв'язку, підтвердження замовлення в магазині, лист про відновлення пароля, повідомлення менеджеру про нове замовлення. Це не про розсилку і не про те, як прибрати чужий спам зі своєї скриньки.

Правила масових розсилок — це не ваші правила

Більшість порад в українській видачі написана для email-маркетологів. Звідти в голову власника сайту потрапляють три чужі тези, які тільки заважають діагностиці.

Теза перша. «Потрібні SPF, DKIM і DMARC, інакше Gmail не прийме». У довідці Google для відправників вимога до всіх звучить інакше: налаштуйте SPF або DKIM. Саме через «або». Зв'язку SPF плюс DKIM плюс DMARC Google вимагає окремо, і тільки від тих, хто шле понад 5 000 листів на добу на адреси Gmail. У Microsoft свої вимоги, оголошені у квітні 2025, теж адресовані доменам понад 5 000 листів на добу і теж стосуються споживчих скриньок Outlook.com, Hotmail.com і Live.com. Сайт із десятком заявок на день у ці пороги не потрапляє.

Теза друга. «З 2024 року в кожному листі має бути відписка в один клік». FAQ Google для відправників виводить транзакційні листи з-під цієї вимоги дослівно й називає серед прикладів рівно наші випадки: скидання пароля, підтвердження бронювання, підтвердження надісланої форми. Технічно відписка в один клік описана в RFC 8058: заголовок List-Unsubscribe-Post, HTTPS POST на адресу з List-Unsubscribe, а сам лист має бути підписаний DKIM. І обов'язкова вона для маркетингових та підписних листів. Не для листа «ваше замовлення №1043 прийнято».

Теза третя. «Тримайте скарги нижче 0,3%». Цю стелю Google і Yahoo називають у розділах про масових відправників. У вас на десяти листах на добу знаменника для такого відсотка просто немає.

Що з правил Google стосується всіх відправників без винятку: SPF або DKIM, PTR-запис для IP сервера-відправника, TLS при передаванні, формат листа за RFC 5322. Найчастіше ламаються перший рядок цього списку і третій.

І одне окреме попередження звідти ж. Google прямо забороняє підставляти gmail.com у поле From чужих листів. Це найтиповіша помилка форми зворотного зв'язку. Скрипт бере адресу відвідувача й ставить її у From, щоб менеджеру було зручно натиснути «Відповісти». Якщо відвідувач із Gmail, ваш сервер щойно відправив лист від імені gmail.com, не маючи на це права.

Порядок діагностики — як зрозуміти, що саме зламано

Перед тим як щось налаштовувати, дайте відповідь на одне питання. Лист не доходить чи лист доходить у «Спам»? Це дві різні поломки з різними причинами. Плутанина між ними і є головна причина, чому люди тижнями крутять DNS-записи без результату.

Крок 1. Лист узагалі відправляється? Дивимось лог поштового сервера або лог застосунку. Якщо логування відправки в застосунку вимкнене, вмикаємо: це коротка правка. Дуже часто виявляється, що функція відправки повернула помилку, а форма показала відвідувачу зелену галочку, бо результат ніхто не перевіряв.

Крок 2. Сервер отримувача прийняв лист? У логах шукаємо відповідь приймаючої сторони. Відмова виглядає як конкретний текст із кодом. Український i.ua у власній довідці називає два формулювання, які бачить відправник: «Spam message rejected» і «Rejected because sender host is in a black list». Microsoft для невідповідних масових відправників з 2025 року теж відхиляє на рівні SMTP, а не кладе в «Небажані», з кодом 550; 5.7.515 Access denied, sending domain does not meet the required authentication level. Якщо відмова є, лист не «загубився». Його свідомо не взяли, і текст відмови вже містить причину.

Крок 3. Лист прийнято, але лежить у «Спамі»? Дивимось службові заголовки отриманого листа. У них є результати перевірок: пройшов SPF чи ні, є DKIM-підпис чи немає, що сказав DMARC. Що з цим робити, розбираю нижче.

Крок 4. Перевіряємо на кількох поштовиках одразу. Відправляємо тестові листи на Gmail, на ukr.net, на i.ua, на корпоративну скриньку клієнта. Якщо лист лягає в спам скрізь — проблема у відправника. Якщо тільки в одного оператора — проблема у відносинах саме з ним.

Це рівно та послідовність, за якою ми розбираємо доставність на підтримці сайту: спочатку факт відправки, потім факт прийому, і лише потім DNS.

SPF, DKIM і DMARC простою мовою

Три абревіатури відповідають на три різні питання. Номери стандартів наводжу навмисне, щоб будь-яке твердження нижче можна було перевірити, а не брати на віру за словом підрядника.

SPF (RFC 7208, квітень 2014) відповідає на питання «чи мав цей сервер право відправляти пошту від імені вашого домену». Власник домену перелічує в DNS дозволені хости, а сервер-одержувач цю авторизацію перевіряє. Причина, чому SPF узагалі знадобився, сформульована в абстракті стандарту: наявні поштові протоколи ніяк не обмежують, що відправник вписує в MAIL FROM і в команду HELO/EHLO. Тобто без SPF будь-хто в інтернеті може відправити лист «від вас».

Найчастіше спотикаються на механізмі all наприкінці запису. Це правило за замовчуванням для всього, що не збіглося з попередніми, а знак перед ним задає результат: + — пропустити, - — вважати підробкою, ~ — м'яка відмова, ? — нейтрально. Запис, що закінчується на +all, дозволяє відправляти від вашого імені всій планеті. Такі записи ми досі зустрічаємо на живих сайтах.

DKIM (RFC 6376, вересень 2011) відповідає на питання «чи справді цей домен взяв на себе відповідальність за лист». Домен підписує лист криптографічно, а перевіряльник дістає відкритий ключ прямо з DNS домену-підписанта. Важливо розуміти межі: стандарт прямо каже, що DKIM не гарантує наскрізної цілісності листа і не шифрує його. Він лише прив'язує домен до повідомлення. Не більше. Але й цього достатньо, бо саме прив'язки бракує в анонімному SMTP.

DMARC (RFC 7489, березень 2015; у травні 2026 перевиданий як RFC 9989 зі статусом Standards Track, який скасовує 7489) відповідає на питання «що робити, якщо перевірки не пройшли». Домен оголошує політику й отримує звіти.

Ключове поняття DMARC — вирівнювання ідентифікаторів. Домен у полі From має збігатися з доменом, який підтвердив SPF або DKIM. Ось де ламається та сама форма зворотного зв'язку, що ставить у From адресу відвідувача. Сервер відправляє від імені вашого домену, у From стоїть чужий, вирівнювання немає, DMARC не проходить. Лікується це в один рядок коду. У From ставимо свою адресу (noreply@вашдомен.ua), а адресу відвідувача — у Reply-To. Менеджер так само тисне «Відповісти» і потрапляє куди треба.

Політику задає тег p, і в нього три значення. none — власник не висловлює побажань щодо обробки, quarantine — вважає такі листи підозрілими, reject — вважає їх явною ознакою неправомірного використання домену, і відхилення має відбуватися ще під час SMTP-сесії. У новій редакції формулювання none стало ще відвертішим: власник домену не висловлює жодних побажань.

І тут головне, чого не роблять майже ніде. Навіть p=none варто виставити заради звітів. Агрегатні звіти DMARC показують, які саме відправники шлють пошту від вашого домену, з якими результатами перевірок і що з цією поштою роблять. Інакше ви працюєте наздогад. А от ставити одразу reject на домені, з якого шле пошту сайт, CRM, бухгалтерія і хтось четвертий, кого ви забули, — надійний спосіб покласти собі пошту за один вечір.

Причини, які не лікуються записами в DNS

Частина випадків, які до нас приходять, не має стосунку до автентифікації взагалі.

PHP mail() замість SMTP. Стандартна форма на PHP кличе функцію mail(), яка віддає лист локальному агенту хостингу. Документація PHP прямо попереджає: ця функція не призначена для помітних обсягів, бо відкриває й закриває SMTP-сокет на кожен лист. Практичний висновок для власника: лист іде «звідкись із хостингу», а не з вашої поштової скриньки, і поводиться відповідно. Ми на всіх проєктах відправляємо через автентифікований SMTP того ж поштового сервісу, де живе домен. Тоді лист виходить із того самого сервера, що прописаний у SPF, і має DKIM-підпис.

IP сервера, з якого шле сайт. Google вимагає, щоб публічний IP сервера-відправника мав PTR-запис, що резолвиться в ім'я хоста. На шаред-хостингу цей запис ставить хостер і вказує він на хостера, а не на ваш домен. За нашою практикою це разом із спільним IP на сотні сайтів — головна причина, чому пошта з дешевого хостингу доходить гірше за пошту з тієї ж скриньки через SMTP. Твердження про спільний IP — саме наш промисловий досвід, а не рядок із документації, тож перевіряйте його на своєму випадку.

Чорні списки. Spamhaus веде PBL — перелік діапазонів кінцевих користувачів, з яких пошту взагалі не можна віддавати напряму на чужий MX. Він покриває понад 1,4 мільярда адрес IPv4, майже 40% маршрутизованого простору. Тобто «мій сервер у списку» не завжди означає покарання за спам. Іноді це просто категорія адреси. Окремо є SBL, база IP-джерел спаму в реальному часі. Сервери-одержувачі відкидають з'єднання з таких адрес ще на етапі підключення, до того як лист узагалі буде переданий. Тому в логах ви побачите не «лист у спамі», а обрив з'єднання.

Українські поштовики. i.ua у довідці називає свої тексти відмов, і з ними вже можна працювати. З ukr.net складніше: офіційні сторінки для відправників на момент написання віддають редирект на форму відновлення акаунта, тож публічних правил у відкритому доступі немає. Це саме по собі проблема для відправника: сперечатися нема з чим. Лишається емпірика — тестові листи, читання відмов і перехід на нормальний SMTP. Переказувати чужі перекази неопублікованих правил ми не будемо.

Що робити і в якому порядку

Порядок не випадковий. Він іде від дешевого й дієвого до дорогого й рідко потрібного.

1. Прибрати чужу адресу з поля From. Свій домен у From, адреса відвідувача — в Reply-To. Правка на кілька рядків, а лікує найчастішу поломку.
2. Перейти з mail() на автентифікований SMTP. Домен відправки збігається з доменом у From, лист виходить із сервера, який має право його відправляти. За нашою практикою — день-два на типовому сайті разом із тестами.
3. Перевірити SPF. Один запис на домен, усі реальні відправники перелічені, наприкінці ~all або -all, а не +all.
4. Увімкнути DKIM на поштовому сервісі й покласти ключ у DNS.
5. Поставити DMARC із p=none і адресою для звітів. Місяць дивитись, хто насправді шле пошту від вашого домену, і лише потім думати про посилення політики.
6. Перевірити IP у Spamhaus і подивитись PTR. Якщо IP у PBL — питання не в DNS, а в тому, що ви шлете напряму з адреси, з якої цього робити не можна.
7. Додати запасний канал для лідів. У нас на цьому сайті заявки їдуть у Telegram, а не поштою. Саме тому, що поштовий лист губиться мовчки, а повідомлення в чат або приходить, або видно, що не прийшло.

Для магазину до цього додається окрема робота: лист-підтвердження замовлення, лист про зміну статусу, лист про оплату. Це вже не одна форма, а серія транзакційних листів, і кожен має свій шаблон і свою чергу відправки. Про це ми пишемо в матеріалах про розробку інтернет-магазину.

Чесно скажу: майже завжди справа не в містичних «спам-фільтрах», а в тому, що сайт шле листи так, як їх слали до появи всіх цих вимог, і ніхто ці листи жодного разу не перевіряв після запуску.

Питання, які ставлять найчастіше