Почему письма не доходят до Яндекса и Mail.ru: SPF, DKIM, DMARC и нужен ли ERID в рассылке

Сервис рассылок показывает «доставка 98%», а в аналитике редкие клики. Открытий нет, переходов нет, заказов тоже. Кто-то из знакомых на Яндексе говорит, что ваше письмо лежало в спаме. У кого-то оно не пришло вообще. Первая реакция: перепишем тему, сменим время отправки, добавим эмодзи. Мимо. Чаще всего всё упирается в DNS, в репутацию домена и в базу, которую когда-то собрали «как получилось». Ну и в закон, куда без него.

Разберу по порядку. Как почтовики решают судьбу письма, отправленное через сервис почтовых рассылок что настроить и в какой последовательности, где заканчивается маркетинг и начинается ответственность. Отдельно про ERID: вокруг него шума больше, чем смысла. Законы и справку Яндекса я сверял с первоисточниками, дата актуальности указана выше. Где нормы меняются быстро, называю дату и документ.

Как почтовики решают судьбу вашего письма

У письма на пути две технические развилки. Сначала SMTP: принимающий сервер может отказать сразу, и вы получите служебный отчёт о недоставке. В справке Яндекса сказано, что в этом отчёте от Mailer-Daemon есть причина отказа и имя сервера, который письмо заблокировал. Я с этого текста начинаю любой разбор. Его почему-то никто не читает. Вторая развилка уже фильтр: письмо принято, но улетело в «Спам». Дальше слово за человеком. Открыть, пропустить, нажать «Это спам».

Как именно Яндекс и Mail.ru отличают рассылку от спама, они не рассказывают. Яндекс прямо пишет, что алгоритм разделения это его ноу-хау, и обсуждать его никто не будет. Остаётся читать опубликованные требования и думать, как устроены репутационные системы. Логика простая: оценивают не письмо, а отправителя. Всю его историю.

Что в эту историю попадает:

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

Репутация привязана к домену и к IP. Если вы отправляете с общего IP сервиса, делите её с соседями, а соседи бывают всякие. Выделенный IP даёт независимость, но и всю ответственность. И стартует он с нуля.

Теперь о том, как понять, что случилось. Сначала прочитайте отказы целиком: код и пояснение сервера обычно показывают, в какую сторону копать. Потом подключите домен к Постмастеру Mail.ru.

Он показывает статистику по ящикам Mail.ru, жалобы (это система обратной связи FBL) и ошибки вроде отсутствующего SPF или проваленного DMARC. Без подтверждения прав на домен он не заработает. Если Mail.ru вас заблокировал, сначала исправьте причины и только потом пишите в поддержку, например на abuse@corp.mail.ru. Без исправлений разблокировку, судя по разборам и ответам сотрудников VK, обычно не дают. И последнее: отправьте тестовое письмо на свои ящики на Яндексе, Mail.ru и Gmail, откройте служебные заголовки и найдите строку Authentication-Results. Там написано, как приёмник оценил SPF, DKIM и DMARC. Честнее любого отчёта сервиса.

SPF, DKIM и DMARC: что это, как настроить и как проверить

Три технологии отвечают на один вопрос: имеет ли отправитель право писать от имени этого домена. Друг от друга они не зависят, но работают вместе. Пропустите одну, и в защите дыра.

Начну со SPF. Он описан в RFC 7208. Вы публикуете в DNS TXT-запись со списком серверов, которым можно отправлять почту от имени домена. Получатель сверяет IP отправителя с этим списком. Нюанс, о котором забывают: проверяется домен из технического адреса Return-Path, а не из поля «От кого». Для DMARC это окажется важным. Вот шаблон записи для вымышленного домена:

example.ru. IN TXT "v=spf1 include:_spf.esp-example.net ~all"

Расшифровка короткая. v=spf1 версия протокола. include: разрешает серверы вашего сервиса рассылок, конкретное значение он вам выдаст сам. ~all мягкая политика: всё остальное считается подозрительным. Есть ещё жёсткий -all, он запрещает остальное целиком. Я начинаю с мягкого. Убедился, что все нужные источники учтены, тогда уже можно думать об ужесточении.

