Гайд по политике DMARC: от none до reject за 4 шага

DMARC (Domain-based Message Authentication, Reporting, and Conformance) — это слой политики, связывающий SPF и DKIM и говорящий принимающим серверам, что делать, когда сообщение не проходит аутентификацию. Без DMARC mailbox-провайдер может молча пропустить, отправить в карантин или отклонить неаутентифицированное письмо по своим внутренним правилам. С DMARC вы явно задаёте политику обработки для своего домена.

Этот гайд проводит через весь процесс внедрения DMARC — от публикации первой record-only-monitoring до полного enforcement с политикой reject.

Почему DMARC важен#

Email-спуфинг остаётся одним из самых частых векторов атак. Атакующий может подделать заголовок «From», чтобы письмо выглядело как с вашего домена. Без DMARC принимающие серверы не имеют надёжного способа понять ваше намерение по обработке таких сообщений.

DMARC решает три задачи:

• Предотвращение фишинга: останавливает атакующих, отправляющих письма, выглядящие как с вашего домена.
• Защита бренда: не даёт использовать ваш домен в мошеннических кампаниях, бьющих по репутации.
• Видимость: DMARC-отчёты показывают, кто именно шлёт письма с вашего домена — включая легитимные сервисы, о которых вы могли забыть, и несанкционированных отправителей, о которых вы не знали.

Крупные mailbox-провайдеры — Google, Microsoft, Yahoo — теперь требуют DMARC от bulk-отправителей. С 2024 года Google требует DMARC-политику у доменов, отправляющих более 5 000 писем в день на адреса Gmail.

Как DMARC работает с SPF и DKIM#

DMARC не делает собственных проверок аутентификации. Он оценивает результаты SPF и DKIM и применяет дополнительное требование — выравнивание (alignment).

Требование выравнивания

Чтобы DMARC прошёл, должно выполняться хотя бы одно из:

1. SPF проходит И SPF-аутентифицированный домен выравнен с доменом из «From». SPF проверяет envelope sender (Return-Path). DMARC требует, чтобы этот домен совпадал (или был субдоменом) домена в видимом «From».

2. DKIM проходит И подписавший DKIM домен (тег d=) выравнен с доменом из «From». Домен в DKIM-подписи должен совпадать (или быть субдоменом) домена «From».

Выравнивание может быть strict (точное совпадение домена) или relaxed (субдомены допускаются). Relaxed — по умолчанию, и это работает для большинства конфигураций.

Почему выравнивание важно

Без выравнивания атакующий мог бы настроить SPF и DKIM для attacker.com, отправить сообщение с From: ceo@yourcompany.com, и письмо прошло бы SPF и DKIM (для attacker.com), но получатель видит ваш домен. DMARC-выравнивание закрывает эту дыру, требуя совпадения аутентифицированного домена с тем, что видит пользователь.

Синтаксис DMARC-записи#

DMARC-запись — это DNS TXT-запись, опубликованная по адресу _dmarc.yourdomain.com. Полный пример:

v=DMARC1; p=reject; rua=mailto:dmarc-agg@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; aspf=r; adkim=r; fo=1;

Справочник тегов

Тег	Обязателен	Описание	Значения
v	Да	Версия протокола	Всегда DMARC1
p	Да	Политика для домена	none, quarantine, reject
rua	Нет*	Получатели агрегированных отчётов	URI mailto:
ruf	Нет	Получатели forensic-отчётов	URI mailto:
pct	Нет	Процент сообщений, к которым применяется политика	1–100 (по умолчанию: 100)
aspf	Нет	Режим SPF-выравнивания	r (relaxed, по умолчанию) или s (strict)
adkim	Нет	Режим DKIM-выравнивания	r (relaxed, по умолчанию) или s (strict)
sp	Нет	Политика для субдоменов	none, quarantine, reject
fo	Нет	Опции отчётов о сбоях	0, 1, d, s

