Сервис рассылка спам: чеклист проверки фильтров и репутации домена

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

Для команды CRM запрос «сервис рассылка спам» обычно означает поиск конкретной причины: что проверить в платформе рассылок и DNS, чтобы письма проходили фильтры. Ниже — рабочий чеклист, который помогает найти сбой до следующего крупного запуска. Он не обещает попадание во «Входящие» по одной настройке, зато помогает убрать ошибки, которые ухудшают репутацию и съедают конверсию.

1. Проверьте аутентификацию домена: SPF, DKIM и DMARC

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

Для отправки на личные адреса Gmail действует отдельный порог: если отправитель направляет туда от 5 000 сообщений в день, он относится к массовым. Для таких отправителей Google требует SPF и DKIM, опубликованную политику DMARC как минимум с p=none, а также отписку в один клик. Порог считается по объёму сообщений на адреса Gmail, а не по всей базе в вашей CRM.

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

Перед запуском проверьте конфигурацию по шагам:

1. Найдите в панели сервиса рассылок значения SPF и DKIM, которые он просит добавить. Если письма отправляются через несколько платформ, проверьте, что SPF-запись не перезаписана последним подключённым сервисом. У домена должна быть одна корректно собранная SPF-запись, включающая все используемые источники отправки.

2. Убедитесь, что DKIM включён именно для рабочего домена или поддомена рассылки. Сам факт наличия ключа в панели не гарантирует, что подпись ставится на письма: отправьте тест и проверьте заголовки сообщения.

3. Опубликуйте DMARC-запись и сверьте домен в ней с доменом отправителя. Если маркетинговая платформа использует отдельный поддомен, учитывайте это при настройке и проверке выравнивания доменов.

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

Частая ошибка — считать, что зелёный статус в интерфейсе ESP означает полную готовность. Платформа может подтвердить, что DNS-запись найдена, но не показать, как письмо оценивается конкретным провайдером. Сверяйте настройку в сервисе, записи DNS и заголовки реального тестового сообщения.

Для массовой отправки SPF, DKIM и DMARC работают как единый контур. Отсутствие одного из элементов оставляет провайдеру сигнал риска, который не компенсируется красивым шаблоном или высоким прошлым опенрейтом.

Аутентификация снижает риск подмены отправителя и помогает фильтрам связать письмо с вашим доменом. Но она не даёт гарантии попадания во «Входящие»: провайдеры также учитывают жалобы, качество базы, поведение получателей и репутацию IP-адреса.

2. Смотрите на жалобы раньше, чем на падение конверсии

Жалоба на спам — прямой сигнал, что часть аудитории не хочет получать письма или не узнаёт отправителя. В Google Postmaster Tools spam rate необходимо удерживать ниже 0,3%; рекомендуемый рабочий уровень — менее 0,1%. Приближение к верхней границе лучше считать ранним предупреждением, а не поводом дождаться блокировки или троттлинга.

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

Когда spam rate растёт, не меняйте одновременно тему, креатив, сегментацию и расписание отправки. Так вы потеряете возможность понять, какая гипотеза сработала. Разберите последний прирост по источникам подписки, давности контакта, активности когорты и типу кампании. Часто проблемный участок базы появляется после импорта старых адресов, сбоя в форме подписки или отправки неактивным контактам.

Практический порядок действий при росте жалоб:

• Сопоставьте изменение показателя с конкретной кампанией и её аудиторией. Общий средний уровень по месяцу может скрывать проблемный сегмент.
• Проверьте, совпадает ли ожидание подписчика с содержанием рассылки и её частотой. Если человек оставил адрес ради уведомлений о заказе, регулярные промописьма могут вызвать жалобу.
• Приостановите отправку на когорту, которая даёт непропорционально много негатива, и разберите источник контактов и условия получения согласия.
• Проверьте видимость ссылки отписки и корректность её работы на мобильных устройствах и в разных почтовых клиентах.
• После изменений отслеживайте следующий запуск отдельно. Сравнивайте сопоставимые сегменты и объёмы, а не кампании с принципиально разной аудиторией.