Ошибки в SPF почти всегда одни и те же. Первая: две записи на одном домене. Стандарт разрешает одну запись v=spf1, а две дают permerror и никогда не склеиваются. Вторая: больше десяти DNS-запросов. RFC 7208 ограничивает проверку десятью терминами (include, a, mx, exists, redirect и давно устаревший ptr), превысили лимит, получили тот же permerror. Когда в компании живут CRM, сервис рассылок, почта, поддержка и ещё что-то из прошлого года, лимит заканчивается быстрее, чем кажется. Третья: подключили новый сервис, а в SPF его не вписали.

С DKIM история другая. Он описан в RFC 6376. Отправитель подписывает письмо закрытым ключом, получатель проверяет подпись открытым, который лежит в DNS. Подпись сидит в заголовке DKIM-Signature, и если письмо по пути изменили, проверка не пройдёт. Открытый ключ публикуется по адресу вида селектор._domainkey.домен:

mail1._domainkey.example.ru. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq...(открытый ключ)"

mail1 это селектор, у домена их может быть несколько. k=rsa тип ключа, p= сам ключ. Длину обычно берут 2048 бит. Теперь главная ловушка. Многие сервисы по умолчанию подписывают письма своим доменом. Подпись при этом валидна, но принадлежит не вам, и для DMARC она не считается. Поэтому в настройках сервиса включите подпись вашим доменом и добавьте выданную запись в DNS. У Яндекса тут не пожелание, а жёсткое требование: все письма рассылки должны быть подписаны DKIM, и SPF у домена тоже должен быть.

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

И свежая новость, которую пока мало кто упоминает. В мае 2026 года IETF выпустил новую редакцию DMARC. Протокол теперь описан в RFC 9989, агрегированные отчёты в RFC 9990, отчёты о сбоях в RFC 9991. Они заменили RFC 7489 от 2015 года, тот был всего лишь информационным. Теги pct, rf и ri из основной модели убрали, добавили флаг тестирования. Старые записи продолжают работать, версия по-прежнему v=DMARC1, так что ничего срочно переписывать не надо. Просто если инструкция ссылается на RFC 7489, знайте, что она устарела. Базовая запись для старта:

_dmarc.example.ru. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.ru"

p=none значит «только наблюдаем». Ничего не блокируется, зато на адрес из rua= начинают приходить агрегированные отчёты в XML. Дальше лесенка. Пару-тройку недель собираете отчёты и выясняете, кто вообще пишет от вашего имени: рассылка, CRM, бухгалтерия, поддержка. Чините источники. Потом p=quarantine. И когда уверены в каждом, p=reject.

Что с этим у Яндекса и Mail.ru? В официальных требованиях Яндекса DMARC числится в рекомендованных, не в обязательных. Постмастер Mail.ru проваленный DMARC считает проблемой. А Gmail и другие крупные получатели от массовых отправителей его ждут. Я настраиваю все три механизма всегда, что бы там ни было в базе.

Проверка занимает пять минут. Письмо на ящики Яндекса, Mail.ru и Gmail, в Authentication-Results ищем spf=pass, dkim=pass, dmarc=pass. Домены подписи DKIM и Return-Path должны совпадать с вашим доменом или его поддоменом. Иначе выравнивание не сработает, и DMARC упадёт.

Отдельно про адрес отправителя. Рассылать с @mail.ru, @yandex.ru или @gmail.com нельзя. Mail.ru включил строгую политику DMARC на своих публичных доменах ещё в 2016 году, так что письмо с такого адреса через сторонний сервис проверку не пройдёт. Яндекс, в свою очередь, требует, чтобы адрес отправителя соответствовал аккаунту, под которым вы авторизуетесь на сервере. Выход один: писать с адреса на своём домене.

Остальная техническая база: PTR, IP-адрес, заголовки

