Email-рассылки в 2026: как не попасть в спам и не нарушить закон

Открываемость рассылки упала с 24% до 6% за два месяца, база та же, тема писем та же. Знакомая история? Обычно дело не в контенте, а в трёх буквах, о которых маркетолог вспоминает последним - SPF, DKIM, DMARC.

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

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

Причин обычно несколько сразу, а не одна. Вот основные, по убыванию частоты в нашей практике.

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

Жалобы получателей - самый жёсткий сигнал. Кнопка "Это спам" в Gmail весит больше, чем десяток открытий письма. Google требует держать долю жалоб ниже 0,10% от отправленных писем для крупных отправителей, а по факту рекомендует ориентироваться на 0,08% с запасом (Google, Email sender guidelines). Один жалующийся на тысячу подписчиков - уже тревожный звонок.

Отсутствующие или неправильно настроенные SPF/DKIM/DMARC. Без них почтовик не может отличить ваше письмо от подделки - и на всякий случай перестраховывается спамом. Это ядро проблемы для большинства писем, которые молча теряются, а не отправителя даже не уведомляют об отказе.

Плохое качество базы. Спам-ловушки (адреса, специально созданные почтовиками для отлова недобросовестных рассылок), несуществующие ящики, старые подписчики, которые давно не открывают письма - всё это тянет метрики вниз (Mindbox, "11 способов не попасть в спам").

Есть и менее очевидный фактор - вовлечённость получателей. Gmail и другие крупные почтовики учитывают, сколько писем от конкретного отправителя открывают, а сколько удаляют не глядя; низкий отклик со временем снижает шансы попасть во "Входящие" даже при идеальной технической настройке. Отсюда правило сегментации, о котором ниже.

И, конечно, содержание самого письма - агрессивные CAPS в теме, спам-слова вроде "бесплатно!!!", ссылки на сомнительные домены. Это тоже играет роль, но по факту вторично: без технической базы content-фильтры даже не успевают среагировать - письмо уже отсеяно на этапе аутентификации.

SPF, DKIM, DMARC - что это и зачем

Три протокола, три разные задачи. Путать их не стоит - я регулярно вижу настроенный SPF без DKIM, и это половинчатое решение.

SPF (Sender Policy Framework) - DNS-запись у вашего домена со списком серверов, которым разрешено слать почту от вашего имени. Выглядит примерно так:

v=spf1 include:_spf.yandex.net include:mailgun.org ~all

Получил почтовик письмо якобы от example.ru - сверяет IP отправителя со списком в SPF-записи домена example.ru. Не совпало - подозрение на подделку.

DKIM (DomainKeys Identified Mail) - цифровая подпись, которую сервер отправителя добавляет к каждому письму приватным ключом. Публичный ключ лежит в DNS вашего домена. Получатель проверяет подпись - и знает, что текст письма не подменили в пути и оно действительно ушло с вашего домена, а не с чужого сервера, который просто представился вами.

DMARC (Domain-based Message Authentication) - надстройка над первыми двумя. Говорит почтовику, что делать, если SPF или DKIM не прошли: пропустить (p=none), отправить в спам (p=quarantine) или отклонить целиком (p=reject). Плюс DMARC присылает вам отчёты - кто вообще пытается слать письма от вашего имени, включая фишеров.

Настройка через панель управления DNS у регистратора домена или хостинг-провайдера занимает от получаса, если у вас один почтовый сервис (Яндекс 360, Google Workspace, транзакционный SMTP-провайдер). Сложнее, когда писем несколько источников - собственная CRM шлёт транзакционные письма, а массовые рассылки идут через Unisender или Sendsay. Тогда в SPF нужно перечислить все источники через include:, а DKIM настраивается отдельно для каждого сервиса. Забыли добавить один источник в SPF - и письма именно из него начнут проваливаться.

Частая техническая ошибка, которую я вижу у клиентов при первом аудите - две отдельные SPF-записи в DNS вместо одной объединённой. Стандарт разрешает только одну TXT-запись типа SPF на домен; если их две, почтовики трактуют это как ошибку конфигурации и вообще игнорируют обе. Все источники отправки должны попасть в единственную строку через include. Проверить итоговый результат удобно бесплатными инструментами вроде mail-tester.com или MXToolbox - они за минуту показывают, что именно не так с записями и какой балл получит письмо.

Яндекс рекомендует внедрять DMARC постепенно: сначала p=none для сбора статистики, потом pct=25 с постепенным повышением до pct=100 при переходе на p=quarantine или p=reject (Яндекс, настройка DMARC). Резкий переход сразу на reject без периода наблюдения - хороший способ похоронить легитимную почту вместе со спамом.

Что требуют Gmail, Yandex и Mail.ru в 2026 году

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

