Почему письма с сайта попадают в спам и как улучшить доставляемость
Когда письма с сайта попадают в спам, покупатель может не увидеть подтверждение заказа, сотрудник — уведомление о заявке, а подписчик — ожидаемую рассылку. При этом в панели отправки всё выглядит успешно. Чтобы исправить ситуацию, нужно проверить не только настройки домена, но и сам маршрут письма, репутацию отправителя, ожидания получателей и работу с отказами.
Начните с конкретного сообщения: найдите его у почтового провайдера и получателя, сохраните исходник и определите масштаб проблемы. Затем исправляйте подтверждённые причины. Ни одна DNS-запись, оценка тестового сервиса или смена SMTP не даёт гарантии попадания во входящие. Ниже — порядок проверки, который помогает принять обоснованные решения и оценить результат.
Отправлено, доставлено и прочитано — разные результаты
Уведомление может пройти несколько независимых этапов: сайт передал его сервису отправки, сервис поставил сообщение в свою очередь, сервер получателя принял его, почтовая система выбрала папку, а человек открыл письмо. Успех одного этапа не подтверждает следующие. Название статуса в интерфейсе нужно сверять с документацией конкретного продукта.
Например, Amazon SES определяет Delivery как доставку серверу получателя. Этот статус не сообщает, в какую папку попало сообщение. У другого сервиса похожая надпись может иметь иной смысл. Сопоставляйте статус с техническим событием и идентификатором письма.
Если сообщение вообще не было создано или передано почтовому сервису, сначала проверяют форму и приложение. Здесь рассматривается следующий участок: письмо отправлено, но отклоняется, задерживается или оказывается в нежелательной почте. Также отличайте папку «Спам» от категорий вроде «Промоакции»: расположение в категории входящих само по себе не означает блокировку.
Как проверить, почему письма попадают в спам
Соберите несколько сопоставимых примеров
Возьмите сообщения одного типа за проблемный период: например, подтверждения заказа на Gmail и на Яндекс. Зафиксируйте время с часовым поясом, отправителя, получателя, шаблон, домен подписи, сервис отправки и идентификатор сообщения. Для первичной проверки используйте собственные тестовые адреса, а рабочие примеры передавайте специалисту с учётом конфиденциальности переписки.
Уточните, что изменилось перед ухудшением: новый сервис, адрес From, шаблон, источник подписчиков, объём рассылки или правила домена. Сравнивайте одинаковые типы писем. Уведомление о заказе и рекламная кампания отличаются и содержанием, и ожиданиями аудитории; общий средний показатель может скрывать проблему только одного потока.
| Наблюдение | Что проверить первым | Какие данные нужны |
|---|---|---|
| Письма в спаме у разных сервисов | Аутентификацию, источник базы, репутацию, изменения отправки | Исходники писем, отчёты провайдера, история изменений |
| Проблема только у одного почтового провайдера | Его требования и статистику, ответы принимающих серверов | Примеры доставки именно на этот сервис |
| Проблема у одного сотрудника | Личные фильтры, блокировки, корпоративный карантин, пересылку | Правила ящика и исходник найденного письма |
| Сбой начался после смены транспорта | Фактический IP, DKIM, домен возвратов и согласование с From | Сравнение заголовков до и после изменения |
| Реклама фильтруется, сервисные письма доходят | Подписку, частоту, отписку, содержание рекламного потока | Отдельные показатели кампаний и жалоб |
| Есть возврат или длительная задержка | Точный ответ сервера и статус попыток | Полный технический отчёт, а не только слово «ошибка» |
Изучите исходник сообщения
В Gmail это команда «Показать оригинал»; порядок просмотра описан в справке о заголовках письма. В других клиентах ищите исходный текст или служебные заголовки. Нужны From, Return-Path, DKIM-Signature, Authentication-Results, Received и Message-ID. Пересланная обычным способом копия может не сохранить исходный маршрут, поэтому лучше анализировать оригинал у проблемного получателя.
Результаты проверок следует читать в контексте принимающего сервиса. Произвольная строка Authentication-Results внутри сообщения не заслуживает автоматического доверия: значение имеет, кто её добавил. Границы доверия описаны в RFC 8601. При сложном маршруте попросите почтового администратора сопоставить заголовки с журналом доставки.
Проверьте аутентификацию и узнаваемость отправителя
SPF, DKIM и DMARC решают задачи проверки отправителя. Для диагностики важен результат на реальном письме, прошедшем через ваш сайт и сервис отправки. Наличие записей в DNS не подтверждает, что выбранный транспорт использует их правильно.
- SPF: проверьте домен технического отправителя, используемый при SMTP-передаче, и разрешён ли фактический сервер отправки.
- DKIM: убедитесь, что письмо подписано ожидаемым доменом и подпись проходит проверку после доставки.
- DMARC: проверьте согласование домена видимого From с успешно проверенным SPF или DKIM. Для прохождения достаточно одного подходящего механизма с нужным выравниванием.
Так, SPF и DKIM сторонней платформы могут проходить проверку, но не подтверждать домен компании в From. Разбирайте фактические домены, а не только зелёные отметки. При этом Google отдельно предупреждает: получатель может фильтровать сообщение даже при успешном DMARC. Аутентификация необходима для доверия, но не заменяет качество рассылки.
Для уведомления менеджеру используйте разрешённый адрес компании в From, а проверенный адрес посетителя — в Reply-To. Для письма покупателю укажите понятного отправителя и рабочий канал ответа. Смена имени или адреса при каждом письме затрудняет узнавание компании и диагностику. Подробные DNS-значения берите из настроек используемого сервиса, учитывая всех законных отправителей домена.
Учтите пересылки
Если проблема появляется только после пересылки, сравните прямой и пересланный маршрут. Посредник может изменить содержимое или способ передачи, что влияет на проверки. ARC передаёт сведения о проверках на предыдущих этапах, но решение принимающая сторона выносит с учётом доверия к участникам цепочки. Наличие ARC не гарантирует попадание во входящие.
Что требуют Gmail, Яндекс, Mail и Yahoo
Правила относятся к конкретному принимающему сервису и категории отправителя. Не переносите порог объёма или перечень обязательных функций одного провайдера на всех остальных. Перед запуском или существенным увеличением рассылки сверяйте действующую документацию.
| Получатель | На что обратить внимание | Официальный источник |
|---|---|---|
| Личные Gmail | SPF или DKIM для всех отправителей; для массовых — SPF, DKIM, DMARC и дополнительные условия | Gmail: требования к отправителям |
| Yahoo | Базовая аутентификация и DNS; отдельные требования к массовым отправителям, жалобам и отписке | Yahoo Sender Best Practices |
| Яндекс | Подтверждённая подписка, понятная отписка, корректная идентификация, DKIM и SPF для рассылок | Требования к честным рассылкам |
| Аутентификация, корректный сервер и формат, ожидаемые письма, обработка несуществующих адресов | Технические и административные требования |
В FAQ Gmail массовым считается отправитель примерно от 5000 сообщений на личные Gmail за 24 часа. Объём суммируется по основному домену, включая поддомены; присвоенный статус сохраняется. Разделение рассылки между поддоменами не отменяет эти условия. Для Yahoo определение категории и требования смотрите отдельно.
Проверьте прямую и обратную DNS-идентификацию исходящего сервера, TLS и формат письма. При работе через почтовую платформу часть параметров обслуживает она. Настройка PTR для IP веб-хостинга бесполезна, если письма фактически уходят с другого сервера. Уточните у подрядчика, за какой участок отвечает сайт, а за какой — провайдер отправки.
Как связаны отписка и попадание писем в спам
Когда человек больше не хочет рассылку, доступная отписка помогает завершить её без жалобы. Ссылка должна быть заметной, действующей и соответствовать списку, из которого пришло письмо. Проверяйте весь процесс: нажатие, изменение статуса подписчика, исключение из следующих отправок и синхронизацию между сервисами.
Для применимых маркетинговых сообщений различайте ссылку в тексте и механизм one-click. RFC 8058 описывает заголовки List-Unsubscribe и List-Unsubscribe-Post, HTTPS POST для отписки и подпись DKIM, охватывающую эти заголовки. Обычная страница настроек подписки не заменяет этот механизм. Реализуйте его средствами провайдера и проверьте обработку без входа в аккаунт получателя.
Gmail и Yahoo отделяют маркетинговые сообщения от транзакционных: подтверждение заказа или восстановление пароля не получает такое требование автоматически. Это прямо отражено в FAQ Yahoo и FAQ Gmail. Yahoo требует исполнять отписку в течение двух дней; у других сервисов свои условия. Практически полезно исключать адрес сразу после подтверждённого запроса, учитывая уже поставленные в очередь кампании.
Не маскируйте рекламное предложение под обязательное уведомление. Если в подтверждение заказа добавлена большая рекламная подборка, получатель может воспринимать его как продвижение. Решение о составе письма принимайте по его основной задаче и ожиданиям адресата.
Проверьте базу, жалобы и возвраты
Установите, почему человек получает письмо
Для каждого рекламного сегмента должны быть понятны источник адресов, дата подписки, выбранная тематика и ожидаемая частота. Покупка товара сама по себе не описывает согласие на любую будущую рассылку. Не используйте купленные или собранные с сайтов списки: наличие адреса не означает интерес к вашим предложениям.
Яндекс требует явного согласия и подтверждения адреса для честных рассылок; правила Mail также предусматривают ожидаемую подписку. Это требования сервисов, а применимые правовые основания определяются отдельно. Подтверждение адреса помогает отсечь ошибки и чужие подписки, но не освобождает от контроля дальнейшего качества базы.
Проверьте старые сегменты, импорт из CRM и объединение списков. Пользователь мог отписаться в одном сервисе, а затем снова попасть в кампанию после синхронизации. Нужен единый источник статуса подписки и правило, которое не позволяет очередному импорту отменить осознанный отказ человека.
Настройте список исключений
Отдельно учитывайте отписки, жалобы и подтверждённые постоянные ошибки адреса. Почтовые платформы называют такие ограничения suppression list. Например, Amazon SES поддерживает причины BOUNCE и COMPLAINT. Состав и область действия списка зависят от настроек продукта; наличие функции ещё не подтверждает, что она включена для вашего потока.
После сообщения о несуществующем ящике прекратите автоматические попытки на этот адрес и уточните контакт в допустимом рабочем процессе. При временной ошибке используйте предусмотренные провайдером отложенные повторы. Не считайте любой постоянный отказ доказательством несуществующего адреса: блокировка по политике требует другого исправления.
Жалобу на рекламную рассылку обработайте как сигнал прекратить нежелательные отправки. Не удаляйте адрес из списка исключений ради улучшения цифры кампании. Если ограничение затронуло важное сервисное уведомление, выясните причину, подтвердите актуальный контакт и согласуйте другой канал связи; простая принудительная отправка не решает проблему.
Как влияют репутация домена, IP и объём отправки
У почтового сервиса складывается история взаимодействия с отправителем: успешная аутентификация, жалобы, ошибки адресов, характер отправки. Репутация связана с несколькими признаками, поэтому смена IP или поддомена не гарантирует нового доверия. Сначала устраните причину нежелательной почты и только затем оценивайте изменения инфраструктуры.
Исключите незапланированную отправку
Если объём вырос без согласованной кампании, проверьте журналы отправки и доступ к платформе. Причиной может оказаться ошибочный автоматический сценарий, повторная обработка очереди или использование чужим человеком действующих реквизитов. Сопоставьте время, учётную запись, источник запросов и шаблон. Подозрение на взлом требует подтверждения по событиям, а не только по падению доставляемости.
При подтверждённом нарушении остановите соответствующий источник, отзовите скомпрометированный доступ и устраните причину, затем оцените уже выполненные отправки. Рекомендации Яндекс 360 по безопасности включают управление правами, двухфакторную аутентификацию и мониторинг. Возвращать обычную нагрузку имеет смысл после проверки, что незапланированные сообщения больше не появляются.
Общий и выделенный IP
На общем IP отправляют разные клиенты провайдера; его качество зависит и от управления общим потоком. Выделенный IP даёт больше самостоятельности, но требует подходящего объёма и обслуживания. В сравнении вариантов Amazon SES выбор прямо связан с объёмом и регулярностью писем, а общий пул подходит в том числе для небольших отправителей.
Поэтому сайту с несколькими десятками ожидаемых уведомлений не стоит автоматически покупать выделенный IP. Запросите у текущего сервиса сведения о проблемном маршруте, принятых мерах и доступных вариантах. Оцените, кто будет следить за репутацией и устранять сбои после перехода.
Рост нагрузки и разделение потоков
Увеличивайте объём на основе реального спроса и наблюдаемых результатов. Google относит резкое увеличение отправки к типовым причинам проблем. Универсального графика «прогрева за семь дней» нет: важны история, аудитория, ограничения провайдера и реакция принимающих систем. Искусственные открытия и переписка ради имитации активности не заменяют ожидаемых писем.
Разделите маркетинговые кампании и критичные уведомления хотя бы в отчётах, очередях, настройках лимитов и ответственности команды. При необходимости используйте отдельные потоки или домены подписи по схеме провайдера. Это помогает управлять нагрузкой и локализовать сбои, но полной независимости репутации всех связанных доменов обещать нельзя.
Что проверить в содержании и оформлении письма
Получатель должен быстро понять, кто пишет, почему и что нужно сделать. Используйте узнаваемое имя компании, точную тему и содержание, соответствующее событию. Подтверждение заказа должно показывать нужные сведения о заказе; сообщение о заявке — помогать менеджеру обработать обращение.
- Проверьте видимую тему, адрес отправителя и адрес ответа на реальном письме.
- Откройте все ссылки и убедитесь, что они ведут на ожидаемый сайт без ошибочных переходов.
- Проверьте отображение на телефоне, читаемость текста и работу при отключённых изображениях.
- Убедитесь, что подстановки не оставили пустое обращение, чужие данные или служебный код.
- Проверьте вложения и удалите элементы, которые не нужны для задачи сообщения.
Правила Mail отдельно обращают внимание на опасные HTML-объекты и попытки скрывать целевую страницу ссылок. Проверяйте шаблон и домены переходов, включая подключённый трекинг. Если проблема появилась после изменения шаблона, сравните версии на одинаковом типе получателей, не смешивая проверку с новой базой и ростом объёма.
Список «запрещённых слов» или заданный процент картинок не объясняет решение всех почтовых фильтров. Оценка mail-tester и подобных проверок полезна для поиска отдельных дефектов, но не измеряет фактическое расположение всех писем у клиентов. Исправляйте конкретные замечания и подтверждайте результат на используемом маршруте.
Как измерять доставляемость без ложных выводов
В рабочем отчёте разделяйте отправленные сообщения, принятие сервером адресата, временные задержки, окончательные отказы, жалобы и отписки. Указывайте период, тип письма, принимающий сервис и знаменатель каждого процента. Одинаковое название показателя у двух платформ не означает одинаковый расчёт.
В Postmaster Tools Gmail показатель Spam rate связан с письмами, доставленными во входящие активным получателям и затем отмеченными ими как спам; учитываются особенности выборки сервиса. Автоматически отправленная в спам почта не отражается в нём как обычная пользовательская жалоба. Поэтому низкий процент может соседствовать с плохим попаданием во входящие.
В своём FAQ Google рекомендует удерживать пользовательские жалобы ниже 0,1% и не допускать уровня 0,3% и выше. Оценивайте этот ориентир по метрике Gmail, а не по общему числу всех писем в вашей CRM. Порог Yahoo и расчёт его показателей проверяйте отдельно; у Mail также собственные правила оценки репутации.
Google предупреждает о пропусках статистики при малом объёме. Не увеличивайте рассылку только ради появления графика. Для небольшого сайта полезнее сопоставлять журнал уведомлений, ошибки и контрольные письма. Postmaster Mail предоставляет собственные данные о доставке, спаме, блокировках и обратной связи.
Открытия тоже имеют ограничения. Например, Mail Privacy Protection Apple мешает отправителю определять факт открытия. Поэтому не объявляйте всю аудиторию неактивной по одному пикселю. Сопоставляйте доступные сигналы с задачей: ответ клиента, подтверждение действия, обращение в поддержку или завершённый заказ. Даже клик сам по себе ещё не равен бизнес-результату.
План исправления: от причины к проверяемому результату
Назначьте одного ответственного за разбор и зафиксируйте исходное состояние. Изменения должны отвечать конкретной гипотезе: например, исправить подпись одного транспорта или исключить сегмент без подтверждённой подписки. Если одновременно поменять домен, сервис, шаблон и базу, оценить вклад каждого действия будет трудно.
| Приоритет | Действие | Подтверждение результата |
|---|---|---|
| Остановить ухудшение | Приостановить проблемную рекламную кампанию, обработать отписки и жалобы | Исключённые адреса не попадают в новые задания |
| Исправить идентификацию | Проверить все используемые транспорты и законных отправителей | Ожидаемые результаты аутентификации на доставленных образцах |
| Устранить дефекты | Исправить ошибочные шаблоны, ссылки, адреса и обработку возвратов | Повторяется тот же рабочий сценарий с корректным результатом |
| Вернуть контролируемую отправку | Отправлять ожидаемые сообщения подходящему сегменту в пределах лимитов | Наблюдаются задержки, отказы и обратная связь по каждому сервису |
| Закрепить контроль | Настроить отчётность, уведомления о сбоях и ответственность | Команда видит проблему и знает порядок реакции |
При обращении в поддержку приложите обезличенный исходник, время, идентификатор, получателя на проблемном сервисе и точный результат доставки. Mail рекомендует сначала получить журнал отправки у рассылочного провайдера. Не отправляйте пароли, токены и полную клиентскую базу в обычном описании проблемы.
Для критичных уведомлений отдельно согласуйте допустимую задержку и действия команды при её превышении. Например, менеджеру нужен список заказов без подтверждённого уведомления, а поддержке — способ проверить конкретный запрос восстановления доступа. Это позволяет обслужить клиента, пока разбирается почтовая проблема. Численные цели выбирают по процессу компании и возможностям используемых сервисов, а не заимствуют из чужого кейса.
Приёмка включает разные шаблоны, реальные маршруты и наблюдение за рабочим потоком. Зафиксируйте, что исправлено, какие исключения остаются и кто их разбирает. Один успешный тест показывает работоспособность конкретного сценария; стабильность оценивается по дальнейшим данным. Срок восстановления репутации заранее гарантировать нельзя.
Учебный пример: реклама повлияла на важные уведомления
Предположим, магазин использует учебный домен example.com. Подтверждения заказов и рекламные письма отправляются через одну платформу. После импорта старой базы часть клиентов жалуется на отсутствие уведомлений. В контрольных письмах аутентификация проходит, а в отчётах обнаружены жалобы и возвраты у новой кампании.
Рабочая гипотеза — проблема связана с качеством этого сегмента и общей отправкой. Команда приостанавливает кампанию, сверяет подписку, исключения и историю импорта, проверяет критичные уведомления отдельно. Она не объявляет DNS причиной только потому, что письма попали в спам, и не переносит всю базу на новый домен.
После исправления процесса подписки и обработки отказов команда наблюдает за ожидаемыми письмами по сервисам получателей. Если фильтрация сохраняется, передаёт провайдеру конкретные примеры. Это условный сценарий диагностики, а не обещание, что такие действия всегда восстановят доставку за определённое время.
Частые вопросы
Почему письма попадают в спам, хотя SPF, DKIM и DMARC проходят?
Проверки подтверждают технические свойства отправителя. Получатель также оценивает репутацию, содержание, ожидаемость писем и собственные правила. Исследуйте жалобы, базу, маршрут и изменения отправки.
Поможет ли попросить клиента нажать «Не спам»?
Для конкретного ожидаемого письма человек может исправить классификацию в своём ящике. Это не заменяет устранение общей причины. Не организуйте искусственные действия сотрудников ради имитации интереса к рассылке.
Нужно ли менять SMTP, если письма с сайта в спаме?
Сначала установите причину и ответственность провайдера. Смена транспорта может потребовать новой аутентификации и проверки репутации. Некачественная база, сломанная отписка или нежелательное содержание сохранят проблему и после переезда.
Как не попадать в спам при небольшом количестве заявок?
Используйте ожидаемые уведомления, согласованный адрес отправителя, корректную аутентификацию и подходящий почтовый сервис. Контролируйте реальные письма и ошибки. Малый объём не отменяет технических требований и не гарантирует входящие.
Почему один почтовый сервис принимает письма, а другой фильтрует?
У сервисов различаются правила, история взаимодействия и доступные сигналы. Сравните исходники и показатели именно проблемного направления. Успех в одном тестовом ящике нельзя распространять на всех получателей.
Нужна ли отписка в письме восстановления пароля?
Такое письмо относится к сервисным сообщениям по действию пользователя. Требования Gmail и Yahoo к one-click для маркетинга не переносятся на него автоматически. Сохраните фокус письма на восстановлении доступа.
Для разбора доставляемости подготовьте перечень типов писем, используемый сервис отправки и несколько обезличенных примеров. Это поможет согласовать проверку, определить ответственных и принять результат по понятным показателям.
Ссылки из писем должны вести на доступные страницы, а формы на них — принимать обращения. Оцените SiteGuard для регулярного мониторинга сайта и форм.