DMARC: rua, p=quarantine и p=reject — как включить без потери доставляемости

DMARC — это политика, которая связывает результаты SPF и DKIM с доменом в заголовке From и позволяет почтовым провайдерам применять санкции к письмам, не прошедшим аутентификацию. Правильно включенный DMARC повышает deliverability и защищает бренд от спуфинга. Ключ к безопасному внедрению — агрегированные отчеты rua и поэтапный переход через p=none к p=quarantine и затем p=reject.

Зачем DMARC и что такое rua

DMARC позволяет домену публично заявить, что считать «аутентичным» письмом с этим доменом в From: — с опорой на выравнивание (alignment) DKIM и/или SPF. Итоговая политика (p) подсказывает получателям, что делать с неаутентичными письмами: пропускать (none), помещать в карантин (quarantine) или отклонять (reject). Чтобы управлять рисками, нам нужны данные: откуда приходят письма от имени домена, какие механизмы проходят, где проблемы. Для этого и служат агрегированные отчеты rua.

Агрегированные отчеты DMARC (rua) — это ежедневные (или с заданным интервалом ri) сводки в формате XML, которые провайдеры доставки отправляют на указанные вами адреса. В отчетах вы увидите IP-адреса отправителей, организацию-источник (если известна), количество писем по каждому источнику, результаты SPF/DKIM и сведения об alignment. Это ваш «радар», позволяющий увидеть, где вы не подписываете письма DKIM, где SPF не выравнивается, и какие внешние сервисы отправляют от вашего имени.

Пока вы не анализируете rua, переходить к p=quarantine/p=reject рано: велик риск потерять часть легитимной почты.

Синтаксис rua: без пробелов, с mailto:, несколько адресов — через запятую

Часть ошибок с DMARC начинается с банальной опечатки. Видел и такое: «rua : dmarc@example.com» — это неверно. В DMARC у тега rua знак равенства, а в значении обязательна схема mailto:. Разрешено указывать несколько получателей отчетов — список URI через запятую.

• Правильно: rua=mailto:dmarc@example.com
• Несколько адресов: rua=mailto:dmarc@example.com,mailto:secops@example.net
• Неправильно: rua : dmarc@example.com, rua=dmarc@example.com, rua= dmarc@example.com

Формально спецификация терпимее к пробелам, но практика доставки показывает: лишние пробелы и экзотические пробельные символы иногда ломают парсинг у отдельных получателей. Рекомендация: никаких пробелов вокруг = и после запятых в списке.

Интервал отчетов задается тегом ri в секундах (по умолчанию 86400, то есть раз в сутки). Форензик-отчеты ruf и опция fo для них в проде лучше не включать: они затрагивают контент и метаданные отдельных писем, несут риски приватности и редко дают пользу, превышающую шум. Для оценки покрытия и выравнивания достаточно rua.

Параметры DMARC: краткий справочник

• v — версия, всегда DMARC1.
• p — политика для домена: none, quarantine, reject.
• sp — политика для поддоменов (если не задано, наследует p).
• rua — список mailto: для агрегированных отчетов.
• ri — интервал агрегирования в секундах (по умолчанию 86400).
• adkim — выравнивание DKIM: r (relaxed) или s (strict).
• aspf — выравнивание SPF: r или s.
• pct — процент писем, к которым применяют политику (p), от 0 до 100.
• ruf и fo — адреса и условия форензик-отчетов (используйте с осторожностью).

Где публикуется DMARC

Запись DMARC — это TXT на имени _dmarc.<ваш_домен> в вашей DNS-зоне. Например, для example.com запись создается на узле _dmarc.example.com со значением, начинающимся с v=DMARC1; и далее теги через ;. Если домен еще не зарегистрирован, начните с шага регистрация доменов.

Примеры записей

Мониторинг (этап 1):

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ri=86400; adkim=r; aspf=r"

Карантин (этап 2):

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com; ri=86400; adkim=r; aspf=r"

Полный карантин: pct=100. Переход к отклонению (этап 3):

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:secops@example.net; ri=86400; adkim=s; aspf=s"

Отдельная политика для поддоменов:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com"

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

План безопасного внедрения: от p=none к p=reject

