DMARC внедрение: как настроить без потери писем

1. Что делают политики none, quarantine и reject

DMARC - это TXT-запись в DNS на хосте _dmarc.вашдомен. Она говорит принимающему серверу, что делать с письмом, которое не прошло проверку DMARC: не выровнен ни SPF, ни DKIM с доменом в From. Политика задается тегом p= и принимает три значения.

Частый вопрос: p=none - это ошибка? Нет, если это осознанный первый этап. p=none ошибкой становится, когда запись висит в таком виде месяцами: домен не защищен от подделки, а отчеты никто не читает. С февраля 2024 года Gmail и Yahoo требуют от отправителей более 5000 писем в день DMARC-запись минимум с p=none вместе с действующими SPF и DKIM, и p=none это требование формально закрывает, но для защиты репутации и антиспуфинга нужен переход к quarantine и reject.

Пример минимальной записи на первом этапе:

2. Что должно быть готово до внедрения

DMARC опирается на SPF и DKIM. До публикации записи проверьте: SPF опубликован одной записью и не превышает лимит DNS-lookups, DKIM подписывают все сервисы отправки, и хотя бы один из механизмов выровнен с доменом в From. Выравнивание (alignment) означает, что домен в SPF (Return-Path) или домен d= в DKIM-подписи совпадает с доменом From. Подробности разбора alignment - в статье про DMARC alignment.

Составьте полный список источников почты домена: основной ESP рассылок, транзакционный сервис, корпоративная почта (Google Workspace, Яндекс 360, Exchange), CRM, биллинг, сервис-деск, формы на сайте. Каждый источник, который не подписывает DKIM вашим доменом и отправляет со своего Return-Path, кандидат на DMARC fail.

3. Шаг 1: p=none и сбор отчетов

Опубликуйте запись с p=none и адресом rua для агрегированных отчетов. Принимающие системы (Gmail, Mail.ru, Yahoo, Microsoft и другие) начнут присылать XML-отчеты о том, какие IP отправляют от вашего домена и как проходят проверки.

Отчеты обычно приходят раз в сутки, формат - zip с XML внутри, но точная периодичность и задержка зависят от конкретной принимающей стороны (Gmail, Yandex, Mail.ru, Microsoft шлют не по одному и тому же расписанию). Читать их вручную неудобно, поэтому rua-адрес обычно указывают на сервис обработки. PostmastersTool принимает DMARC-отчеты и агрегирует их по источникам, так что вы видите список IP и сервисов, а не сырой XML. Разбор формата отчетов - в статье про DMARC aggregate XML.

Держите p=none минимум две недели, лучше месяц: редкие потоки (ежемесячные счета, парольные ресеты из старых систем) всплывают не сразу. За этот срок зафиксируйте три группы источников: проходят DMARC (хорошо), не проходят, но легитимные (чинить), не проходят и не ваши (это и есть спуфинг, ради него все и делается).

4. Шаг 2: чиним легитимные источники

Типовые причины DMARC fail у легитимных сервисов: ESP не настроен на DKIM-подпись вашим доменом (в кабинете ESP включается отдельно, обычно добавлением CNAME или TXT-записей с селектором), корпоративная почта подписывает доменом провайдера, а не вашим, на сайте стоит скрипт отправки без DKIM и с Return-Path хостера.

Для ESP порядок действий одинаковый: в настройках домена отправителя включить DKIM для вашего домена, опубликовать выданные DNS-записи, дождаться валидации в кабинете, отправить тест и проверить подпись. Для корпоративной почты: Google Workspace и Яндекс 360 позволяют включить DKIM для домена в админ-панели, Microsoft 365 - через настройку DKIM в Defender (подписание доменом организации включается отдельно).

Проверяйте результат по письмам: отправьте тест на Gmail и Mail.ru, откройте оригинал письма и посмотрите строки Authentication-Results. Нужны spf=pass и dkim=pass с доменом вашего From, плюс dmarc=pass. Быстрее всего разобрать заголовки анализатором: /tools/email-header-analyzer разбирает письмо прямо в браузере.

5. Шаг 3: переход на quarantine через pct

Когда в отчетах не осталось легитимных источников с fail, переходите на quarantine. Чтобы не рисковать всем трафиком сразу, используйте тег pct (percentage): он задает долю писем, к которым применяется политика. Запись v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.ru означает: карантин применяется примерно к 25% писем, не прошедших DMARC, остальные обрабатываются как при none.

