SPF, DKIM и DMARC для холодных писем: практический чек-лист настройки

Почему холодные письма проваливаются при неправильной DNS-аутентификации

Почтовая аутентификация — это способ, которым почтовый ящик проверяет, действительно ли ваше сообщение разрешено отправляться от имени домена. Речь не о том, как лучше написать текст. Речь о подтверждении личности.

Когда вы отправляете холодное письмо, принимающий сервер смотрит на домен в поле From и выполняет три основных проверки:

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

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

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

Часто причиной становятся мелкие ошибки. Две отдельные SPF TXT-записи могут привести к ошибке. DKIM-ключ с одной пропущенной буквой не пройдет валидацию. DMARC, выставленный в агрессивную политику до выравнивания всего, может заблокировать нормальную отправку.

Этот чек-лист фокусируется на SPF, DKIM и DMARC в практическом плане: что публиковать, чего избегать и как проверить результат до масштабирования отправок. Он не покрывает копирайтинг, качество списков, соответствие локальным правилам или релевантность предложения.

Простая модель: что проверяется при отправке

Когда вы отправляете холодное письмо, обычно участвуют два домена, и их смешивание вызывает много путаницы.

Домен отправителя — это тот, что видит получатель в поле From ([email protected]). Домен почтового ящика (иногда другой) — это домен, который фактически отправляет сообщение за кулисами, например выделенный поддомен для отправки или домен провайдера. Для хорошей доставляемости эти домены должны быть согласованными или хотя бы явно связанными.

От From до входящих: три проверки

Большинство почтовых сервисов следуют одной и той же общей логике:

1. SPF проверяет скрытый Return-Path (его ещё называют envelope sender) и спрашивает, разрешён ли этот сервер отправлять от имени этого домена.
2. DKIM проверяет DKIM-подпись и спрашивает, совпадает ли домен, которым подписали сообщение.
3. DMARC смотрит на видимый From-домен и проверяет, выровнены ли SPF и/или DKIM с ним, затем применяет вашу политику.

Выравнивание, без жаргона

Выравнивание — это просто «совпадают ли домены?» Смотреть нужно в трёх местах:

• From: что видят люди (пример: @yourdomain.com)
• Return-Path: что использует SPF (может быть @mail.yourdomain.com или другой)
• DKIM d=: домен, который подписал сообщение (пример: d=yourdomain.com)

DMARC проходит, когда From-домен выровнен с SPF (домена Return-Path) и/или с DKIM (d= домен). Всё не обязано быть идентичным, но должно быть осознанным.

Что происходит, когда проверки не проходят

Провайдеры реагируют не одинаково, но исходы предсказуемы:

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

Даже до строгого DMARC повторяющиеся провалы со временем снижают попадание в основной ящик.

Пример: вы отправляете с [email protected], но SPF авторизует другой домен, а DKIM подписывает как d=anotherdomain.com. Сообщение может выглядеть «неродным», и фильтры относятся к нему осторожно.

Подготовка до правок в DNS: настройтесь на чистую установку

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

Сначала решите, какой домен будет в поле From. Многие команды используют отдельный домен отправки (или поддомен), чтобы основной корпоративный домен не был под угрозой, если что-то пойдёт не так.

Затем выберите, как вы получите точные значения записей. Ваш почтовый провайдер даст конкретное значение SPF, имена и ключи DKIM-селекторов и рекомендованную DMARC-запись. Не догадывайтесь и не копируйте записи с другого домена.

Перед изменениями подтвердите четыре базовых вещи: какой точный From-домен вы будете использовать, какие провайдеры будут отправлять почту, где управляется DNS и у кого есть права публиковать TXT и CNAME записи.

Также убедитесь, что вы в правильной панели управления. Часто домен покупают в одном месте, DNS хостят в другом, а записи правят не там. Если не уверены, проверьте, какие nameserver использует домен, и залогиньтесь в провайдера, который ими управляет.

Простой план изменений помогает избежать «полезных» правок, которые ломают существующую почту. Как правило, сначала вы аккуратно обновите SPF, добавите DKIM и опубликуете DMARC в режиме мониторинга. Оставляйте MX, A и веб-записи без изменения, если вы точно не знаете, зачем их трогать.

SPF: добавьте нужных отправителей и избегайте лимита запросов

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

Хорошая SPF-запись — это небольшой белый список, покрывающий все места, которые могут отправлять от вашего домена: ваш инструмент для холодных писем, Google Workspace или Microsoft 365 (если вы их используете), и любые CRM или служебные инструменты, которые отправляют письма от вашего имени.

Что включить в SPF-запись

Большинству новых доменов нужно лишь несколько элементов:

• include: когда провайдер просит включить их SPF. Держите include минимальным — они считаются DNS-запросами.
• ip4:/ip6:: когда у вас есть фиксированный IP отправки. Это избегает дополнительных запросов, но работает только при действительно стабильных IP.
• a и mx: только если ваш собственный сервер домена или почтовый обменник отправляет почту напрямую (многие настройки для холодных рассылок этого не требуют).

Вот пример чистой формы (ваши значения будут другими):

v=spf1 include:YOUR-SENDER-SPF ip4:203.0.113.10 ~all

Выберите правильный окончательный флаг: -all или ~all

Последняя часть — это правило по умолчанию для любого несоответствующего источника.

~all (soft fail) — более безопасный старт, пока вы тестируете и могли пропустить отправителя. -all (hard fail) лучше, когда вы уверены, потому что однозначно говорит провайдерам отвергать неавторизованных отправителей.

Для нового исходящего домена начните с ~all во время настройки и ранних отправок, затем переходите на -all, когда убедитесь, что ничего легитимного не падает.

Держитеся в пределах лимита из 10 запросов

SPF имеет жёсткий лимит в 10 DNS-запросов. Слишком много include может сломать SPF и тихо навредить доставляемости.

Чтобы не превысить лимит, держите include в минимуме, избегайте вложенных цепочек include, удаляйте старые инструменты, которыми вы больше не пользуетесь, и публикуйте ровно одну SPF TXT-запись для домена. Несколько SPF-записей приводят к permerror.

DKIM: публикуйте ключи корректно и держите селекторы в порядке

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

Как работают селекторы (и почему их имена важны)

DKIM-селектор — это метка, указывающая на конкретный публичный ключ. Система подписывает письма с этим селектором, а получатель ищет DNS-запись по адресу:

selector._domainkey.yourdomain.com

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

Простой подход — применить стабильный, понятный селектор, например s1, mail или 2026q1, и менять его осознанно при необходимости.

TXT vs CNAME: что вы увидите в DNS

Некоторые провайдеры публикуют DKIM как TXT-запись с полным ключом. Другие дают CNAME, указывающий на хостированную запись с ключом. Оба варианта работают, если вы публикуете ровно то, что ожидает ваш провайдер.

Наиболее частые проблемы с DKIM просты: неверный тип записи (TXT vs CNAME), лишние кавычки или скрытые переносы строк, вставлена только часть ключа, запись размещена не на selector._domainkey, или остались старые селекторы с конфликтующими записями.

Если DKIM не проходит проверку, не пускайтесь в догадки. Скопируйте значение заново у провайдера, опубликуйте его аккуратно и протестируйте после обновления DNS.

DMARC: начните с мониторинга, затем ужесточайте политику

DMARC — это слой «что делать получателю при сбоях». SPF и DKIM говорят Gmail или Outlook, что проверить. DMARC даёт понятную политику (none, quarantine, reject) и требует выравнивания с видимым From-доменом.

Практичный способ начать — с мониторинга. Опубликуйте DMARC с p=none, чтобы видеть, что проходит и что нет, без риска падения доставляемости из-за слишком строгой политики. Пусть это работает несколько дней при небольших объёмах отправки, затем ужесточайте шаг за шагом.

Вот безопасный стартовый шаблон записи (отредактируйте адреса и домен):

_dmarc.example.com TXT \"v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100; fo=1\"

Держите опции простыми. Жёсткое выравнивание (adkim=s и aspf=s) — хороший дефолт для выделенных исходящих доменов, где вы контролируете отправку. pct=100 обеспечивает последовательное поведение. fo=1 разумно, чтобы получать отчёты при сбоях.

Будьте аккуратны с адресами для отчётов. Аггрегированные отчёты (rua) полезны только если кто-то их анализирует. Форенсик-отчёты (ruf) часто блокируются и создают вопросы приватности и шума, поэтому обычно их лучше пропустить.

Пошагово: аутентификация абсолютно нового домена отправки

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

1) Сначала очистите зону DNS

В панели управления DNS найдите существующие TXT-записи, связанные с SPF, DKIM или DMARC. У новых доменов иногда есть стартовые записи, старые тесты или дубликаты от предыдущих попыток. Удалите то, что не узнаёте, и убедитесь, что для корневого домена осталась только одна SPF TXT-запись.

2) Добавляйте аутентификацию в безопасном порядке

Добавляйте по одному типу записи и проверяйте видимость перед переходом к следующему:

1. SPF: опубликуйте единую SPF TXT-запись, которая включает только сервисы, которые будут отправлять почту от этого домена.
2. DKIM: добавьте DKIM-записи, которые даёт ваш отправитель (часто это CNAME, иногда TXT). Убедитесь, что селектор совпадает с тем, что настроен в вашей системе отправки.
3. DMARC: опубликуйте DMARC TXT-запись в _dmarc.yourdomain с p=none вначале.

3) Подождите, затем ещё раз проверьте точные значения

DNS-изменения не всегда мгновенны. После публикации записей перепроверьте, что действительно видно в зоне. Подтвердите, что SPF одна, DKIM совпадает точно и DMARC опубликован на _dmarc поддомене.

4) Отправьте реальные письма и проверьте «pass» в заголовках

Отправьте пару простых писем (без вложений и тяжёлого HTML) на аккаунты, которыми вы управляете: Gmail, Outlook. Откройте детали сообщения и найдите Authentication-Results. Вам нужны spf=pass, dkim=pass и dmarc=pass.

Если SPF падает, обычно это неправильный include или две SPF-записи. Если DKIM не проходит — скорее всего несоответствие селектора или опечатка в DNS. Когда получите стабильные проходы, переходите к разогреву и осторожному увеличению объёмов.

Типичные ошибки в DNS, которые тихо вредят попаданию в почту

Большинство проблем с новым доменом не драматичны. Это мелкие детали DNS, которые позволяют письмам уходить, но снижают доверие к вам.

Два частых вопроса:

Во-первых, публикация двух SPF-записей для одного домена. Для домена должна быть ровно одна SPF TXT-запись. Если вам нужны Google и ещё один инструмент, объедините всё в одну запись v=spf1 и оставьте один завершающий флаг (~all или -all).

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

С DKIM самая распространённая проблема — несоответствие селектора. Провайдер подписывает с определённым селектором (например, s1 или default). Если в DNS опубликован другой селектор, приёмник не сможет проверить подпись, даже если запись есть.

DMARC часто сбивает с толку, потому что SPF может проходить, а DMARC всё равно падает. DMARC требует выравнивания с видимым From-доменом. Если вы отправляете с [email protected], а Return-Path — brand-mail.com и DKIM подписывает как d=brand-mail.com, возможно, SPF покажет pass, а DMARC — fail.

Быстрый чек-лист: финальная 10-минутная проверка

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

Убедитесь, что на корневом домене ровно одна SPF TXT-запись. Убедитесь, что DKIM опубликован для домена, с которого вы отправляете, и селектор совпадает с тем, что использует ваш инструмент отправки. Убедитесь, что на _dmarc.example.com есть ровно одна DMARC-запись и что она начинается с p=none.

Если вы только что изменили записи — подождите. Многие «не проходит» ситуации связаны с кэшированием DNS.

Затем отправьте тестовое письмо на почтовый ящик, который вы можете проверить, и проверьте Authentication-Results: вам нужны spf=pass, dkim=pass и dmarc=pass.

Быстрые исправления при сбоях:

• SPF падает: неправильный include, неверный домен (корень vs поддомен) или две SPF-записи.
• DKIM падает: несоответствие селектора, лишние пробелы/кавычки или отключённая подпись.
• DMARC падает: DMARC отсутствует, опубликован не на _dmarc, или SPF/DKIM не выровнены с From-доменом.

Пример и дальнейшие шаги для нового домена холодной рассылки

Простая настройка: вы покупаете свежий домен только для исходящей почты и создаёте несколько почтовых ящиков (alex@, sam@, info@). Основной корпоративный домен держите отдельно, чтобы ошибка не повлияла на повседневную почту.

Реалистичный временной план:

• День 0: опубликовать SPF, DKIM и DMARC в режиме мониторинга (p=none).
• День 1: отправить тестовые письма и подтвердить, что SPF/DKIM/DMARC проходят. Исправить опечатки и неверные хосты.
• Дни 2–3: начать с очень малого объёма, пока идёт разогрев.
• Конец первой недели: просмотреть DMARC-отчёты и bounce-логи, устранить несоответствия.
• Неделя 2+: при стабильности перейти на p=quarantine, а затем — на p=reject.

Если вы видите SPF=pass, но DMARC=fail, обычно это значит, что нарушено выравнивание, а не что DNS полностью неверен. Быстрое решение часто — включить DKIM и убедиться, что подпись идёт от домена, совпадающего с тем, который вы используете в From, потому что выравнивание по DKIM обычно устойчивее, чем по SPF при смене инструментов.

После того как аутентификация настроена, результаты зависят от поведения, а не от записей. Разогревайте домен медленно, держите ранний объём низким, документируйте изменения DNS, не меняйте провайдеров в первый месяц и внимательно следите за bounce и отписками.

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