Аутентификации недостаточно. Дальше идёт слой, который в инструкциях любят пропускать.

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

Про прогрев. У нового IP нет истории, и почтовики не знают, чего от него ждать. Начинайте с малых объёмов, пишите самым живым подписчикам, объём наращивайте постепенно, следите за отказами и жалобами. Графиков прогрева в документе Яндекса о честных рассылках нет, поэтому ориентируйтесь на показатели в Постмастере, а не на таблицы из чужих блогов.

Домен тоже лучше разделить. Яндекс советует отправлять массовые письма с хоста, отличного от того, что используется для обычной переписки. Если так нельзя, нужен отдельный домен в «От кого», вроде news.example.ru. Смысл понятен: если рассылка наберёт жалоб, деловая переписка не должна пострадать. Я делю потоки минимум на три. Транзакционные письма (заказ, счёт, сброс пароля). Рекламные рассылки. Обычная почта сотрудников.

Отписка. В обязательных требованиях Яндекса значится заголовок List-Unsubscribe по RFC 2369. Переход по ссылке из него должен сразу отписывать человека, все ссылки на отписку должны работать, а процесс не должен занимать больше десяти минут и требовать регистрации. Современная версия, отписка в один клик, описана в RFC 8058: добавляется заголовок List-Unsubscribe-Post, и почтовый клиент отправляет запрос сам. Такой механизм от массовых отправителей требуют Gmail и Yahoo.

Из обязательного в документации Яндекса есть ещё стандартные заголовки массовых рассылок вроде Precedence: bulk, реальный адрес в «От кого» и соответствие RFC 5322 и MIME, включая правильные Date и Message-ID. Из рекомендаций: не использовать сокращатели ссылок, писать в ссылках полные доменные имена, а не IP, и не совать JavaScript в HTML-письма.

Почему бы не рассылать с обычного ящика? Потому что лимиты. Яндекс указывает в справке: 50 писем в сутки через мобильное приложение, 1000 через сайт, 300 через почтовую программу или SMTP. Письмо с десятью получателями считается за десять. А защита может сработать и раньше лимита, если увидит шаблонную рассылку.

Выбираете сервис рассылок, и вот что стоит у него спросить. Подписывает ли он DKIM вашим доменом и можно ли направить Return-Path на ваш домен. Исключает ли сам адреса, отвечающие «пользователя нет». Как обрабатывает жалобы и отписки, есть ли List-Unsubscribe и отписка в один клик. Модерирует ли клиентов, иначе общие IP страдают от чужих грехов. И, пожалуй, самое важное: где физически лежит ваша база. Первичный сбор и хранение персональных данных россиян должны идти в базах на территории России, это часть 5 статьи 18 закона № 152-ФЗ.

Качество базы и поведение рассылки

Идеальные DNS-записи не спасут рассылку по плохой базе. Репутацию делают адреса, которым вы пишете, и то, как люди на вас реагируют.

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

С купленными базами всё просто и грустно. Согласия вы не докажете. Часть адресов устарела. Рассылка нарушит и закон, и правила почтовых сервисов. Сервисы рассылок такие кампании обычно режут ещё на модерации. И отдельно: деловая переписка не равна согласию на рекламу. Человек однажды написал вам письмо? Это не повод добавлять его в рассылку.

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

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

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

И жалобы. Если отписаться сложнее, чем пожаловаться, человек нажмёт «Это спам». Поэтому ссылка на отписку должна быть заметной и срабатывать мгновенно. Отписка репутации почти не вредит. Жалоба вредит сильно.

Закон: согласие на рассылку и ответственность

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

