DNS-записи почтового домена: MX, SPF, DKIM, DMARC на пальцах

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

Зачем разбираться в DNS, если этим обычно занимается технарь

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

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

MX-запись: куда приходит почта на этот домен

MX (Mail Exchange) — запись, которая указывает, какой почтовый сервер отвечает за приём входящей почты на домен. Без корректной MX-записи домен физически не может получать письма — любое сообщение, отправленное на адрес такого домена, вернётся отправителю с ошибкой доставки.

Для холодной рассылки MX важен не потому, что вы отправляете письма — отправка технически возможна и без него, — а потому, что на холодные письма приходят ответы. Если MX не настроен или настроен неверно, ответы заинтересованных ЛПР будут теряться, и вся эффективность кампании обнулится на этапе получения обратной связи.

SPF: список разрешённых отправителей

SPF (Sender Policy Framework) — текстовая запись в DNS, которая перечисляет, каким серверам разрешено отправлять почту от имени этого домена. Когда письмо приходит на сервер получателя, тот проверяет IP-адрес отправителя против списка в SPF-записи домена — и если IP не совпадает ни с одним разрешённым, письмо помечается как подозрительное.

Без SPF любой сервер в мире технически может отправить письмо, представившись вашим доменом, и получатель не сможет отличить легитимное письмо от подделки. Именно поэтому отсутствие SPF — один из первых сигналов, который снижает доверие к домену у большинства почтовых провайдеров.

Практическая ловушка: если для отправки используется несколько сервисов одновременно (например, транспортная почта компании плюс отдельный сервис для холодных рассылок), нужно перечислить все их адреса в одной SPF-записи — две отдельные SPF-записи на одном домене не работают, DNS-стандарт признаёт только одну.

DKIM: цифровая подпись письма

DKIM (DomainKeys Identified Mail) добавляет к письму криптографическую подпись, которую сервер получателя проверяет по открытому ключу, опубликованному в DNS-записи домена. Если подпись совпадает — письмо гарантированно не было изменено в пути и действительно отправлено с сервера, у которого есть закрытый ключ этого домена.

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

Настройка DKIM обычно происходит через сервис отправки: он генерирует пару ключей и просит добавить публичный ключ в DNS как TXT-запись с определённым селектором — именем, которое идентифицирует конкретную конфигурацию подписи.

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

DMARC: политика и отчётность поверх SPF и DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) — запись, которая говорит серверам получателей, что делать с письмом, если оно провалило проверку SPF или DKIM: пропустить как есть (none), отправить в спам (quarantine) или отклонить полностью (reject). Кроме того, DMARC настраивает отправку отчётов владельцу домена о том, кто и как часто пытается отправлять письма от его имени.

Частая ошибка — настроить DMARC с политикой none и на этом остановиться. Политика none собирает отчёты, но никак не защищает домен: письма, не прошедшие проверку, всё равно доставляются как обычно. Реальная защита начинается с quarantine, а полноценная — с reject, но переходить к строгим политикам стоит только после того, как SPF и DKIM отлажены и подтверждено, что легитимная почта их проходит стабильно.

Для нового домена, который только готовится к рассылкам, разумная последовательность: сначала DMARC с политикой none и наблюдением за отчётами несколько недель, затем переход на quarantine, и только при полной уверенности в конфигурации — на reject.

• p=none — только собирает отчёты, не влияет на доставку писем, проваливших проверку
• p=quarantine — письма, не прошедшие проверку, отправляются в спам получателя
• p=reject — письма, не прошедшие проверку, отклоняются полностью, до почтового ящика не доходят

Частые ошибки в настройке DNS для холодных рассылок

Большинство проблем с доставляемостью, которые списывают на «плохой текст письма» или «жадный спам-фильтр», на деле оказываются ошибками именно в этих записях.

• Две SPF-записи на одном домене вместо одной объединённой — стандарт DNS это не поддерживает, и проверка ломается непредсказуемо
• DKIM настроен для одного сервиса отправки, а письма фактически идут через другой — подпись не совпадает
• DMARC оставлен на p=none навсегда — отчёты собираются, но защиты и репутационного эффекта нет
• Отправка холодных рассылок с основного корпоративного домена, используемого для внутренней переписки — при проблеме с репутацией страдает вся почта компании, а не только рассылка
• Изменение DNS-записей без ожидания их полного распространения (TTL) — проверка проводится раньше, чем изменения реально вступили в силу, и создаёт ложное впечатление ошибки

Как проверить, что всё настроено верно, и что делать под холодную рассылку

Перед первой отправкой стоит проверить все четыре записи через один из бесплатных онлайн-инструментов проверки DNS для почты — они за несколько секунд показывают, находит ли внешний сервер корректные MX, SPF, DKIM и DMARC записи домена, и явно указывают на противоречия вроде двух SPF-записей.

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

После настройки записей важно дать время на прогрев: домен и IP, с которых уходят письма, должны нарастить объём отправки постепенно, а не начинать с сотен писем в первый же день — почтовые провайдеры оценивают репутацию не только по DNS-записям, но и по истории поведения отправителя.

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

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