Почему письма с сайта попадают в спам

Самая дорогая поломка на сайте — та, которую никто не видит. Форма отправляется, зелёная надпись «Спасибо, мы свяжемся» появляется, посетитель уходит довольным. Письмо с заявкой при этом лежит в «Спаме» или не существует вовсе. Владелец узнаёт об этом через месяц, когда клиент перезванивает с вопросом «так вы вообще работаете?».

Речь здесь именно о письмах, которые отправляет сайт. Заявка с формы обратной связи, подтверждение заказа в магазине, письмо о восстановлении пароля, уведомление менеджеру о новом заказе. Это не про рассылку и не про то, как убрать чужой спам из своего ящика.

Правила массовых рассылок — это не ваши правила

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

Для магазина к этому добавляется отдельная работа: письмо-подтверждение заказа, письмо о смене статуса, письмо об оплате. Это уже не одна форма, а серия транзакционных писем, и у каждого свой шаблон и своя очередь отправки. Об этом мы пишем в материалах о разработке интернет-магазина.

Скажу честно: почти всегда дело не в мистических «спам-фильтрах», а в том, что сайт шлёт письма так, как их слали до появления всех этих требований, и никто эти письма ни разу не проверял после запуска.

Вопросы, которые задают чаще всего