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

Форма на сайте отрабатывает без ошибок, скрипт рапортует «отправлено», а менеджер уверен, что заявок нет. Знакомая картина: письма с сайта месяцами падают в спам, и никто этого не замечает, пока клиент сам не спросит, почему ему не ответили. Причин два слоя: технический (DNS-записи, способ отправки, репутация IP-адреса) и содержательный (база адресов, контент, поведение получателей). В статье — оба слоя, наша история с чёрным списком Spamhaus, куда сервер клиента попал по вине соседа по хостингу, и конкретный порядок действий, если письма уже в спаме.

Почему никто не замечает, что письма уходят в спам

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

Косвенные признаки, по которым проблему можно поймать раньше:

• заявки с сайта резко «закончились», хотя трафик не падал;
• клиенты говорят, что не получали подтверждение заказа или ответ на письмо;
• в сервисе рассылок падает открываемость при том же составе базы;
• письма на адреса одного провайдера (например, Gmail) доходят, а на другой (Mail.ru) — нет.

Дальше важно разделить два потока писем, потому что причины и лечение у них разные. Первый — транзакционные письма: уведомления о заявках, подтверждения заказов, восстановление пароля. Их отправляет сам сайт, чаще всего прямо с сервера хостинга. Второй — маркетинговые рассылки, которые уходят через сервисы вроде Unisender или Mindbox. Спам-фильтры оценивают оба потока по одним и тем же правилам, но точки отказа у них свои: у транзакционных писем это обычно сервер и DNS-записи, у рассылок — база и контент.

Как почтовый сервис решает, что письмо — спам

Короткий ответ: по совокупности репутации отправителя, технической аутентификации, реакции получателей и содержимого письма. Ни один фактор в одиночку не отправляет письмо в спам, но провал по любому из них тянет вниз всю оценку.

Gmail, Яндекс Почта и Mail.ru проверяют примерно одно и то же:

• аутентификацию — подтверждает ли домен отправителя, что письмо действительно ушло с разрешённого сервера (записи SPF, DKIM, DMARC);
• репутацию IP-адреса и домена — сколько спама уходило с этого адреса раньше, числится ли он в чёрных списках;
• поведение получателей — как часто письма открывают, удаляют не читая и помечают кнопкой «Спам»;
• содержимое — вёрстку, соотношение картинок и текста, ссылки, характерные для спама формулировки.

Требования к отправителям при этом продолжают ужесточаться. С февраля 2024 года Google и Yahoo требуют от всех, кто отправляет на Gmail больше 5000 писем в сутки, обязательной настройки SPF, DKIM и DMARC, отписки в один клик и доли жалоб не выше 0,3% — полный список опубликован в руководстве Google для отправителей. А с ноября 2025 года Gmail перешёл от мягких мер к жёстким: письма без корректной аутентификации начали отклоняться с ошибками 5.7.25 и 5.7.26 — они уже не попадают даже в папку «Спам» (по данным PowerDMARC, ноябрь 2025 года). У Яндекса и Mail.ru формальные пороги другие, но логика та же: без аутентификации и с плохой репутацией во «Входящие» не попасть.

SPF, DKIM и DMARC: технический минимум

Это три DNS-записи домена, по которым принимающий сервер проверяет подлинность письма. Настраиваются один раз в панели управления DNS, работают для всех писем домена.

SPF перечисляет серверы, которым разрешено отправлять почту от имени домена. Принимающий сервер сверяет IP-адрес, с которого пришло письмо, с этим списком. Пример записи для домена, у которого почта на Яндексе, а сайт отправляет письма со своего сервера:

v=spf1 include:_spf.yandex.net ip4:203.0.113.10 ~all

DKIM — криптографическая подпись письма. Почтовый сервер подписывает каждое исходящее письмо закрытым ключом, а открытый ключ публикуется в DNS. Если письмо по дороге подменили или отправитель не владеет доменом, подпись не сойдётся.

DMARC — политика, которая говорит принимающему серверу, что делать с письмами, не прошедшими SPF и DKIM: ничего (p=none), отправлять в спам (p=quarantine) или отклонять (p=reject). Плюс адрес для отчётов:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.ru