1. Инвентаризация источников рассылок. Соберите список всех систем, отправляющих почту от домена: MTA вашего сайта, CRM, биллинг, сервисы рассылок, тикетницы, форум, CMS-плагины, формы заявок, а также сторонние сервисы (прием платежей, маркетплейсы, календарь, корпоративные календарные приглашения, cloud-хелпдеск и пр.).
2. Включите DMARC в режиме мониторинга. Опубликуйте p=none с корректным rua, убедитесь, что почтовый ящик для отчетов настроен, квоты достаточные, вложения XML принимаются.
3. Проанализируйте отчеты rua 2–4 недели. Отметьте доли прохождения SPF/DKIM, alignment, топ-источники по IP/ASN, географию и объемы. Выявите «серые» источники, где нет DKIM либо From не выравнивается с SPF-доменом. Цель: >= 98% легитимной почты проходит DMARC с DKIM-alignment.
4. Исправьте проблемы. Для каждого источника: включите DKIM-подпись с доменом, совпадающим или подчиненным домену из From (для adkim=r допустим поддомен). Проверьте SPF: домен в MAIL FROM (envelope) должен совпадать/быть поддоменом домена в From при aspf=r. Где возможно — опирайтесь на DKIM, так как SPF ломается при пересылке без SRS.
5. Постепенно ужесточайте политику через pct. Перейдите на p=quarantine; pct=10, затем 25→50→100 с интервалом 7–14 дней, наблюдая по rua, что не появляется нового легитимного трафика, попадающего в карантин.
6. Включите p=reject. Когда карантинная фаза стабильна (2–3 недели без инцидентов), меняйте политику на p=reject. Для поддоменов можно оставить sp=quarantine, если есть мало контролируемые системы.
7. Ужесточите alignment по мере готовности. Начните с adkim=r; aspf=r и позже переходите к adkim=s; aspf=s для более сильной защиты бренда. Делайте это после полного перехода на DKIM на всех источниках.

Как читать и использовать отчеты rua

Каждый провайдер-репортер присылает ZIP/GZIP с XML. Полезные поля: домен From, результаты SPF/DKIM, policy_evaluated (что сделал бы провайдер при текущей политике), IP-адрес отправителя и количество сообщений. Из этого собираем метрики:

• Доля сообщений, прошедших DMARC по DKIM и/или SPF.
• Доля с выравниванием DKIM (желательно основной упор именно на DKIM).
• Топ-источники без DKIM или без выравнивания.
• Динамика инцидентов после изменений в настройках.

Практика: держите отдельный ящик/хранилище для rua, заведите фильтры и автоматический парсер (скрипт или сервис). Минимум — сводка по дням и алерты по новым неизвестным источникам с объемом > N писем в сутки. Если нужен детальный пайплайн и примеры парсинга, посмотрите подробное руководство по разбору DMARC-отчётов.

Внешние адреса в rua и авторизация

Если указываете в rua адрес на чужом домене (например, парсер отчетов стороннего сервиса), некоторые репортеры потребуют авторизацию — специальную TXT-запись на домене получателя. Механика такая: получатель отчетов размещает у себя TXT на виде <ваш_домен>._report._dmarc.<домен_получателя> со значением v=DMARC1 или иным, описанным в документации получателя. Без этой авторизации часть провайдеров просто не будет отправлять отчеты на внешний домен. Проверьте наличие такой поддержки у выбранного сервиса и завершите авторизацию до публикации записи с внешним rua.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Типичные ошибки и как их избежать

• «rua : …» вместо «rua=…». В DMARC теги записываются как ключ=значение. После rua ставьте =, а не :. Сама схема mailto: содержит двоеточие к адресу, но это внутри значения.
• Отсутствует mailto: в значении. Требуется mailto:, иначе часть репортеров проигнорирует тег.
• Лишние пробелы и переносы строк. Старайтесь хранить значение в одной строке и без пробелов внутри списка.
• Случайно включили p=reject без мониторинга. Это самая дорогая ошибка: часть легитимных писем начнет отклоняться, вы узнаете о проблемах от пользователей.
• Ставка только на SPF. SPF ломается при форвардинге без SRS. Делайте опору на DKIM и alignment DKIM.
• Забыли про поддомены. Если рассылка идет с mail.example.com и From: указывает этот поддомен, явно задайте sp=, если политика для поддоменов должна отличаться.
• Не учли сторонние сервисы. Любой внешник (CRM, биллинг, сервис опросов) должен подписывать ваши письма DKIM вашим доменом либо отправлять с собственного домена (white label).

