SPF, DKIM, DMARC: как настроить аутентификацию домена перед холодной рассылкой

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

Зачем аутентификация важна именно для холодного аутрича

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

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

Отдельная причина настраивать все три протокола именно перед адресной рассылкой, а не после первых проблем: Gmail и Yahoo с 2024 года требуют аутентификацию как обязательное условие для доменов, которые отправляют больше определённого объёма писем в сутки. Для холодного аутрича, где отправка идёт с нескольких доменов и ящиков одновременно, это правило касается каждого домена в цепочке.

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

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

Типичная запись выглядит так: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Каждый include добавляет доверенный сервис — почтовый провайдер, CRM для рассылок, транзакционный SMTP. Важно перечислить все реальные источники отправки: если письма уходят и через Google Workspace, и через CRM для холодных кампаний, оба должны попасть в запись.

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

У SPF есть жёсткое ограничение на 10 механизмов включения (include, a, mx и другие) — если в организации несколько доменов и сервисов, запись легко превысить, и тогда SPF перестаёт работать полностью, без явной ошибки на стороне отправителя. Это стоит проверять отдельно, особенно если аутрич ведётся с нескольких брендированных поддоменов.

• v= — версия протокола, всегда spf1
• include: — доверенный сервис отправки (почтовый провайдер, CRM, SMTP-релей)
• ~all — мягкий отказ для неразрешённых источников (рекомендуется на старте)
• -all — жёсткий отказ, включать только после проверки, что все источники учтены

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

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

Настройка обычно происходит на стороне сервиса отправки: почтовый провайдер или платформа для рассылок генерирует пару ключей и просит добавить публичный ключ в DNS как TXT-запись вида selector._domainkey.вашдомен.ru. Селектор (имя перед _domainkey) у каждого сервиса свой, поэтому при использовании нескольких инструментов для рассылки в DNS нужно добавить несколько отдельных DKIM-записей с разными селекторами.

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

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

DMARC не заменяет SPF и DKIM, а связывает их и говорит принимающему серверу, что делать с письмом, если проверки не прошли: пропустить как есть (p=none), отправить в спам (p=quarantine) или отклонить полностью (p=reject). Запись добавляется как TXT-запись на поддомене _dmarc.вашдомен.ru.

Для нового домена под аутрич правильная последовательность — начать с p=none и собирать отчёты о том, кто и как отправляет почту от имени домена, две-три недели. Это безопасный режим: он ничего не блокирует, но показывает, есть ли расхождения между SPF/DKIM и реальным потоком писем. После того как отчёты показывают чистую картину, можно переходить на p=quarantine, а затем на p=reject.

Пропуск этого постепенного перехода — частая причина, почему легитимные письма кампании внезапно перестают доходить: если сразу поставить p=reject на домене, где SPF-запись не учитывает все реальные сервисы отправки, часть писем будет отклоняться самим доменом-отправителем ещё до попытки доставки.

Пример рабочей DMARC-записи для начального этапа: v=DMARC1; p=none; rua=mailto:dmarc-reports@вашдомен.ru; pct=100. Адрес в rua — куда будут приходить агрегированные отчёты от почтовых провайдеров о прохождении проверок.

Как проверить настройку перед стартом кампании

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

Практический чек-лист перед первой отправкой: SPF-запись существует и включает все реальные источники, число include не превышает лимит в 10; DKIM-запись опубликована и совпадает с ключом сервиса отправки; DMARC-запись существует хотя бы в режиме p=none; отправка тестового письма на несколько разных провайдеров (Gmail, Yandex, Mail.ru) показывает статус аутентификации pass по всем трём проверкам в заголовках письма.

• SPF: запись существует, включает все реальные сервисы отправки, механизмов включения не больше 10
• DKIM: селектор совпадает с сервисом, публичный ключ опубликован и активен
• DMARC: запись есть хотя бы в режиме p=none, адрес для отчётов указан
• Тестовое письмо на Gmail/Yandex/Mail.ru: во всех трёх — статус pass по SPF, DKIM и DMARC
• Возраст домена и ящика: новый домен нуждается в прогреве параллельно с настройкой аутентификации, а не вместо неё

Типичные ошибки на доменах для холодного аутрича

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

• Несколько SPF-записей на одном домене вместо одной объединённой — по стандарту допустима только одна запись SPF
• DKIM настроен для одного сервиса отправки, а кампании идут ещё и через другой инструмент без своей подписи
• DMARC сразу выставлен в p=reject на домене без прогретой истории — легитимные письма блокируются вместе с потенциально поддельными
• Поддомен для рассылок использует SPF/DKIM основного домена без отдельной настройки — при проблемах страдает репутация всего бренда, а не только поддомена
• Забыли обновить SPF после смены CRM или SMTP-провайдера — старые include остаются, новый источник не добавлен

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