Начинать стоит с p=none и недели-двух наблюдения за отчётами: они покажут все сервисы, которые отправляют почту от имени домена. Часто на этом этапе выясняется, что письма шлёт CRM, сервис рассылок и старый форум, о котором все забыли. Когда все легальные отправители внесены в SPF и подписывают письма DKIM, политику ужесточают.

Проверить, проходят ли ваши письма аутентификацию, можно без сервисов: в Gmail откройте письмо, меню «Ещё» → «Показать оригинал» — вверху будут результаты SPF, DKIM и DMARC.

Как «сосед» по хостингу отправил наши письма в спам

Случай из нашей практики, после которого проверка IP-адреса вошла в обязательную программу любого аудита.

Симптомы выглядели необъяснимо: уведомления о заявках с сайта клиента стабильно падали в спам, хотя SPF и DKIM были настроены и проходили проверку, контент — служебное письмо из трёх строк, никаких стоп-слов и подозрительных ссылок. По всем видимым признакам письмо было безупречным.

Причина нашлась не в письме. Мы проверили IP-адрес сервера через Spamhaus — крупнейшую базу данных о спамерах, на которую ориентируются почтовые провайдеры по всему миру. Адрес числился в спам-листе. При этом сам клиент спама не рассылал: сайт жил на виртуальном хостинге, где на одном сервере с одним IP-адресом соседствуют десятки чужих сайтов. Один из соседей — судя по всему, взломанный — рассылал спам, и репутацию общего IP-адреса испортил всем сразу.

На виртуальном хостинге репутация IP-адреса — общая. Ваши письма оценивают по поведению всех сайтов на сервере, включая те, о существовании которых вы не догадываетесь.

Что мы сделали. Первым же действием, как только увидели адрес в списке, сменили IP-адрес самого сервера: хостер выделил новый, с чистой репутацией, и доставка писем восстановилась почти сразу, без долгого ожидания. Дальше разобрались с причиной: заражённый аккаунт соседа был найден и заблокирован, по старому адресу подан запрос на исключение из списка (у Spamhaus это штатная процедура делистинга, для автоматических списков она занимает от нескольких часов до пары дней). А чтобы история не повторилась, отправку писем сайта перевели с локального сервера на SMTP почты домена: репутация писем больше не зависит от соседей.

Отдельно отмечу зеркальный сценарий: спам-рассыльщиком может оказаться и ваш собственный сайт, если его взломали. Устаревшая CMS с известными уязвимостями — типичная входная точка; чем это грозит и как закрыть дыры, мы разбирали на примере уязвимостей 1С-Битрикс. В этом случае в чёрный список попадаете уже вы, а страдают соседи.

Отправка с сайта: чем плоха функция mail() и что использовать вместо неё

Большинство сайтов на PHP по умолчанию отправляют письма функцией mail() — напрямую с веб-сервера. Для спам-фильтров такое письмо выглядит подозрительно по целому набору причин: IP хостинга не предназначен для почты и часто не имеет корректной обратной DNS-записи (PTR), репутация адреса общая на всех клиентов сервера, а заголовки письма собраны кое-как. Даже идеальный контент в таких условиях доходит нестабильно.

Рабочая схема надёжнее:

1. Заведите для сайта почтовый ящик на своём домене, например robot@example.ru, в Яндекс 360, VK WorkSpace или на почтовом сервере хостинга.
2. Настройте отправку с сайта через SMTP этого ящика с авторизацией. Для популярных CMS есть готовые модули и плагины, самописным проектам подойдёт библиотека вроде PHPMailer.
3. В поле From ставьте только адрес своего домена. Подстановка адреса клиента в From — верный способ провалить DMARC его почтового провайдера; адрес клиента укажите в Reply-To.
4. Когда транзакционных писем становится много или они критичны для бизнеса (интернет-магазин, личный кабинет), переходите на специализированный сервис транзакционных писем. Мы в Design Lab рекомендуем именно этот вариант: у таких сервисов выделенная почтовая инфраструктура, контроль репутации, статистика доставки и уведомления о письмах, которые не дошли. Из российских это Unisender Go, Notisend и RuSender; из западных показателен Resend, но у зарубежных сервисов будут сложности с оплатой из России.

