Сервис рассылок показывает «доставка 98%», а открытий нет. Кто-то говорит, что письмо лежало в спаме, кто-то его вообще не получил. Проблема почти всегда не в теме и не во времени отправки — она в DNS, репутации домена и качестве базы.
Как почтовики оценивают письмо
У письма две развилки. Первая — SMTP: сервер может отказать сразу и прислать служебный отчёт от Mailer-Daemon с причиной отказа и именем заблокировавшего сервера. Вторая — фильтр: письмо принято, но ушло в «Спам».
Яндекс открыто пишет, что алгоритм разделения — его ноу-хау. Остаётся опираться на опубликованные требования. Оценивают не письмо, а отправителя — всю его историю. Смотрят на следующее:
- проходят ли SPF и DKIM, совпадают ли домены с адресом в «От кого»;
- постоянный IP, корректная обратная DNS-запись (PTR), актуальные данные о владельце домена;
- адреса, которых не существует: если сервер отвечает «такого пользователя нет», писать туда нельзя — это обязательный пункт у Яндекса;
- явное согласие получателя и подтверждённый адрес;
- жалобы, отписки, письма, удалённые без прочтения.
Репутация привязана к домену и IP. На общем IP сервиса вы делите её с соседями. Выделенный IP даёт независимость, но стартует с нуля.
Чтобы понять, что произошло: читайте отказы целиком — код и пояснение сервера показывают направление. Подключите домен к Постмастеру Mail.ru: он показывает статистику по ящикам, жалобы через FBL и ошибки вроде отсутствующего SPF или проваленного DMARC. Если Mail.ru заблокировал — сначала исправьте причины, только потом пишите на [email protected]. Без исправлений разблокировку обычно не дают. Отправьте тестовое письмо на ящики Яндекса, Mail.ru и Gmail, откройте служебные заголовки и найдите строку Authentication-Results — там написано, как приёмник оценил SPF, DKIM и DMARC.
SPF, DKIM и DMARC: настройка и проверка
Три технологии отвечают на один вопрос: имеет ли отправитель право писать от имени этого домена. Пропустите одну — в защите дыра.
SPF описан в RFC 7208. Вы публикуете в DNS TXT-запись со списком серверов, которым можно отправлять почту от имени домена. Нюанс: проверяется домен из технического адреса Return-Path, а не из поля «От кого». Типичные ошибки: две записи v=spf1 на одном домене (стандарт разрешает одну, две дают permerror), больше десяти DNS-запросов (RFC 7208 ограничивает ровно десятью терминами — include, a, mx, exists, redirect и устаревший ptr), и новый сервис, который забыли вписать в SPF.
DKIM описан в RFC 6376. Отправитель подписывает письмо закрытым ключом, получатель проверяет открытым из DNS. Если письмо по пути изменили, проверка не пройдёт. Длину ключа обычно берут 2048 бит. Главная ловушка: многие сервисы по умолчанию подписывают письма своим доменом, а не вашим. Подпись валидна, но для DMARC не считается. У Яндекса это жёсткое требование: все письма рассылки должны быть подписаны DKIM вашим доменом, и SPF тоже должен быть.
DMARC связывает SPF и DKIM с адресом в «От кого». Письмо проходит DMARC, если сработала хотя бы одна проверка и домен в ней совпал с доменом из «От кого» — это выравнивание. Отсюда парадокс: DKIM чужого домена и SPF по техническому адресу сервиса дают провал DMARC, хотя по отдельности обе проверки зелёные.
В мае 2026 года IETF выпустил новую редакцию DMARC. Протокол теперь описан в RFC 9989, агрегированные отчёты — в RFC 9990, отчёты о сбоях — в RFC 9991. Они заменили RFC 7489 от 2015 года. Теги pct, rf и ri убрали, добавили флаг тестирования. Старые записи продолжают работать, версия по-прежнему v=DMARC1. Начинать стоит с p=none — ничего не блокируется, но на адрес из rua= приходят агрегированные отчёты в XML. Дальше лесенка: несколько недель собираете отчёты, чините источники, переходите на p=quarantine, потом на p=reject.
В официальных требованиях Яндекса DMARC числится в рекомендованных, не в обязательных. Постмастер Mail.ru проваленный DMARC считает проблемой. Gmail и другие крупные получатели от массовых отправителей его ждут.
Рассылать с @mail.ru, @yandex.ru или @gmail.com нельзя. Mail.ru включил строгую политику DMARC на публичных доменах ещё в 2016 году — письмо с такого адреса через сторонний сервис проверку не пройдёт. Яндекс требует, чтобы адрес отправителя соответствовал аккаунту авторизации на сервере. Выход один — писать с адреса на своём домене.
Техническая база: PTR, IP, заголовки и лимиты
Яндекс обязывает использовать постоянный IP с корректной PTR-записью и актуальными данными в WHOIS. Если работаете через сервис рассылок, об этом заботится он. Собственный сервер — PTR настраивается у владельца IP.
Яндекс советует отправлять массовые письма с хоста, отличного от того, что используется для обычной переписки. Если нельзя — нужен отдельный домен в «От кого», вроде news.example.ru. Смысл: если рассылка наберёт жалоб, деловая переписка не пострадает.
Из обязательных требований Яндекса: заголовок List-Unsubscribe по RFC 2369, переход по ссылке из него должен сразу отписывать, процесс не должен занимать больше десяти минут и требовать регистрации. Отписка в один клик по RFC 8058 — через заголовок List-Unsubscribe-Post — обязательна у Gmail и Yahoo.
Лимиты обычного ящика Яндекса: 50 писем в сутки через мобильное приложение, 1000 через сайт, 300 через почтовую программу или SMTP. Письмо с десятью получателями считается за десять.
База, согласие и закон
Идеальные DNS-записи не спасут рассылку по плохой базе. Яндекс требует явное согласие и подтверждение адреса самим получателем — на практике это двойное подтверждение: человек оставил адрес, получил письмо со ссылкой, перешёл по ней, и только тогда попал в активную базу. Адреса с ответом «пользователя нет» убираем сразу — у Яндекса это обязательный пункт. Резкие скачки объёма выглядят как взлом аккаунта или начало спам-кампании.
С купленными базами всё просто: согласия не доказать, часть адресов устарела, сервисы рассылок такие кампании режут на модерации. Деловая переписка не равна согласию на рекламу.
По закону. Часть 1 статьи 18 закона от 13.03.2006 № 38-ФЗ «О рекламе»: реклама по сетям электросвязи допускается только при предварительном согласии адресата. Доказывать должны вы, а не получатель. Верховный Суд в определении от 08.07.2021 № 310-ЭС21-10616 по делу № А14-8969/2020 подтвердил, что это распространяется на email. ФАС относит email-рассылки к рекламе по сетям электросвязи. Понятие спама есть и в Правилах оказания телематических услуг связи (постановление Правительства от 31.12.2021 № 2607): сообщение для неопределённого круга лиц без предварительного согласия и без возможности определить отправителя. Первичный сбор и хранение персональных данных россиян должны идти на серверах в России — это часть 5 статьи 18 закона № 152-ФЗ.
По материалам Actualtraffic.