Схема безопасного повышения: p=quarantine; pct=25 на неделю, затем pct=50, затем pct=100, затем снять pct. После каждого шага смотрите отчеты и жалобы: если у получателей начали пропадать нужные письма (падают во входящие в спам), возвращайтесь на шаг назад и ищите источник.

Нюанс: поддержка pct - рекомендация, а не гарантия, часть получателей может применять политику ко всему трафику независимо от значения pct. Поэтому даже с pct=25 держите канал обратной связи: почта постмастера, мониторинг жалоб.

Отдельно учтите: действующий стандарт DMARC (RFC 9989, весна 2026 года, заменил исходный RFC 7489) исключил тег pct из спецификации, вместо него описан тег t с двумя значениями - тестовый режим либо обычная работа, без деления по проценту трафика. Крупные почтовые службы пока не отказались от pct: актуальная инструкция Microsoft по внедрению DMARC для доменов Microsoft 365 по-прежнему описывает именно постепенный подъем pct 10-25-50-75-100. Поэтому шаг с pct остается рабочим способом внедрения, но не гарантирован на уровне протокола на годы вперед.

6. Шаг 4: reject и DMARC для поддоменов

После стабильной работы quarantine без жалоб переходите на p=reject. Письма, не прошедшие DMARC, будут отклоняться на SMTP-сессии, и вы увидите это в логах отправки как отказы (если откажется легитимный поток - вы узнаете сразу по баунсам, а не по тихому спаму).

Поддомены наследуют политику основного домена по умолчанию. Тег sp задает отдельную политику для поддоменов: v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.ru защитит основной домен, но оставит поддомены в режиме наблюдения. Это удобно, если поддомены (news.example.ru, billing.example.ru) настраиваются позже или находятся в ведении другой команды.

Отдельную запись на поддомене (_dmarc.news.example.ru) можно опубликовать и без sp: она переопределяет и p, и sp основного домена для этого поддомена. Практическое правило: пока поддомен не разобран, держите на нем p=none с rua, потом проходите тот же путь quarantine - reject. Разделение потоков по поддоменам - тема статьи про поддомены и потоки email.

7. Как проверить результат

Техническая проверка записи: dig TXT _dmarc.example.ru +short должен вернуть ровно одну запись, начинающуюся с v=DMARC1. Если записей две и обе валидны, стандарт предписывает получателю отбросить обе: домен останется без DMARC-политики вообще.

Проверка поведения: отправьте письмо с сервиса, который заведомо не пройдет DMARC (например, telnet-отправка с чужого IP с подменой From, или любой тестовый спуфинг-инструмент). При p=reject письмо должно быть отклонено, при quarantine - попасть в спам. Легитимные письма при этом должны показывать dmarc=pass в заголовках.

Дальше мониторинг: DMARC-отчеты продолжают приходить и после reject, и это нормально: там видны попытки спуфинга и новые сервисы, которые коллеги подключили, не предупредив. Пороговые уведомления в PostmastersTool приходят в Telegram или на почту, так что всплеск DMARC fail вы увидите в тот же день, а не при плановой ревизии.

Параллельно следите за репутационными метриками: доля жалоб в Google Postmaster Tools и Mail.ru Postmaster. Жесткая политика сама по себе репутацию не поднимает, но убирает спуфинговый трафик, который ее портит.

8. Типичные ошибки внедрения

Первая: p=none без rua. Запись есть, отчетов нет, внедрение мертво. Вторая: сразу p=reject по требованию безопасников без этапа наблюдения, и через день падают счета из биллинга или письма с формы сайта. Третья: забытый поддомен, от которого идут транзакционные письма, без собственной записи он попадает под sp или p основного домена.

Четвертая: опечатка в rua (несуществующий ящик, ящик в чужом домене без подтверждающей записи external verification). Пятая: запись опубликована не на том хосте - пропущено подчеркивание (dmarc.example.ru вместо _dmarc.example.ru), либо панель регистратора сама подставляет имя домена к введенному хосту, и запись задваивается (_dmarc.example.ru.example.ru). Шестая: после смены ESP старый сервис продолжает отправлять триггеры, которые теперь падают по DMARC. Поэтому смена ESP - это отдельный аудит потоков.

Если DMARC проходит, а письма все равно в спаме, причина не в аутентификации: смотрите жалобы, контент и репутацию. Это разбирается в статье SPF, DKIM и DMARC проходят, но письмо в спаме.