Яндекс 360 отправитель: доставляемость доменной почты

1. Для какой ситуации эта статья

Материал для команд, у которых корпоративная почта работает на Яндекс 360 (бывшая Почта для домена): ящики вида имя@вашдомен.ru, администрирование через admin.yandex.ru, отправка через веб-интерфейс или SMTP Яндекса. Типовые жалобы: клиенты не получают ответы, письма падают в спам у получателей на Gmail и Mail.ru, Яндекс возвращает отказ при отправке.

Важно не путать две задачи. Первая: вы отправитель, и письма с вашего домена на Яндекс 360 плохо доходят до получателей на любых сервисах. Вторая: ваши рассылки из внешнего ESP плохо доходят до ящиков @yandex.ru. Эта статья про первую задачу. Про вторую читайте материал о попадании в спам Яндекса у получателей.

Еще одно ограничение: Яндекс 360 это почтовый сервис для деловой переписки, а не платформа для массовых рассылок. Для маркетинговых потоков на десятки тысяч писем нужен отдельный ESP, обычно на поддомене. Об этом ниже.

2. Как устроена отправка через Яндекс 360

Когда вы отправляете письмо из ящика на Яндекс 360, его принимает и доставляет инфраструктура Яндекс Почты. Отсюда следуют три практических вывода.

Первый: IP-адреса и HELO принадлежат Яндексу, их репутацию вы не контролируете и не прогреваете. Ваша зона ответственности: домен отправителя и его DNS-записи, содержимое писем, качество адресатов.

Второй: DKIM-подпись ставит Яндекс, но только если вы опубликовали открытый ключ в DNS своего домена. Для доменной почты используется селектор mail, то есть запись вида mail._domainkey.вашдомен.ru. Пока ключ не опубликован, письма уходят без валидной DKIM-подписи вашего домена, и это частая причина спама.

Третий: у Яндекса нет публичного постмастер-кабинета для отправителей, в отличие от Google Postmaster Tools и Mail.ru Postmaster. Статистику по домену вы сможете видеть в инструментах Google и Mail.ru (если получатели там), а по трафику на @yandex.ru ориентирами остаются тестовые отправки, заголовки писем и косвенные метрики вроде открываемости.

3. Ограничения Яндекс 360 для рассылок

Для ящиков Яндекс 360 действуют суточные ограничения на количество отправляемых писем и получателей, точные значения зависят от тарифа и возраста ящика, проверяйте актуальные цифры в справке Яндекса. При превышении лимита отправка временно блокируется: это выглядит как "письма не доходят", хотя до SMTP-сессии с сервером получателя дело вообще не доходит.

Практический вывод: счета, договоры, письма клиентам из CRM в ручном режиме, внутренняя переписка: все это нормальный сценарий для Яндекс 360. Маркетинговая рассылка на базу в тысячи адресов: нет, для этого нужен ESP с собственной инфраструктурой, обработкой возвратов и механизмом отписки.

Если рассыльщик уже подключен, разведите потоки на уровне DNS: корпоративная переписка остается на основном домене с MX Яндекса, массовые рассылки уходят с поддомена (например, news.вашдомен.ru) через ESP. Так репутация и настройки аутентификации одного потока не ломают другой.

4. SPF, DKIM и DMARC для домена на Яндекс 360

Минимальный набор записей для доменной почты на Яндекс 360 выглядит так (синтаксис примерный, сверяйте со справкой Яндекса и значениями из панели admin.yandex.ru):

MX: вашдомен.ru. 3600 IN MX 10 mx.yandex.net. Без корректной MX входящая почта на домен не придет, а ответы на ваши письма будут теряться.

SPF: если домен отправляет письма только через Яндекс 360, справка Яндекса рекомендует v=spf1 redirect=_spf.yandex.net. Если тот же домен шлет еще и через ESP, используйте include вместо redirect и добавьте include ESP в ту же запись, например: v=spf1 include:_spf.yandex.net include:spf.esp-provider.ru ~all. Вторая TXT-запись с v=spf1 на том же домене недопустима: при двух записях SPF ломается полностью, для всех отправителей сразу.