Начнём со статьи 18 закона «О рекламе». Реклама по сетям электросвязи допускается только при предварительном согласии адресата (часть 1 статьи 18 закона от 13.03.2006 № 38-ФЗ). Если рекламораспространитель не докажет, что согласие было, реклама считается распространённой без него. Доказывать должны вы, а не получатель. И по требованию адресата рассылку нужно немедленно прекратить. Распространяется ли всё это на email? Да. Так указал Верховный Суд в определении от 08.07.2021 № 310-ЭС21-10616 по делу № А14-8969/2020, и ФАС относит email-рассылки к рекламе по сетям электросвязи. Понятие спама есть ещё и в Правилах оказания телематических услуг связи (утверждены постановлением Правительства от 31.12.2021 № 2607): сообщение для неопределённого круга лиц, доставленное без предварительного согласия и без возможности определить отправителя.

Что считать согласием? Форму закон не называет, но практика ФАС задаёт ориентиры. Согласие даёт сам человек, и по нему можно понять, кто он. Оно касается именно рекламы, а не обработки данных вообще. Галочка не должна стоять заранее: в решениях региональных УФАС нарушением признавали ситуацию, когда у пользователя фактически не было возможности отказаться. И согласие надо уметь подтвердить: адрес, дата и время, источник, формулировка, которую человек видел. Я бы ещё сохранял версию текста формы на момент подписки. Пригодится.

Теперь персональные данные. Адрес электронной почты, особенно в связке с именем, как правило, относится к персональным данным, так что на базу подписчиков действует закон от 27.07.2006 № 152-ФЗ. Тут три момента.

• Федеральный закон от 24.06.2025 № 156-ФЗ с 01.09.2025 поменял статью 9: согласие на обработку нужно оформлять отдельно от других документов и сведений, которые человек подтверждает или подписывает. Прятать его в пользовательское соглашение нельзя. Новые правила касаются согласий, полученных после этой даты. В форме подписки получается два отдельных чекбокса: на обработку данных и на получение рекламы.
• Локализация баз по части 5 статьи 18 закона № 152-ФЗ. Про место хранения спросите у сервиса рассылок до подключения.
• Федеральный закон от 30.11.2024 № 420-ФЗ с 30.05.2025 добавил в статью 13.11 КоАП новые составы. За утечки штрафы зависят от числа пострадавших, повторные наказываются строже, появилась ответственность за неуведомление Роскомнадзора. База подписчиков давно не просто таблица в маркетинге.

Сколько стоит рассылка без согласия? Действует часть 4.1 статьи 14.3 КоАП. Штрафы по состоянию на октябрь 2026 года такие: гражданам от 10 до 20 тысяч рублей, должностным лицам от 20 до 100 тысяч, организациям от 300 тысяч до 1 миллиона. Повышенные размеры действуют с апреля 2024 года. Региональные управления ФАС порой выносят предупреждение вместо штрафа за первое нарушение, только строить на этом политику рассылок не надо. Кроме административных дел, по статье 38 закона о рекламе можно подавать иски о возмещении убытков и компенсации морального вреда. А начинается всё обычно с жалобы получателя в ФАС. Приложить письмо, и достаточно.

Последнее: рекламные и служебные письма. Статья 18 про рекламу. Транзакционные письма (подтверждение заказа, чек, сброс пароля) рекламой, как правило, не считаются. Но если вы добавите в такое письмо рекламный блок, статус может поменяться. Держите потоки отдельно. Репутация чище, юристам спокойнее.

Нужен ли ERID в email-рассылке

Тема, из-за которой в 2022–2023 годах многие маркетологи нервничали. И которую зачем-то часто связывают с доставляемостью.

С 1 сентября 2022 года действует статья 18.1 закона «О рекламе». Она требует маркировать рекламу в интернете: получить для креатива токен erid у оператора рекламных данных, поставить пометку «Реклама» и сведения о рекламодателе, передать отчётность в Единый реестр интернет-рекламы (ЕРИР).

Роскомнадзор в письме от 24.10.2023 № 03-97847 разъяснил, что требования статьи 18.1 не распространяются на рекламу, направляемую на адреса электронной почты, то есть на email-рассылки, и на push-рассылки. ФАС объясняет это так: email идёт по сетям электросвязи, как SMS, и регулируется статьёй 18, а не 18.1. Так что ответ прямой. ERID в обычной email-рассылке не нужен. Нужно согласие получателя. Это две разные нормы с разными последствиями, и если путать их, получается смешно: компания возится с токенами и при этом не собирает согласий.