*Хотя rua технически опционален, его всегда стоит указывать. Без агрегированных отчётов вы публикуете политику вслепую — без возможности увидеть, что происходит.

Объяснение значений политики

• none: только мониторинг. Сообщения, не прошедшие DMARC, доставляются как обычно. Вы получаете отчёты с результатами аутентификации, но никаких действий не предпринимается. Это стартовая точка.
• quarantine: сообщения, не прошедшие DMARC, считаются подозрительными. Обычно попадают в спам/junk-папку получателя.
• reject: сообщения, не прошедшие DMARC, отклоняются. Принимающий сервер возвращает ошибку, и письмо не доставляется.

Опции отчётов о сбоях (тег fo)#

• 0 (по умолчанию): отчёт генерируется, только если SPF и DKIM оба провалили выравнивание.
• 1: отчёт генерируется, если SPF или DKIM провалил выравнивание. Полезнее для отладки и рекомендуется.
• d: отчёт, если DKIM провалился независимо от выравнивания.
• s: отчёт, если SPF провалился независимо от выравнивания.

Прогрессия из 4 шагов до полного enforcement#

Прыгать сразу в p=reject без подготовки опасно. Можно заблокировать легитимные письма от сервисов, о которых забыли. Безопасный подход — постепенная прогрессия.

Шаг 1: Деплой с p=none (мониторинг)#

Начните с monitoring-only политики, чтобы собрать данные без влияния на доставку.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Что делать на этом этапе:

• Опубликуйте запись и подождите минимум 2–4 недели, чтобы накопилось достаточно данных в отчётах.
• Просматривайте агрегированные отчёты, чтобы выявить все легитимные источники писем для домена. Это включает основной почтовый сервер, маркетинговые платформы (Mailchimp, SendGrid, HubSpot), транзакционные сервисы, CRM, тикет-системы и любые SaaS-инструменты, шлющие письма от вашего имени.
• Для каждого легитимного источника убедитесь, что SPF настроен (включите IP сервиса в SPF-запись) и DKIM настроен (опубликуйте DKIM-ключ сервиса в DNS).
• Расследуйте источники, которых не узнаёте. Это могут быть либо забытые легитимные сервисы, либо несанкционированные отправители.

Длительность: минимум 2–4 недели. Дольше при сложной отправляющей инфраструктуре.

Шаг 2: Перейдите на p=quarantine 25% (мягкий enforcement)#

Когда вы уверены, что все легитимные источники проходят DMARC, начните enforcement на небольшой части трафика.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Это говорит принимающим серверам отправлять в карантин (обычно — в спам) 25% сообщений, не прошедших DMARC. Остальные 75% обрабатываются как при политике none.

Что делать на этом этапе:

• Внимательно следите за отчётами на рост сбоев DMARC от легитимных источников.
• Если найдёте новый легитимный отправитель без SPF или DKIM — исправьте конфигурацию до перехода дальше.
• Следите за отчётами о попадании легитимной почты в спам.
• Если через 1–2 недели всё чисто — переходите к следующему шагу.

Длительность: 1–2 недели.

Шаг 3: Увеличьте до p=quarantine 100% (полный карантин)#

Уберите ограничение по проценту, чтобы карантин применялся ко всем не прошедшим сообщениям.

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Или просто опустите тег pct, поскольку 100 — значение по умолчанию:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Что делать на этом этапе:

• Продолжайте мониторить отчёты.
• Убедитесь, что легитимная почта не попадает в карантин.
• Сообщите команде, чтобы сообщали, если кто-то не получает письма.
• После 2–4 недель без проблем — готовы к финальному шагу.

Длительность: 2–4 недели.

Шаг 4: Включите p=reject (полная защита)#

Это финальное состояние. Сообщения, не прошедшие DMARC, отклоняются полностью.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1;

На этом этапе любая попытка отправить письмо с вашего домена без правильной аутентификации будет отклонена. Ваш домен полностью защищён от спуфинга.

