Настройка SPF и DKIM для отправляющего домена: инструкция по шагам

SPF и DKIM — это две DNS-записи, без которых Gmail, Яндекс и Mail.ru отправляют деловые письма в спам независимо от их содержания. Настройка занимает от получаса до пары часов, делается один раз и не требует навыков администрирования — только доступ к DNS-панели домена. Ниже — пошаговая инструкция с примерами записей, способами проверки и разбором ошибок, которые встречаются чаще всего.

Что понадобится до начала

Для настройки нужны три вещи: доступ к управлению DNS-записями домена (панель регистратора или DNS-хостинга — reg.ru, Timeweb, Cloudflare и т.п.), список всех сервисов, которые отправляют почту с этого домена (корпоративная почта, CRM, сервис отправки), и полчаса-час времени. Если DNS домена управляет подрядчик — достаточно передать ему готовые записи из этой инструкции.

Сначала определитесь с доменом отправки. Для холодного B2B-аутрича стандарт — не трогать основной домен компании, а завести отдельный домен (company-team.ru вместо company.ru) или поддомен (mail.company.ru). Логика простая: репутация отправителя живёт на уровне домена, и эксперименты с холодным каналом не должны рисковать доставляемостью основной корпоративной переписки — счетов, договоров, писем клиентам.

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

Шаг 1. Составляем SPF-запись

SPF-запись — это TXT-запись в DNS домена, которая начинается с v=spf1 и перечисляет разрешённые источники отправки. Источники задаются механизмами: include:домен подтягивает список серверов стороннего сервиса, ip4: и ip6: указывают конкретные адреса ваших серверов, mx разрешает серверы из MX-записей домена. Завершается запись квалификатором для всех остальных: ~all (мягкий отказ — чужие письма помечать подозрительными) или -all (жёсткий — отклонять).

Значения include публикует ваш почтовый сервис в своей документации. Типовые примеры: для Яндекс 360 — include:_spf.yandex.net, для Google Workspace — include:_spf.google.com, для Mail.ru для бизнеса — include:_spf.mail.ru. Если письма дополнительно уходят с собственного сервера, добавьте его адрес через ip4:.

Собранную запись публикуете в DNS: тип — TXT, имя — @ (для поддомена — имя поддомена, например mail), значение — сама строка. TTL можно оставить по умолчанию. Критично: SPF-запись на домене должна быть ровно одна. Если запись уже существует — не добавляйте вторую, а объедините источники в одной строке.

Шаг 2. Генерируем и публикуем DKIM

DKIM устроен иначе: ключи генерирует не регистратор, а почтовый сервис, который отправляет письма. В панели администратора почты (Яндекс 360, Google Workspace, VK WorkSpace или ваш собственный сервер) найдите раздел DKIM: сервис создаст пару ключей и покажет, какую запись опубликовать. Закрытый ключ останется у сервиса и будет подписывать каждое исходящее письмо, открытый — вы кладёте в DNS.

Запись DKIM публикуется с именем вида селектор._domainkey, где селектор задаёт сервис (например, mail._domainkey или google._domainkey). Тип записи — TXT (иногда CNAME на запись сервиса), значение — строка с открытым ключом вида v=DKIM1; k=rsa; p=MIGfMA0GCSq… Длинный ключ — это нормально: некоторые панели требуют разбить строку на части, следуйте их подсказкам.

После публикации вернитесь в панель почтового сервиса и нажмите «Проверить» или «Включить DKIM» — сервис убедится, что запись видна, и начнёт подписывать письма. Учтите задержку распространения DNS: обычно записи подхватываются за 15–60 минут, в худшем случае — до суток. Если сервисов отправки несколько, DKIM настраивается для каждого со своим селектором — они спокойно сосуществуют на одном домене.

Шаг 3. Проверяем, что всё работает

Самая надёжная проверка — боевая. Отправьте письмо с настроенного домена на ящик Gmail, откройте его, меню «ещё» → «Показать оригинал». В верхней части будет таблица с вердиктами: SPF: PASS с указанием IP, DKIM: PASS с доменом подписи, DMARC — если настроен. Аналогично в Яндекс.Почте: «Свойства письма» покажут служебные заголовки с результатами Authentication-Results.

На что смотреть в вердиктах. SPF должен быть pass, а домен в проверке — совпадать с вашим доменом отправки. DKIM должен быть pass, и важно, чтобы подпись стояла именно вашим доменом (d=company-team.ru), а не техническим доменом сервиса-посредника — иначе с точки зрения DMARC подпись «не ваша» и выравнивание не сойдётся.

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

• Тестовое письмо на Gmail: SPF и DKIM — pass в «Показать оригинал»
• DKIM-подпись стоит вашим доменом (параметр d= в заголовке), а не доменом сервиса
• SPF-запись одна, синтаксис валиден, DNS-обращений не больше 10
• Тест на Яндекс и Mail.ru: вердикты в служебных заголовках тоже pass
• Через 24 часа проверка повторена — DNS точно разошёлся

Типичные ошибки настройки

Ошибка номер один — две SPF-записи на одном домене. Так бывает, когда новый сервис подключали, не глядя на существующие записи: провайдеры в этом случае считают конфигурацию невалидной, и проверку не проходит ни одна запись. Лечится объединением: все include и ip4 собираются в одну строку с одним v=spf1 в начале и одним all в конце.

Ошибка номер два — превышение лимита в 10 DNS-обращений. Каждый include сам может содержать вложенные include, и запись, годами обраставшая сервисами, однажды перестаёт проходить проверку с ошибкой permerror. Лечится ревизией: удалите include сервисов, которыми больше не пользуетесь, а IP-адреса собственных серверов указывайте напрямую через ip4: — это обращений не тратит.

Ошибка номер три — считать, что настройки сервиса достаточно. Если DKIM включён в панели сервиса, но запись в DNS не опубликована или опубликована с опечаткой в селекторе, подписи невалидны, и вы узнаете об этом по просевшей доставляемости. Всегда завершайте настройку боевой проверкой через Gmail. Четвёртая ошибка — забыть про поддомен: записи основного домена не распространяются на поддомен отправки автоматически, у mail.company.ru должен быть собственный SPF и свой DKIM.

Что дальше: DMARC, прогрев и режим отправки

SPF и DKIM — фундамент, но для полной картины не хватает третьей записи — DMARC. Она связывает первые две проверки с видимым адресом отправителя и говорит провайдерам, что делать с письмами, не прошедшими аутентификацию. Начните с мягкой политики p=none с адресом для отчётов и ужесточайте после пары чистых недель — подробная настройка DMARC описана в отдельном гайде.

Свежий домен с корректными записями — ещё не готовый к работе домен. У него нет истории отправки, и резкий старт с десятков писем в день провайдеры воспринимают настороженно. Стандартная практика адресного аутрича — прогрев 2–4 недели: сначала единичные письма с ответами и нормальной перепиской, затем плавный рост до рабочих 20–50 писем в день с ящика.

В LDM проверка SPF, DKIM и DMARC для домена отправки встроена в подготовку кампании: платформа не даст запустить рассылку по собранному сегменту, если DNS-записи не в порядке — потому что терять тщательно подобранных ЛПР из-за технической мелочи обиднее всего. Но и без платформы правило то же: сначала DNS-записи и проверка, потом база и письма.

• Опубликовать DMARC с p=none и адресом для отчётов
• Прогреть домен 2–4 недели до боевых объёмов
• Держать режим 20–50 писем в день с одного ящика
• Пересматривать SPF при каждом подключении нового сервиса отправки
• Раз в квартал делать ревизию DNS-записей и повторную проверку

Вопросы и ответы