Сервис рассылок шлет в спам: как исправить настройки

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

Я часто вижу одну и ту же ситуацию у небольших команд: маркетолог подключил новый сервис рассылок, вставил список клиентов, отправил первое письмо на несколько тысяч адресов — и получил проблемы с доставкой. Здесь важно не паниковать и не пытаться «перещёлкать» все настройки подряд. Доставляемость — это не один волшебный тумблер, а рутина из нескольких слоёв: техническая аутентификация домена, аккуратный прогрев, чистая база и наблюдение за реакцией получателей.

Технический фундамент: SPF, DKIM и DMARC как стандарт доверия

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

Если упрощать, SPF, DKIM и DMARC отвечают на три последовательных вопроса:

SPF, или Sender Policy Framework, — это DNS-запись, в которой владелец домена указывает, какие почтовые сервисы и IP-адреса могут отправлять письма от его имени. Например, если вы используете отдельный сервис рассылок, корпоративную почту Google Workspace и ещё CRM с автоматическими уведомлениями, все легитимные отправители должны быть отражены в SPF. Иначе один инструмент может быть настроен правильно, а другой — выглядеть для почтового провайдера как самозванец.

Здесь есть спокойная, но частая ошибка: команда добавляет новую SPF-запись, не заметив, что старая уже существует. В DNS для домена не должно быть нескольких отдельных SPF-записей. Их нужно объединять в одну, иначе проверка может работать некорректно. Это не тот случай, где «чем больше, тем надёжнее».

DKIM работает иначе. Он добавляет к письму цифровую подпись. Почтовый провайдер получает сообщение, сверяет подпись с публичным ключом в DNS и понимает: письмо действительно связано с доменом, а его содержимое не изменили по дороге. В интерфейсах сервисов рассылок DKIM обычно выглядит как набор CNAME- или TXT-записей, которые нужно добавить у регистратора домена или в DNS-хостинге.

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

Я обычно советую не начинать сразу с p=reject, если у домена сложная история: рассылки, CRM, сайт, платёжные уведомления, старые интеграции. Сначала полезно включить мониторинг, посмотреть, кто вообще отправляет письма от имени домена, и только потом ужесточать политику. Это снижает риск случайно перекрыть важный поток писем — например, транзакционные уведомления с сайта.

SPF, DKIM и DMARC не гарантируют место во «Входящих», но без них домен выходит к почтовым провайдерам без документов.

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

Когда рассылка уходит в спам, хочется найти одну очевидную причину: «плохая тема», «слишком много ссылок», «сервис не подходит». Иногда это правда влияет, но чаще провайдер смотрит шире. Для Gmail, Outlook, Mail.ru, Яндекса и других систем письмо — часть поведения отправителя во времени.

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

На практике проблемы с доставкой писем часто складываются из нескольких мелочей:

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

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

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

Настройка сервиса рассылок: спокойный порядок действий

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

Удобная последовательность выглядит так:

1. Выберите отправочный домен или поддомен.

Для маркетинговых рассылок часто используют отдельный поддомен: например, news.example.com или mail.example.com. Это помогает отделить репутацию массовых кампаний от основной корпоративной переписки. Не всегда это обязательно, но для регулярных рассылок такой подход даёт больше пространства для управления.

2. Добавьте DNS-записи, которые предлагает сервис.

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

3. Проверьте, нет ли конфликта SPF.

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

4. Включите DKIM-подпись и дождитесь подтверждения.

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

5. Настройте DMARC сначала в режиме наблюдения.

Политика p=none позволяет увидеть, какие источники отправляют письма от имени домена. Когда картина понятна, можно переходить к p=quarantine, а затем, если инфраструктура чистая, к p=reject.

6. Отправьте тесты на разные почтовые ящики.

Не ограничивайтесь одним корпоративным адресом. Проверьте Gmail, Outlook, Mail.ru, Яндекс, если они важны для вашей аудитории. Смотрите не только папку, но и заголовки письма: проходят ли SPF, DKIM и DMARC.

7. Разделите транзакционные и маркетинговые потоки.

Уведомление о заказе и промо-письмо к распродаже — разные по смыслу сообщения. Если есть возможность, отправляйте их через разные потоки, шаблоны или даже поддомены. Так проще диагностировать проблемы и не смешивать репутационные риски.

Интеграция почтового сервиса с CRM, сайтом или no-code-инструментами добавляет ещё один слой внимания. Автоматизация удобна, но она легко создаёт невидимые потоки писем: приветственные цепочки, напоминания, счета, вебинарные уведомления. Раз в несколько месяцев полезно спокойно пройтись по всем интеграциям и понять, какие письма действительно уходят от имени домена.

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

Прогрев домена: почему нельзя сразу отправлять на всю базу

Прогрев домена — один из тех процессов, который кажется лишним, пока не столкнёшься с блокировками. Его смысл простой: новый или давно неактивный домен должен постепенно показать почтовым провайдерам, что он отправляет ожидаемые письма живым людям, а не внезапный поток неизвестного происхождения.