Постоянное сопровождение:

• Продолжайте просматривать агрегированные отчёты минимум раз в месяц.
• При добавлении нового сервиса для отправки писем настраивайте SPF и DKIM до отправки.
• Периодически ротируйте DKIM-ключи и проверяйте, что новые проходят DMARC.
• Подумайте о добавлении ruf для forensic-отчётов, если ваш ящик переваривает объём.

Чтение DMARC-отчётов#

Агрегированные отчёты (rua)#

Агрегированные отчёты — это XML-файлы, ежедневно отправляемые принимающими серверами. Они содержат:

• Имя организации сервера-репортёра.
• Период покрытия.
• Вашу опубликованную DMARC-политику.
• Для каждого источника IP, отправлявшего письма с вашего домена: число сообщений, результаты SPF/DKIM/DMARC и итог выравнивания.

Упрощённый фрагмент отчёта:

<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>1542</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

Сырой XML тяжело читать в масштабе. Большинство организаций используют сервис анализа DMARC-отчётов или инструмент, который парсит и визуализирует данные. Помогут сервисы вроде бесплатного DMARC-мониторинга от Postmark, dmarcian или EasyDMARC.

Forensic-отчёты (ruf)#

Forensic-отчёты содержат детали отдельных сообщений, не прошедших DMARC, включая заголовки и иногда часть содержимого. Полезны для расследования конкретных инцидентов спуфинга, но генерируют большие объёмы и могут содержать чувствительную информацию. Многие получатели больше не шлют forensic-отчёты из соображений приватности.

Частые ловушки DMARC#

1. Публикация p=reject без предварительного мониторинга#

Самая опасная ошибка. Если хоть один легитимный сервис не настроен правильно с SPF и DKIM, его письма будут отклонены. Всегда начинайте с p=none и просматривайте отчёты.

2. Забыли о сторонних отправителях#

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

• Платформы маркетинговой автоматизации
• Тикет-системы саппорта
• CRM, шлющие письма от вашего имени
• ПО для счетов и бухгалтерии
• HR- и рекрутинговые инструменты
• Календари и планировщики

Проверьте каждый сервис, привязанный к домену, до перехода с p=none.

3. SPF превышает 10 DNS-запросов#

У SPF жёсткий лимит — 10 механизмов DNS-запросов (include, a, mx, redirect, exists). Если ваша SPF-запись превышает лимит, оценка SPF возвращает «permerror» — то есть SPF фактически провалился для всех сообщений. Поскольку DMARC требует, чтобы SPF или DKIM прошёл и совпал, permerror у SPF давит сильнее на DKIM.

Если у вас много отправляющих сервисов, рассмотрите flattening SPF-записи или стратегию субдоменов, где разные сервисы шлют с разных субдоменов.

4. Не используете rua#

Без агрегированных отчётов у вас нет видимости, как аутентифицируются письма с вашего домена. Всегда указывайте тег rua, даже при p=none.

5. Субдомены без тега sp#

По умолчанию, если не задать тег sp, субдомены наследуют политику родительского. Если вы используете субдомены под разные задачи (например, marketing.yourdomain.com), подумайте о явной политике для субдоменов или отдельных DMARC-записях для каждого.

6. Игнорирование DMARC после reject#

DMARC — не «настроил и забыл». Появляются новые сервисы, истекают ключи, меняются SPF-записи. Просматривайте агрегированные отчёты ежемесячно, чтобы ловить регрессии.

Проверка вашей DMARC-конфигурации#

Можно проверить текущую DMARC-запись запросом DNS:

dig TXT _dmarc.yourdomain.com

Для комплексной проверки, оценивающей DMARC вместе с SPF, DKIM, MX-записями и статусом в чёрных списках, используйте бесплатный Email Health Checker от Nova Uptime. Инструмент даёт оценку из 100, буквенный грейд (от A до F) и конкретные рекомендации по улучшению DMARC-политики.