DKIM: в административной панели Яндекс 360 для домена берется публичный ключ и публикуется TXT-записью на имя mail._domainkey.вашдомен.ru, значение вида v=DKIM1; k=rsa; p=MIIBIjANBg... (длинный ключ целиком, без пробелов и переносов внутри p=). После публикации подпись начнет проходить проверку: в заголовках письма появится dkim=pass с d=вашдомен.ru.

DMARC: стартовая запись _dmarc.вашдомен.ru со значением v=DMARC1; p=none; rua=mailto:dmarc@вашдомен.ru. Политика none ничего не блокирует, но включает отчеты, по которым видно, кто шлет с домена и проходят ли SPF и DKIM. После анализа отчетов политику усиливают до quarantine и reject.

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

dig TXT вашдомен.ru +short (ищем одну строку v=spf1), dig TXT mail._domainkey.вашдомен.ru +short (ищем v=DKIM1), dig TXT _dmarc.вашдомен.ru +short (ищем v=DMARC1). В Windows вместо dig: nslookup -type=TXT вашдомен.ru.

5. Дерево диагностики: письма не доходят или в спаме

Начните с локализации отказа: письмо вообще не ушло, ушло, но вернулся баунс, или ушло без ошибки, но у получателя его нет во входящих. От этого зависит ветка проверки.

Разбор реального случая. Письмо из Яндекс 360 уходит в спам Gmail, хотя SPF настроен. Открываем заголовки у получателя: spf=pass (smtp.mailfrom=ящик@вашдомен.ru), dkim=none (message not signed), dmarc=pass или dmarc=none, если DMARC-записи еще нет. Причина в спаме не DMARC: конверт при отправке из Яндекс 360 не подменяется, поэтому SPF выравнивается с доменом From и формально проходит. Причина: запись mail._domainkey не опубликована, поэтому DKIM-подписи вашего домена нет вовсе, а без DKIM почтовые фильтры доверяют письму меньше. Лечение: опубликовать DKIM-ключ для домена и проверить результат через сутки, после обновления кеша DNS, - в заголовках должен появиться dkim=pass с d=вашдомен.ru.

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

6. Как проверить результат

Шаг 1. DNS-проверка. Прогоните домен через проверку записей: SPF (одна запись, нужные include, меньше 10 DNS-запросов при раскрытии), DKIM (ключ на месте), DMARC (запись есть, синтаксис валиден).

Шаг 2. Тестовое письмо на ящики в Gmail, Mail.ru, Яндексе и Outlook. У каждого получателя смотрите: папка входящие или спам, и заголовки письма, строки spf, dkim, dmarc с доменом в d=. Быстрый способ: вставьте заголовки в бесплатный анализатор на нашем сайте, он разберет результаты аутентификации.

Шаг 3. Статистика постмастер-кабинетов по домену. В Google Postmaster Tools (API v2): доли писем с пройденными SPF, DKIM, DMARC, доля жалоб (пороги Google: выше 0,1% уже зона риска, 0,3% и выше: серьезные проблемы с доставкой). В Mail.ru Postmaster: объем, доставка, жалобы и показатель "Репутация, %", это средний процент жалоб за 30 дней, чем меньше, тем лучше; допустимый порог зависит от месячного объема по таблице справки Mail.ru.

Шаг 4. Постоянный контроль, а не разовая проверка. Записи DNS затирают при смене хостинга, ESP меняет include в SPF, провайдер меняет DKIM-селектор или ротирует ключ - у самой DKIM-записи срока действия нет, но она перестает совпадать с тем, что реально подписывает письма. PostmastersTool проверяет SPF, DKIM, DMARC, MX и черные списки для вашего домена по расписанию, собирает данные Google Postmaster Tools и Mail.ru Postmaster, принимает DMARC-отчеты и присылает уведомление в Telegram или на почту, когда метрика пересекает порог. Статистика привязана к домену d= в DKIM-подписи, поэтому смена селектора s= историю не обнуляет.