Маркетинговые рассылки с хостинга сайта не отправляют вообще. Это работа сервисов рассылок: они следят за репутацией своих IP-адресов, автоматически обрабатывают отписки и жалобы.

Причины, которые не лечатся DNS-записями

Если техническая база в порядке, а рассылка всё равно в спаме, причина почти всегда в базе адресов или контенте. Сводка типичных ошибок — по материалам разбора 1PS.RU (searchengines.guru, февраль 2024) и нашей практики:

• купленная или собранная без согласия база — получатели жалуются, и порог 0,3% жалоб пробивается мгновенно; вдобавок это нарушение 152-ФЗ со штрафами до 500 тысяч рублей;
• нет заметной отписки — кто не нашёл кнопку «отписаться», нажимает «Спам», а для репутации это на порядок хуже;
• слишком частые письма — усталая аудитория сначала перестаёт открывать, потом жалуется;
• спам-лексика в теме и тексте — «бесплатно», «гарантированный доход», «только сегодня» и ещё пара сотен формулировок, на которые натренированы фильтры;
• письмо из одних картинок — классический приём спамеров, который фильтры давно знают; текста должно быть больше, чем изображений, у картинок — заполненный alt;
• битые и подозрительные ссылки — включая сокращатели ссылок и редиректы через сторонние домены.

Обратите внимание: двухэтапное подтверждение подписки (double opt-in) закрывает сразу две первых причины. Подписчик, который дважды подтвердил интерес, почти никогда не жмёт «Спам».

Как мы проверяем письма перед запуском: mail-tester.com

В Design Lab проверка почты входит в чек-лист сдачи каждого сайта. Основной инструмент — mail-tester.com. Работает он просто: сервис выдаёт одноразовый адрес, вы отправляете на него письмо с каждой формы сайта и получаете оценку по десятибалльной шкале с полным разбором.

В отчёте видно всё, о чём шла речь выше: результаты SPF, DKIM и DMARC, присутствие IP-адреса и домена в чёрных списках (включая Spamhaus), оценку контента фильтром SpamAssassin, ошибки HTML-вёрстки письма, проблемы со ссылками. Каждое замечание расшифровано, так что отчёт одновременно служит планом исправлений.

Наш внутренний норматив — 10 из 10 для транзакционных писем. Оценка ниже 8 означает, что письмо с заметной вероятностью не дойдёт, и сайт с такой почтой мы не сдаём. Бесплатных проверок у сервиса несколько в день — для приёмки одного сайта хватает.

Письма уже в спаме: порядок действий

Последовательность, по которой мы разбираем такие обращения. Двигайтесь сверху вниз, большинство проблем находится на первых трёх шагах.

1. Отправьте письмо с сайта на адрес mail-tester.com и посмотрите общий балл и список замечаний. Это диагноз за две минуты.
2. Проверьте IP-адрес сервера и домен в чёрных списках: spamhaus.org и MXToolbox покажут попадание в основные базы.
3. Проверьте SPF, DKIM и DMARC через «Показать оригинал» в Gmail. Нет хотя бы одной записи — начните с её настройки.
4. IP в чёрном списке: напишите хостеру, пройдите процедуру делистинга на сайте списка. Если сервер виртуального хостинга попадает в списки регулярно — переносите отправку почты на внешний SMTP или меняйте хостинг.
5. Переведите письма сайта с mail() на SMTP с авторизацией, как описано выше.
6. Зарегистрируйтесь в постмастере Mail.ru — он показывает репутацию домена, процент жалоб и попадание писем в спам у крупнейшего провайдера Рунета. У Яндекса аналогичный сервис закрыт, ориентируйтесь на отчёты DMARC.
7. Попросите лояльных подписчиков и постоянных клиентов найти письмо в спаме и нажать «Не спам», а лучше добавить ваш адрес в контакты. Репутация восстанавливается медленно, закладывайте на это две-четыре недели стабильной аккуратной отправки.

Что в итоге

Доставляемость писем — это в итоге вопрос гигиены: корректные DNS-записи, отправка через авторизованный SMTP, чистая база и регулярная проверка чёрных списков. Всё перечисленное проверяется за один день, а окупается каждой дошедшей заявкой. Если разбираться самостоятельно некогда — покажем, где ваши письма теряются, в рамках аудита сайта.