Gmail и Yahoo с февраля 2024 года требуют от отправителей 5000+ писем в сутки настроенных SPF и DKIM, а также DMARC-записи (политика может быть p=none, само наличие записи уже обязательно). Плюс - поддержку одноклик-отписки по RFC 8058 с обработкой запроса в течение двух дней, и жёсткий потолок жалоб 0,30% с рекомендованным рабочим уровнем 0,08% (Google, Email sender guidelines FAQ). Это правило действует и для меньших объёмов негласно - просто без формального порога.

Источники: Google Email sender guidelines, Помощь Mail.ru для разработчиков.

Mail.ru отдельно проверяет обратные DNS-записи (PTR) отправляющих серверов - они должны быть валидными и осмысленными, а не автосгенерированной строкой вида 123-45-67-89.dynamic.provider.ru. Для сервисов рассылок (ESP) действует правило двойного DKIM: подписывает и сама платформа, и домен клиента (Помощь Mail.ru, "Правила для сервисов рассылок"). Если отправляете через Unisender или похожий сервис от собственного домена - убедитесь, что настроены оба слоя, иначе письма Mail.ru пометит как подозрительные.

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

Кстати, про открываемость отдельная оговорка. С тех пор как Apple Mail стал по умолчанию подгружать пиксели отслеживания через собственный прокси (Mail Privacy Protection), метрика open rate по адресам на iCloud и Apple Mail превратилась в фикцию - письмо считается открытым, даже если человек его не читал. Ориентироваться стоит на клики и жалобы, а не на open rate, если заметная часть базы сидит на почте от Apple.

Согласие на рассылку - отдельная история от маркировки рекламы

Важный момент, который путают чаще всего: email-рассылки и push-уведомления не требуют токена erid и регистрации в ЕРИР - это прямое исключение из закона о маркировке интернет-рекламы. Подробнее о том, что вообще считается рекламой и как работает система ОРД/ЕРИР - в статье про маркировку интернет-рекламы.

Но освобождение от маркировки не освобождает от другого требования. Ст. 18 закона "О рекламе" (38-ФЗ) прямо запрещает распространение рекламы по сетям электросвязи без предварительного согласия абонента. На практике это значит: галочка "Согласен на обработку персональных данных" под формой заказа рекламную рассылку не разрешает - нужен отдельный чекбокс именно про рассылку, и он не может быть предзаполнен по умолчанию.

Штраф по ст. 14.3 КоАП за рассылку без согласия - 100 000-500 000 ₽ для юрлиц, при повторных нарушениях планка поднимается до 1 млн ₽. Полный разбор формулировок, cookie-согласия и смежных юридических требований к сайту - в отдельном чек-листе, здесь дублировать его нет смысла.

На мой взгляд, самая частая ошибка малого бизнеса - собирать email через форму "Подпишитесь на новости" без явного чекбокса согласия, а потом присылать промо-письма с расчётом, что раз человек сам оставил адрес - значит, согласился на всё. Юридически это не так.

Спросите себя прямо сейчас: в форме подписки на вашем сайте один общий чекбокс "на всё про персональные данные" или отдельный, именно про рекламную рассылку? Если общий - это дыра, которую стоит закрыть до следующей проверки, а не после неё. Двойное подтверждение (double opt-in), когда подписчик ещё раз кликает по ссылке в письме-подтверждении, - не юридическое требование само по себе, но лучшее доказательство согласия, если дело дойдёт до жалобы в ФАС.

Прогрев домена и гигиена базы

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

Схема прогрева обычно строится по нарастающей - неделя за неделей, с увеличением объёма не больше чем на 20-30% за раз:

На небольшую базу прогрев уходит 3-4 недели, на объём в сотни тысяч писем - до полутора-двух месяцев (DashaMail, Unisender, Mindbox - "Прогрев домена и почты для рассылки"). Зачем вообще ждать так долго, если технически всё настроено уже сегодня? Потому что почтовики оценивают историю отправок, а не факт настройки DNS-записей - у домена без истории просто нет данных, на основании которых можно доверять его репутации.

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

Гигиена базы работает параллельно с прогревом, а не вместо него:

• Удаляйте адреса с bounce (недоставка) после двух-трёх неудачных попыток - таскать мёртвый груз в базе портит статистику каждой следующей рассылки
• Сегментируйте по активности: тем, кто не открывал письма 6+ месяцев, шлите реже или выводите из активной рассылки
• Не покупайте базы. Спам-ловушки в купленных списках убивают репутацию домена за одну рассылку, восстановление занимает месяцы
• Проверяйте адреса на этапе сбора - валидация email в форме подписки экономит проблемы на старте
• Следите за метрикой жалоб в постмастерах Яндекса и Mail.ru еженедельно, а не раз в квартал

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

Из готовых сервисов для рассылок на рынке РФ выделяются Unisender (баланс цены и функциональности, подходит для старта), DashaMail (акцент на доставляемость и аналитику), Sendsay и Mailganer (мультиканальные сценарии - email плюс push плюс мессенджеры). Для 152-ФЗ важно, что данные хранятся на серверах в России - это плюс перечисленных сервисов перед иностранными платформами вроде Mailchimp.

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