SPF, DKIM и DMARC для Яндекс 360 и Mail.ru: настройка за один вечер

SPF, DKIM и DMARC для Яндекс 360 и Mail.ru для бизнеса: какие TXT-записи внести в DNS, где взять значения и как проверить, что письма перестали лететь в спам.

SPF, DKIM и DMARC — три TXT-записи в DNS вашего домена. Первая перечисляет серверы, которым разрешено отправлять письма от имени домена, вторая подписывает каждое письмо цифровым ключом, третья говорит принимающему серверу, что делать с письмом, не прошедшим проверку. Для Яндекс 360 и Mail.ru для бизнеса вся настройка сводится к одному вечеру: скопировать готовые значения из админ-панели почты и внести их у DNS-хостера.

Если записей нет или они внесены с ошибкой, сервер получателя не может отличить ваше письмо от подделки — и по умолчанию считает его подозрительным. Для холодной переписки это почти гарантированная спам-папка. Ниже — конкретные значения записей для обеих платформ, нюансы российских DNS-хостеров и способ проверить результат за пять минут.

Почему без этих записей письма летят в спам

Когда письмо приходит на сервер получателя, тот отвечает на три вопроса: имел ли право отправляющий сервер писать от этого домена (SPF), не изменилось ли письмо по дороге и подписано ли оно владельцем домена (DKIM), что делать, если проверки не пройдены (DMARC). Если ответа нет, фильтр исходит из худшего предположения.

С февраля 2024 года Google и Yahoo требуют настроенных SPF, DKIM и DMARC, отписки в один клик и доли жалоб на спам ниже 0,3% уже от крупных отправителей на их адреса. Российские площадки — Яндекс и Mail.ru — применяют сопоставимые проверки при любом объёме: наличие записей давно один из базовых сигналов репутации. Для B2B-аутрича, где домен отправляет сотни писем в день незнакомым людям, отсутствие настройки читается фильтром как «отправитель, которому есть что скрывать».

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

Сводка: какие записи нужны

Значения DKIM у каждого домена свои — публичный ключ выдаёт админ-панель почтовой платформы. MX-записи для приёма почты тоже обязательны, но их значения платформа показывает при добавлении домена; здесь разбираем только три записи, отвечающие за отправку.

Настройка в Яндекс 360

1. Откройте админ-панель (admin.yandex.ru), раздел с доменами, и подтвердите владение доменом, если это ещё не сделано.
2. SPF: создайте у DNS-хостера TXT-запись для @ со значением v=spf1 redirect=_spf.yandex.net — она подходит, если от имени домена пишет только Яндекс.
3. DKIM: в карточке домена Яндекс покажет статус DKIM-подписи и публичный ключ. Создайте TXT-запись с именем mail._domainkey и значением вида v=DKIM1; k=rsa; p=MIIBIjANBg... — ключ копируется целиком, без пробелов и переносов.
4. DMARC: TXT-запись с именем _dmarc и значением v=DMARC1; p=none; rua=mailto:postmaster@вашдомен.ru.
5. Вернитесь в админ-панель через час и проверьте, что статусы записей позеленели.

Настройка в Mail.ru для бизнеса

1. В панели biz.mail.ru добавьте домен и подтвердите владение способом, который предложит панель.
2. SPF: TXT-запись для @ со значением v=spf1 include:_spf.mxcorp.ru ~all.
3. DKIM: панель выдаст публичный ключ. Создайте TXT-запись с именем mailru._domainkey и значением вида v=DKIM1; k=rsa; p=....
4. DMARC: так же, как для Яндекса, — запись _dmarc со значением v=DMARC1; p=none; rua=mailto:postmaster@вашдомен.ru.
5. Дождитесь обновления DNS и проверьте статусы в панели.

Если пишете с двух платформ: как собрать SPF

SPF-запись у домена может быть только одна. Две TXT-записи с v=spf1 ломают проверку обе. Если отправляете и с Яндекса, и с Mail.ru (плюс, скажем, сайт шлёт заявки со своего сервера), все сервисы перечисляются в одной строке:

v=spf1 include:_spf.yandex.net include:_spf.mxcorp.ru ~all

Правила простые: каждый отправляющий сервис добавляется через include, запись заканчивается мягким запретом ~all, а суммарное число DNS-запросов в цепочке include не должно превышать десяти — перебор ломает SPF так же надёжно, как его отсутствие.

Нюансы российских DNS-хостеров

• Имя записи. reg.ru, Selectel и DNS Яндекс Облака просят только поддомен: mail._domainkey, _dmarc, @. Часть панелей (старые интерфейсы Timeweb, хостеры на ISPmanager) ждёт полное имя с точкой на конце: mail._domainkey.вашдомен.ru. Посмотрите, как оформлены существующие записи домена, и сделайте так же.
• TTL. На время настройки ставьте 3600 секунд или меньше — тогда ошибку можно исправить без суток ожидания. Обновление записей занимает от 15 минут до 24 часов.
• Длинный ключ. Некоторые панели режут TXT длиннее 255 символов. Вставляйте ключ одной строкой без кавычек; если панель сама разбила значение на части — это нормально, DNS склеит их обратно.
• Перенос домена. Смена регистратора или DNS-провайдера часто сбрасывает записи на шаблонные. После любого переезда проверяйте весь набор заново — это самая частая причина «вчера всё работало».

Как проверить, что всё встало

• Посмотрите записи командой dig TXT вашдомен.ru, dig TXT mail._domainkey.вашдомен.ru, dig TXT _dmarc.вашдомен.ru — или любым онлайн-чекером DNS.
• Отправьте тестовое письмо на ящики в Mail.ru и Gmail, откройте исходник письма и найдите строку Authentication-Results: там должно быть spf=pass, dkim=pass, dmarc=pass.
• Прогоните письмо через почтовый тестер (например, mail-tester.com): он покажет и состояние записей, и грубые проблемы самого письма.

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

Где обычно ломается

• Две SPF-записи у одного домена — проверка падает в обеих.
• Опечатка в имени: dmarc вместо _dmarc, dkim._domainkey вместо mail._domainkey — запись существует, но сервер её не находит.
• DMARC сразу в p=reject: любая неправильно настроенная система (сайт, CRM, бухгалтерия) начнёт терять письма. Начинайте с p=none.
• Записи внесены не у того хостера: NS домена делегированы в одно место, а редактируете зону в другом. Частая история после смены регистратора.
• Старый SPF после переезда почты: домен переехал с Яндекса на Mail.ru, а запись осталась прежней.

Частые вопросы

Нужны ли эти записи, если отправляем по 50 писем в день?

Да. Формальные требования Google и Yahoo к массовым отправителям, а фильтры Яндекса и Mail.ru смотрят на наличие записей при любом объёме. Три записи вносятся один раз за вечер — это самый дешёвый пункт всей настройки доставляемости.

Можно ли обойтись SPF без DKIM?

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

Что ставить в DMARC сначала: none, quarantine или reject?

Начинайте с p=none и адресом для отчётов. Пара недель покажет, все ли ваши легальные отправители — сайт, CRM, сервис рассылок — проходят проверки. Затем p=quarantine, и только убедившись, что своих писем в отказах нет, — p=reject.

У нас и Яндекс 360, и Mail.ru — как быть с SPF?

Одной общей записью: v=spf1 include:_spf.yandex.net include:_spf.mxcorp.ru ~all. DKIM при этом у каждой платформы свой, и обе записи спокойно соседствуют — у них разные имена хоста.

Записи настроены, а письма всё равно в спаме. Что не так?

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

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