Инструмент оценивает строгость DMARC-политики как часть скоринга. Политика p=reject с агрегированной отчётностью получает высший балл, а p=none или отсутствие записи — заметные вычеты. Это даёт чёткую картину, где ваш домен и какие следующие шаги.

Таймлайн внедрения DMARC#

Реалистичный график полного развёртывания:

Неделя	Действие	DMARC-запись
1	Опубликовать monitoring-запись, настроить обработку отчётов	p=none; rua=mailto:...
2-4	Просмотр отчётов, исправление SPF/DKIM для всех легитимных отправителей	p=none; rua=mailto:...
5-6	Мягкий enforcement 25%	p=quarantine; pct=25; rua=mailto:...
7-8	Полный карантин	p=quarantine; rua=mailto:...
9-12	Полный enforcement	p=reject; rua=mailto:...
Постоянно	Ежемесячный обзор отчётов, поддержание конфигов	p=reject; rua=mailto:...

Для организаций с простой инфраструктурой почты (один основной сервис, один-два маркетинговых инструмента) это можно сжать до 4–6 недель. Для предприятий с десятками отправляющих сервисов — закладывайте 3–6 месяцев.

Главное

• DMARC надстраивается над SPF и DKIM, добавляя enforcement политики и требование выравнивания.
• Всегда начинайте с p=none и агрегированной отчётностью. Никогда не прыгайте сразу в p=reject.
• Используйте тег pct для постепенного увеличения enforcement.
• Просмотрите агрегированные отчёты, чтобы выявить все легитимные источники до enforcement.
• Достичь p=reject — цель, но требует подготовки.
• Продолжайте мониторить после деплоя. DMARC требует постоянного сопровождения.
• Используйте Email Health Checker Nova Uptime, чтобы проверить DMARC-конфигурацию и получить полную оценку email-аутентификации.

Правильно внедрённая DMARC-политика — одна из самых сильных защит для домена. Она предотвращает спуфинг, строит доверие с mailbox-провайдерами и даёт чёткую видимость, кто шлёт письма от вашего имени.

Часто задаваемые вопросы

Что такое DMARC-проверка?#

DMARC-проверка проверяет, есть ли у домена валидная DMARC DNS-запись и оценивает настройки политики. Подтверждает, что синтаксис записи корректен, политика (none/quarantine/reject) настроена правильно, а адреса отчётов работают. Запустите бесплатную DMARC-проверку, чтобы увидеть текущую конфигурацию.

Возможен ли бесплатный мониторинг DMARC?#

Да. Nova Uptime включает мониторинг DMARC как часть email health checker. Он проверяет DMARC-запись вместе со SPF, DKIM и статусом в блэклистах по настраиваемому расписанию и уведомляет, когда что-то меняется. Бесплатный план покрывает до 5 доменов.

Сколько занимает выход на p=reject?#

Для большинства организаций прогрессия от p=none до p=reject занимает 2–4 месяца. Сроки зависят от того, сколько легитимных источников писем нужно идентифицировать и аутентифицировать. Прыгать в reject без анализа DMARC-отчётов — рисковать заблокировать собственную легитимную почту.

Что если поставить DMARC reject без SPF и DKIM?#

Ваши письма будут отклонены принимающими серверами. Enforcement DMARC требует, чтобы хотя бы один из SPF или DKIM прошёл И совпал с доменом «From». Сначала настройте SPF и DKIM, затем прогоните DMARC от none до reject постепенно.

Похожие материалы

• SPF, DKIM и DMARC: полный гайд — как все три протокола работают вместе
• Тест и настройка DMARC — продвинутая настройка DMARC-политики
• Гайд по проверке и удалению из email-блэклистов — что делать, когда сбои аутентификации приводят к листингам
• Чек-лист доставляемости email — 15 шагов к улучшению попадания в инбокс
• Бесплатный Email Health Checker — проверка DMARC, SPF, DKIM и блэклистов одним сканом