DMARC от none до reject: настройка для домена холодной рассылки

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

Что именно делает DMARC и почему SPF с DKIM недостаточно

У SPF и DKIM есть архитектурная дыра: они проверяют технические домены, которые получатель не видит. SPF валидирует домен из служебного обратного адреса, DKIM — домен подписи, а человек в почтовом клиенте видит только поле From. Мошенник может отправить письмо, которое честно проходит SPF и DKIM по его собственному домену, а в From поставить ваш. Без DMARC формально всё «зелёное».

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

Вторая функция — политика. Запись DMARC говорит получающим серверам, что делать с письмом, провалившим выравнивание: ничего (none), в спам (quarantine) или отклонить (reject). Третья — отчётность: провайдеры ежедневно присылают на указанный вами адрес сводки, кто и с каких IP отправлял письма от имени домена и как прошли проверки. Для владельца домена рассылки это единственный способ увидеть картину целиком.

Синтаксис записи: разбираем по тегам

DMARC-запись — это TXT-запись в DNS с именем _dmarc.ваш-домен. Обязательных тегов два: v=DMARC1 (версия) и p= (политика для писем, проваливших проверку). Остальные — настройки поведения и отчётности. Практически важные: rua= — адрес для агрегированных отчётов; sp= — отдельная политика для поддоменов (по умолчанию наследуют основную); pct= — процент писем, к которым применяется политика, полезен для плавного ужесточения; adkim= и aspf= — строгость выравнивания, где дефолтное relaxed допускает совпадение по организационному домену (mail.company.ru засчитывается для company.ru), а strict требует точного совпадения.

Для абсолютного большинства случаев хватает трёх-четырёх тегов; relaxed-выравнивание трогать не нужно. Есть ещё тег ruf= для детальных отчётов по каждому провалу, но большинство провайдеров их не шлют из соображений приватности — рассчитывать на них не стоит.

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

Шаг 1. Публикуем p=none и собираем отчёты

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

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

Что ищем в отчётах. Первое — все ли легитимные источники проходят выравнивание: если письма из CRM валят SPF и не подписаны DKIM вашим доменом, их нужно чинить до ужесточения политики. Второе — есть ли чужие источники: IP, с которых кто-то шлёт письма «от вас». Небольшой фон спуфинга — норма для любого домена; это как раз то, что политика reject потом отсечёт.

Шаг 2. Ужесточаем: quarantine, затем reject

Когда 2–4 недели отчёты показывают, что все ваши легитимные письма проходят выравнивание, начинается ужесточение. Промежуточная ступень — p=quarantine: провалившие проверку письма отправляются в спам получателя. Осторожный вариант — с параметром pct: запись v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@company.ru применяет карантин к четверти писем, остальные обрабатываются по none. Подняли pct до 50, затем до 100, наблюдая за отчётами и жалобами на недоставку, — и переходите к финалу.

Финальная политика — p=reject: письма, не прошедшие выравнивание, отклоняются на входе, получатель их не видит вовсе. Для выделенного домена холодного аутрича это правильная конечная точка, и достигается она быстро: источников отправки один-два, наводить порядок почти не в чем. Весь путь none → reject на свежем домене занимает три-четыре недели и совмещается с прогревом.

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

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

Ошибка первая — вечное p=none. Запись опубликовали «для галочки», отчёты никто не читает, политика годами остаётся наблюдательной. Такой DMARC почти бесполезен: от подделки домена он не защищает, а провайдеры видят, что политика ни к чему не обязывает. Если запись стоит дольше пары месяцев в none — это не этап, это забытая задача.

Ошибка вторая — reject без разведки, о ней уже говорили: жёсткая политика до анализа отчётов режет собственные легитимные источники. Симптом — «клиенты перестали получать наши счета» через день после настройки. Ошибка третья — кривой синтаксис: опечатка в имени записи (dmarc вместо _dmarc), точка с запятой в неположенном месте, два тега p=. Провайдеры молча игнорируют невалидную запись — проверяйте синтаксис любым публичным DMARC-чекером после публикации.

Ошибка четвёртая — забытые поддомены. Политика основного домена наследуется поддоменами, и если с поддомена шлёт почту отдельный сервис, не прошедший настройку, ужесточение основной записи уронит его письма. Либо чините выравнивание на поддомене, либо задавайте ему отдельную политику тегом sp= или собственной записью _dmarc.поддомен. Ошибка пятая — отчёты на несуществующий ящик: rua указывает на адрес, который никто не завёл, и весь мониторинг уходит в пустоту.

• p=none дольше двух месяцев — политика «для галочки», защиты нет
• p=reject без чтения отчётов — риск зарезать собственные сервисы
• Невалидный синтаксис — запись молча игнорируется, проверяйте чекером
• Поддомены с отдельной отправкой — отдельное внимание и тег sp=
• Ящик для rua-отчётов должен существовать и проверяться
• Две DMARC-записи на домене — невалидны обе

DMARC в контуре холодного аутрича: чек-лист

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

Порядок действий на новом домене отправки: настроить SPF и DKIM, опубликовать DMARC с p=none и отчётами, параллельно вести прогрев, через 2–4 недели чистых отчётов ужесточить до quarantine, ещё через одну-две — до reject. В LDM состояние DMARC, как и остальных записей, проверяется на этапе подготовки кампании — платформа подсветит отсутствующую или невалидную запись до того, как она стоит вам ответов ЛПР.

Дальше DMARC работает фоном: раз в месяц просматривайте отчёты — не появились ли новые источники (подключили сервис и забыли внести в SPF) и не вырос ли фон спуфинга. Пять минут в месяц — вся цена поддержки.

• SPF и DKIM настроены и проходят с выравниванием по домену From
• Опубликована запись _dmarc с p=none и rua на живой ящик
• Отчёты разобраны: все легитимные источники проходят проверку
• Политика ужесточена до quarantine (можно через pct), затем до reject
• Поддомены отправки покрыты собственной политикой или sp=
• Ежемесячный просмотр отчётов внесён в регламент

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