Минимальный разумный период прогрева нового домена — от 2 до 4 недель. Это не магическая цифра, а ориентир, который помогает не торопить репутацию. Если база большая, прогрев может занять больше времени. Главное — увеличивать объём постепенно и смотреть на реакции.

Пример мягкой схемы для нового отправочного домена:

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

Прогрев — это не разгон ради скорости, а спокойное знакомство домена с почтовыми провайдерами.

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

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

Гигиена базы: как удержать bounce rate ниже 2%

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

Ориентир, к которому стоит стремиться, — bounce rate ниже 2%. Показатель отказов выше 2–5% уже становится критическим сигналом для почтовых провайдеров: база выглядит некачественной, а отправитель — невнимательным. Здесь я бы не стал ждать, пока сервис рассылок сам начнёт ограничивать отправку. Лучше встроить гигиену базы в обычную рутину.

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

Что помогает держать базу в рабочем состоянии:

• Двойное подтверждение подписки там, где это уместно.

Double opt-in уменьшает количество случайных и ошибочных адресов. Да, часть людей не подтвердит подписку, зато оставшиеся контакты будут чище.

• Валидация email перед крупными отправками.

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

• Автоматическое исключение hard bounce.

Адреса с жёсткими отказами не должны снова попадать в кампании. Если система почему-то не удаляет их сама, настройте правило вручную.

• Отдельная работа с неактивными подписчиками.

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

• Простая и заметная отписка.

Это может звучать неприятно для маркетинга, но удобная отписка часто лучше жалобы на спам. Человек, который спокойно ушёл, меньше вредит репутации домена, чем человек, который раздражённо нажал «Спам».

Покупные базы я не рассматриваю как рабочий инструмент для нормальной доставляемости. Это быстрый путь к отказам, жалобам и блокировкам. Даже если на бумаге база выглядит «целевой», почтовые провайдеры оценивают не описание файла, а поведение реальных получателей. Если люди не ждали письма, они будут реагировать соответственно.

Мониторинг доставляемости: что смотреть после отправки

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

Я обычно смотрю на такие показатели:

Нормальная работа с доставляемостью — это не ежедневное тревожное обновление отчёта, а регулярный осмотр. После каждой крупной кампании стоит выделить 10–15 минут и посмотреть, нет ли резких изменений. Если вчера bounce rate был около 0,5%, а сегодня стал 4%, это не «просто статистика», а повод остановиться и понять, какой сегмент дал проблему.

Обратите внимание на жалобы. Даже небольшое число жалоб может быть неприятным сигналом, если объём отправки небольшой. Часто причина не в том, что письмо «плохое», а в нарушенном ожидании: человек подписывался на уведомления о продукте, а получает частые рекламные предложения; скачивал один материал, а оказался в общей базе; давно не взаимодействовал с брендом и уже не узнаёт отправителя.

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

Типовые ошибки сервиса рассылок, которые на самом деле не в сервисе

Фраза «сервис рассылок шлёт в спам» понятна эмоционально, но технически не всегда точна. Платформа может быть только одним звеном в цепочке. Ошибка может жить в DNS, базе, шаблоне, интеграции или в истории домена.

Вот несколько ситуаций, которые я встречал чаще всего:

1. Подключили сервис, но не подтвердили домен полностью.

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

2. Используют бесплатный почтовый адрес как отправителя.

Массовые рассылки от адресов на публичных доменах вроде личных почтовых ящиков хуже подходят для брендовой коммуникации. Лучше использовать собственный домен и настроенную аутентификацию.

3. Меняют отправителя слишком часто.

Сегодня письма идут от info@, завтра от promo@, потом от личного имени без понятной связи с брендом. Получателям сложнее узнавать отправителя, а команде — анализировать репутацию.

4. Импортируют старую базу без сегментации.

В одном списке оказываются активные клиенты, старые лиды, участники давних мероприятий и случайные адреса. Для первого запуска это слишком шумная среда.

5. Слишком резко увеличивают объём.

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

6. Прячут отписку или делают её неудобной.

Человек не хочет искать способ уйти. Если отписка раздражает, кнопка «Спам» становится самым коротким путём.

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

Как возвращать доставляемость без резких движений

Если рассылки уже попадают в спам, не стоит сразу менять сервис, домен, шаблон, базу и частоту одновременно. Так вы потеряете возможность понять, что именно сработало. Лучше двигаться последовательно.

Сначала проверьте техническую часть: SPF, DKIM, DMARC, домен трекинга, адрес отправителя. Затем остановите отправку на сомнительные сегменты и оставьте только наиболее активную аудиторию. После этого очистите базу от hard bounce и старых неактивных контактов. Потом вернитесь к прогреву: небольшие объёмы, регулярный ритм, внимательное наблюдение.

Если репутация домена уже заметно просела, восстановление может занять время. Не стоит ждать мгновенного эффекта на следующий день после исправления DNS. Почтовые провайдеры смотрят на поведение в динамике. Хорошая новость в том, что аккуратная рутина действительно помогает: чистая база, ожидаемые письма, стабильный объём и нормальная аутентификация постепенно возвращают доверие.

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

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