Серая зона, конечно, остаётся. Тему нельзя считать закрытой на все случаи. Часть участников рынка из осторожности маркирует письма «с запасом», особенно если реклама размещается за деньги в рассылке стороннего издателя. Разъяснений регулятора, которые бы опровергали письмо 2023 года, я на октябрь 2026-го не нашёл. Но у вас что-то нестандартное, платные размещения в чужих рассылках, партнёрские кампании? Покажите схему юристу. Законодательство о рекламе меняется часто.

Теперь главное. Даже если промаркировать письмо, доходить оно лучше не станет. Токен адресован регулятору, не почтовому фильтру. В требованиях Яндекса к рассылкам о маркировке нет ни слова. Там аутентификация, отписка, подтверждение адреса, обратная DNS-запись, заголовки и поведение при несуществующих адресах. Решение о письме принимается по репутации и технике. Поэтому, если доставляемость просела, начинайте не с юристов и токенов, а с текстов отказов, Authentication-Results, Постмастера и жалоб.

Чек-лист перед запуском рассылки и выводы

Перед каждым запуском я проверяю по технической части вот что:

• одна SPF-запись, не больше десяти DNS-запросов, учтены все отправители;
• DKIM подписывает письма вашим доменом, ключ 2048 бит;
• DMARC опубликован (начните с p=none), отчёты кто-то читает;
• PTR настроен, WHOIS актуален, домен подключён к Постмастеру Mail.ru;
• рассылка идёт с вашего домена или поддомена, не с публичного адреса;
• в каждом письме работает List-Unsubscribe, лучше с отпиской в один клик.

И по базе и закону:

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

Что в итоге. Письма не доходят до Яндекса и Mail.ru не по одной причине, а по совокупности, и почти всё из этого в ваших руках. Сначала аутентификация и сетевая идентификация. Потом порядок в базе и согласиях. Потом контроль жалоб. ERID в обычной email-рассылке не требуется, а вот согласие получателя требуется всегда, и именно его отсутствие приводит к штрафам и к жалобам, которые убивают доставляемость. Нестандартную схему покажите юристу.

Что вам проверить:

1. В DNS домена ровно одна SPF-запись.
2. В заголовках тестового письма на Яндексе, Mail.ru и Gmail стоят spf=pass, dkim=pass, dmarc=pass.
3. Вы знаете, каким доменом ваш сервис подписывает DKIM.
4. Домен подключён к Постмастеру Mail.ru, раздел проблем просмотрен.
5. В форме подписки два отдельных чекбокса и ссылка на политику обработки данных.
6. Отписка срабатывает мгновенно, заголовок List-Unsubscribe на месте.
7. Вы знаете, где хранится ваша база подписчиков.

Какими источниками пользовались:

• Федеральный закон от 13.03.2006 № 38-ФЗ «О рекламе», статьи 18, 18.1, 38.
• Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», статья 9, часть 5 статьи 18.
• Федеральный закон от 24.06.2025 № 156-ФЗ (согласие на обработку персональных данных отдельным документом, с 01.09.2025).
• Федеральный закон от 30.11.2024 № 420-ФЗ (изменения в КоАП РФ, статья 13.11, с 30.05.2025).
• КоАП РФ: статья 14.3 (часть 4.1), статья 13.11.
• Правила оказания телематических услуг связи (утв. постановлением Правительства РФ от 31.12.2021 № 2607).
• Определение Верховного Суда РФ от 08.07.2021 № 310-ЭС21-10616 по делу № А14-8969/2020.
• Письмо Роскомнадзора от 24.10.2023 № 03-97847.
• Справка Яндекс Почты «Отправить много писем», раздел «Требования Яндекса к честным рассылкам».
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989, 9990, 9991 (DMARC, май 2026), RFC 2369 и RFC 8058 (List-Unsubscribe), RFC 5322 (формат сообщений).