Google Postmaster Tools показывает данные по письмам, направляемым на личные адреса Gmail и Googlemail. Это не универсальная панель репутации для всех почтовых провайдеров. Кроме того, графики формируются только при достаточном ежедневном объёме трафика; точный минимальный порог Google не указывает. Если панели пусты, это само по себе не доказывает ни хорошую, ни плохую репутацию.

Нельзя механически переносить показатель Gmail на Яндекс, Mail.ru или корпоративные домены. Для разных получателей доступны разные инструменты и сигналы. Собирайте собственную аналитику по доменам назначения: доставленные сообщения, отказы, жалобы, отписки, клики и динамика активности. Отдельный сервис «Постмастер» Яндекса закрыт с 2020 года, поэтому строить мониторинг на его текущей доступности нельзя.

3. Убедитесь, что отписка работает в один клик

Отписка — часть инфраструктуры доставляемости. Если получателю проще пожаловаться на спам, чем прекратить рассылку, негативные сигналы будут расти. Для массовых отправителей на Gmail требуется поддержка One-Click Unsubscribe с заголовком List-Unsubscribe. Механизм описан в стандарте RFC 8058; запросы на отписку должны обрабатываться не дольше двух дней.

Проверьте не только ссылку внизу письма. Убедитесь, что сервис добавляет необходимые заголовки и что отписка действительно выполняется без лишних экранов и повторного подтверждения. В некоторых почтовых клиентах кнопка отказа от рассылки отображается в интерфейсе рядом с данными отправителя. Если заголовок отсутствует или сформирован неверно, пользователь может не увидеть эту возможность.

Перед запуском кампании проверьте:

• в заголовках тестового письма есть корректный List-Unsubscribe;
• ссылка ведёт на нужную рассылку или группу сообщений, а не на ошибочную страницу;
• запрос на отписку изменяет статус контакта в ESP и передаётся в CRM, если между системами настроена интеграция;
• отписавшийся адрес исключается из последующих маркетинговых кампаний;
• обработка запроса укладывается в установленный срок.

Здесь часто проявляется проблема интеграции, а не самого почтового сервиса. Например, ESP принимает отписку, но синхронизация с CRM запускается по расписанию или ломается из-за неверного маппинга статусов. В результате контакт продолжает попадать в сегменты и получает новые письма. Для контроля заведите тестовый адрес, пройдите сценарий отписки и проследите изменение статуса во всех связанных системах.

4. Проверьте DNS и сетевую инфраструктуру отправки

Ошибки в DNS могут влиять на то, как принимающий сервер идентифицирует источник письма. В фактической конфигурации важны не только записи SPF, DKIM и DMARC, но также корректные PTR-записи и шифрование соединения по TLS.

PTR-запись связывает IP-адрес с именем хоста при обратном DNS-поиске. Если отправка идёт через инфраструктуру ESP, настройка может быть на стороне платформы, а не в вашем домене. Уточните у сервиса, какой IP используется для отправки и кто отвечает за обратное сопоставление. Если у компании собственный почтовый сервер, ответственность за конфигурацию лежит на администраторе этой инфраструктуры.

TLS защищает соединение между почтовыми серверами. Проверьте, что ваша система отправляет почту с шифрованием и что это подтверждается настройками или логами платформы. Само наличие TLS не повышает конверсию напрямую, но некорректная или устаревшая конфигурация может стать техническим препятствием при доставке.

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

Для каждого канала зафиксируйте в технической документации:

• домен и поддомен отправителя;
• сервис или сервер, который отправляет сообщения;
• IP-адреса и ответственного за PTR;
• SPF, DKIM и DMARC для используемого домена;
• способ проверки TLS;
• владельца интеграции и порядок эскалации сбоя.

Такой список особенно полезен после смены ESP или подключения нового API. Смена платформы часто добавляет новый источник отправки, а команда забывает обновить SPF или настроить DKIM для нового домена. В итоге ошибка проявляется уже на массовой кампании, когда цена промедления выше.

5. Используйте сервисы валидации и интеграции как часть процесса

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