Влияние на deliverability

Включение p=quarantine и затем p=reject обычно повышает доверие к вашему домену у крупных провайдеров: снижается объем спуфинга, уменьшается жалобность. Но до перехода на p=reject убедитесь, что вся ваша легитимная почта проходит DKIM-alignment. Используйте контрольные адреса у разных провайдеров, проверяйте заголовки Authentication-Results, мониторьте рост soft/hard bounce у исходящих очередей, ведите ретроспективу по rua.

Alignment: relaxed vs strict

adkim=r; aspf=r допускают поддомены: подпись selector._domainkey.mail.example.com выровняется с From: user@example.com. Для максимально строгой политики переведите на adkim=s; aspf=s, но только после полной унификации доменов подписи и From у всех источников.

Тонкости пересылки и списков рассылки

Пересылка ломает SPF (меняется IP-адрес), а списки рассылки часто модифицируют письмо, ломая DKIM. Это нормальная проблема экосистемы. Что помогает:

• Опора на DKIM у исходников (не ломается при простом форварде).
• Использование ARC у некоторых хопов может помочь получателю сохранить доверие, но DMARC-оценка все равно идет по правилам выравнивания. См. практику в материале ARC и форвардинг: как не ломать аутентификацию.
• Понимание рисков: при p=reject отдельные редкие сценарии форварда могут отвалиться. Это обычно перекрывается общим выигрышем в безопасности и deliverability.

Практический чек-лист внедрения DMARC с rua

• SPF на домене: актуальные include, без переполнения 10 DNS-запросов.
• DKIM-ключи 2048 бит, уникальные селекторы для каждого источника, ротация раз в 6–12 месяцев.
• From-домен унифицирован и контролируется вами; внешники настроены на подпись вашим доменом.
• Публикация DMARC p=none с rua и рабочим почтовым ящиком для XML.
• Автопарсинг rua: ежедневные дайджесты, алерты по новым источникам и аномалиям.
• Эскалация через p=quarantine с pct ступенями до 100.
• Переход на p=reject, затем (по готовности) adkim=s; aspf=s.
• Периодическая ревизия: новые сервисы, ротация DKIM, контроль SPF.

FAQ по rua и политикам

Можно ли в rua указать обычный почтовый ящик? Да, отчеты придут как вложение XML в архиве. Лучше использовать отдельный ящик и автоматический парсер — отчеты объемные.

Сколько адресов можно указать в rua? Несколько — разделяйте запятыми. Рекомендуется 1–3, чтобы не плодить дубли.

Нужен ли ruf? Обычно нет. Форензик-отчеты шумные, могут содержать чувствительные данные. Для целей внедрения и контроля хватает rua.

Когда переходить на p=reject? Когда по сводкам rua доля легитимной почты, проходящей DKIM-alignment, стабильно >= 98%, а в карантинном режиме инциденты отсутствуют 2–3 недели.

Что делать с внешними адресами rua? Завершить авторизацию у приемщика отчетов (TXT на <ваш_домен>._report._dmarc.<их_домен>), иначе часть провайдеров не будет слать отчеты.

Диагностика и верификация

После изменения записи проверьте, что DNS разошелся, и валидируйте результат почтовым тестом. Из коробки достаточно отправить письма на тестовые ящики разных провайдеров и убедиться по заголовкам Authentication-Results, что SPF/DKIM проходят и есть dmarc=pass. Если отчеты не приходят, проверьте:

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

Если вы держите собственный почтовый стек, удобно тестировать изменения и нагрузку на изолированном облачном VDS перед выкладкой в прод.

Резюме

DMARC — это не «включил и забыл», а процесс: сбор данных через rua, устранение проблем у источников, постепенное ужесточение политики от p=none к p=quarantine и затем p=reject. Следуя плану и внимательно относясь к синтаксису (особенно rua), вы повысите deliverability, защитите бренд от спуфинга и получите управляемость над всей исходящей почтой домена.