---
title: "Чому листи з сайту потрапляють у спам"
description: "Заявка з форми не доходить, а підтвердження замовлення лежить у «Спамі». Порядок діагностики, SPF, DKIM і DMARC простою мовою, PTR і PHP mail проти SMTP."
url: https://apri-code.com/blog/chomu-lysty-z-saitu-potraplyayut-u-spam/
language: uk
published: 2026-08-14
updated: 2026-08-14
author: "Богдан Кононенко"
publisher: Apricode
---

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

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

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

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

Більшість порад в українській видачі написана для 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, не маючи на це права.

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

![Розвилка діагностики: гілка «лист не доходить» із текстами відмов поштових серверів і гілка «лист доходить у Спам» із перевіркою службових заголовків](https://apri-code.com/api/media/file/lysty-spam-diagnoz-uk.svg)

Перед тим як щось налаштовувати, дайте відповідь на одне питання. Лист **не доходить** чи лист **доходить у «Спам»**? Це дві різні поломки з різними причинами. Плутанина між ними і є головна причина, чому люди тижнями крутять 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, на корпоративну скриньку клієнта. Якщо лист лягає в спам скрізь — проблема у відправника. Якщо тільки в одного оператора — проблема у відносинах саме з ним.

Це рівно та послідовність, за якою ми розбираємо доставність на [підтримці сайту](https://apri-code.com/poslugy/pidtrymka/): спочатку факт відправки, потім факт прийому, і лише потім 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

![Стелаж із десятками однакових вузлів, від яких іде один спільний кабель назовні](https://apri-code.com/api/media/file/slot-chomu-lysty-z-saitu-potraplyayut-u-spam-h2-4.webp)

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

**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, а не поштою. Саме тому, що поштовий лист губиться мовчки, а повідомлення в чат або приходить, або видно, що не прийшло.

Для магазину до цього додається окрема робота: лист-підтвердження замовлення, лист про зміну статусу, лист про оплату. Це вже не одна форма, а серія транзакційних листів, і кожен має свій шаблон і свою чергу відправки. Про це ми пишемо в матеріалах про [розробку інтернет-магазину](https://apri-code.com/poslugy/internet-magazyny/).

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

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

### Чому лист із форми не приходить взагалі, а в спамі його теж немає?

Значить, він або не був відправлений, або його відхилили ще під час SMTP-сесії. Дивіться лог відправки на своєму боці та текст відмови: у ньому буде причина, як-от «Spam message rejected» чи «Rejected because sender host is in a black list» у формулюваннях i.ua.

### Мені точно потрібні всі три записи — SPF, DKIM і DMARC?

Мінімум за правилами Google для всіх відправників — SPF **або** DKIM. Зв'язку з усіх трьох Google і Microsoft вимагають від тих, хто шле понад 5 000 листів на добу. Але DMARC із `p=none` варто поставити навіть маленькому сайту: він нічого не блокує й дає звіти про те, хто шле пошту від вашого імені.

### Чи треба додавати відписку в лист із підтвердженням замовлення?

Ні. FAQ Google прямо виводить транзакційні листи з-під вимоги відписки в один клік і серед прикладів називає скидання пароля, підтвердження бронювання та підтвердження надісланої форми. Вимога стосується маркетингових і підписних листів.

### Скільки часу займає розбір?

За нашою практикою діагностика — один робочий день: логи, заголовки, тестові листи на кілька поштовиків, перевірка IP і DNS. Виправлення — від кількох годин (поле From) до кількох днів (перехід на SMTP, налаштування записів, повторне тестування). Далі місяць спостереження за DMARC-звітами.

**Ми поставили SPF, а нічого не змінилося.** Найчастіше причина в тому, що лист відправляється не з того сервера, який перелічений у SPF, або в From стоїть чужий домен і вирівнювання за DMARC не працює. Ще варіант — записів SPF два, і це помилка сама по собі.

### Чи допоможе перехід на інший хостинг?

Іноді так, але це рідко перший крок. Спочатку прибираємо чужу адресу з From і переходимо на SMTP — після цього IP хостингу перестає бути точкою відправки, і питання його репутації знімається саме собою.

Якщо ви прямо зараз не знаєте, доходять листи з вашого сайту чи потрапляють у спам, це вже відповідь. Перевірка займає день і показує, скільки заявок пішло в нікуди, поки форма показувала зелену галочку. [Замовити діагностику пошти](https://apri-code.com/poslugy/pidtrymka/) можна тим самим листом, який, сподіваємось, дійде.

---

Source: https://apri-code.com/blog/chomu-lysty-z-saitu-potraplyayut-u-spam/