Оптимальный процесс начинается до передачи контакта в ESP. Форма подписки должна собирать корректный адрес, а интеграция — передавать в систему источник, дату и статус согласия. Если адреса поступают из нескольких каналов, храните эту информацию на уровне контакта: тогда сегментация опирается на происхождение базы, а не только на дату импорта.

В рабочем сценарии автоматизации полезны такие проверки:

1. При добавлении адреса система проверяет формат и обязательные поля.

2. Контакт получает метку источника и дату подписки.

3. Адрес проходит выбранную проверку валидности, если это предусмотрено процессом.

4. Сегмент для отправки исключает отписавшихся, недоставляемые адреса и контакты без нужного статуса.

5. После кампании результаты передаются обратно в CRM или аналитическое хранилище для разбора по когортам.

Настройте правила исключения один раз и тестируйте их на контрольном наборе адресов после изменений API. Ошибка в маппинге может оказаться дороже самой проверки: например, сервис возвращает статус, но интеграция не записывает его в поле, по которому строится сегмент. В отчёте всё выглядит корректно, а рассылка продолжает включать неподходящие контакты.

Инструменты прогрева домена тоже требуют аккуратной оценки. Они не заменяют аутентификацию, согласие получателей и контролируемый объём отправки. Если домен новый или канал недавно переехал, планируйте рост нагрузки постепенно и отслеживайте жалобы, отказы и вовлечённость. Не ориентируйтесь на обещание автоматического прогрева без понимания, какие адреса участвуют в процессе и как формируется отправка.

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

6. Соберите мониторинг в один рабочий дашборд

Чтобы защита от спама в рассылках не сводилась к разбору инцидентов постфактум, объедините технические и маркетинговые сигналы. В одном отчёте полезно видеть объём отправки, доставку, отказы, жалобы, отписки, опенрейт, кликрейт и конверсию. Если показатели живут в разных системах, настройте выгрузку через API или регулярную синхронизацию в BI.

Смотрите на данные разрезами, которые помогают найти причину:

Интерпретируйте метрики вместе. Например, рост отказов в одном домене получателя может указывать на техническую проблему маршрута, тогда как всплеск отписок после кампании — на несоответствие частоты или содержания ожиданиям сегмента. Просадка кликов при стабильной доставке требует отдельной гипотезы по предложению и аудитории; DNS-записями её не исправить.

Отдельно учитывайте ограничения мониторинга. Google Postmaster Tools охватывает только личные адреса Gmail и формирует панели при достаточном объёме отправки. Пустой график не даёт оснований делать вывод о репутации. Для остальных провайдеров используйте доступные отчёты ESP, данные о возвратах, внутреннюю аналитику и наблюдение за изменениями в результатах кампаний.

Что пройти перед запуском крупной кампании

Перед отправкой на большую аудиторию пройдите короткий технический и маркетинговый контроль:

• SPF, DKIM и DMARC опубликованы для фактического домена отправки; тестовое письмо проходит проверку.
• Для массовой отправки на Gmail настроена политика DMARC не слабее p=none, а SPF и DKIM работают одновременно.
• Проверены PTR и TLS для используемого маршрута отправки; ответственность за них закреплена за вашей командой или ESP.
• Жалобы в Google Postmaster Tools остаются ниже 0,3%, рабочая цель — ниже 0,1%; оценка учитывает, что данных может быть недостаточно.
• В письме присутствует работающая отписка в один клик, запрос обрабатывается в срок до двух дней.
• Сегмент исключает отписавшихся и недоставляемые адреса; источники и статусы контактов передаются между CRM и ESP без потерь.
• После смены сервиса, домена или API-интеграции проверены DNS, заголовки тестового письма и синхронизация статусов.

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

Хороший мониторинг связывает репутацию домена с конкретной кампанией и когортой. Тогда проблема становится проверяемой гипотезой, а не поводом вслепую менять тему письма или сервис рассылок.

Если показатели ухудшились, зафиксируйте дату, домен получателя, кампанию и затронутый сегмент. Сверьте жалобы и отказы с изменениями DNS, объёмом отправки и работой отписки. Такой порядок помогает сохранить профит от канала: команда быстрее находит источник сбоя и не тратит охват на повторение той же ошибки.