--- title: "Почему письма с сайта попадают в спам" description: "Заявка с формы не доходит, а подтверждение заказа лежит в «Спаме». Порядок диагностики, SPF, DKIM и DMARC простым языком, PTR и PHP mail против SMTP." url: https://apri-code.com/ru/blog/chomu-lysty-z-saitu-potraplyayut-u-spam/ language: ru 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-ru.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/ru/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/ru/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/ru/poslugy/pidtrymka/) можно тем самым письмом, которое, надеемся, дойдёт. --- Source: https://apri-code.com/ru/blog/chomu-lysty-z-saitu-potraplyayut-u-spam/