DMARC-политика: что это и как она защищает ваш домен

What is a DMARC policy

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a DNS TXT record that tells receiving mail servers what to do with messages failing SPF and DKIM checks. It was designed to solve a specific gap: SPF validates the envelope sender, DKIM validates a cryptographic signature, but neither controls what happens when validation fails, and neither ties results to the From header domain that the recipient actually sees. DMARC closes both gaps.

The core concept is alignment. DMARC requires that the domain passing SPF or DKIM matches the domain in the visible From header. Without alignment, an attacker can pass SPF on their own domain while spoofing yours in From. With DMARC, that trick fails: the provider checks whether the authenticated domain and the From domain are the same (or share a parent domain in relaxed mode).

Three policy levels

The p= tag sets the policy. none is monitoring mode: the provider delivers the message normally but sends aggregate reports to the address specified in rua=. This is where every deployment should start.

quarantine instructs the provider to route unauthenticated messages to the spam folder. reject instructs the provider to refuse them at the SMTP level - the message is never delivered. The progression from none to quarantine to reject is not optional caution; it is how the protocol is intended to be deployed. Skipping straight to reject without monitoring almost always blocks legitimate mail.

Record structure

A DMARC record lives at the _dmarc subdomain. For example.com the DNS entry is _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com".

Key tags beyond v= and p=: sp= sets policy for subdomains separately; pct= applies the policy to a percentage of messages (useful for gradual rollout); adkim= and aspf= set alignment mode to strict (s) or relaxed (r, the default).

Reports

Aggregate reports (rua) arrive as gzipped XML once per day from each provider that processed mail from your domain. They list source IPs, message counts, SPF/DKIM pass rates, and the policy action taken. Tools like Postmark DMARC Digests or dmarcian parse these into readable dashboards. Without rua, you have no visibility into whether the policy is working.

Forensic reports (ruf) include headers of individual failed messages. They are useful for investigating spoofing incidents, but many providers (including Gmail) do not send them.

Как работает DMARC

DMARC - это DNS-запись, которая сообщает принимающим серверам, что делать с письмами, не прошедшими SPF и DKIM. Ключевой механизм - alignment: домен из заголовка From должен совпадать с доменом, прошедшим аутентификацию. Без этого совпадения спамер может пройти SPF на собственном домене, подставив ваш в From.

При получении письма сервер проверяет SPF и DKIM, затем запрашивает DMARC-запись домена из заголовка From. Если хотя бы одна проверка (SPF или DKIM) прошла с корректным alignment, письмо считается аутентифицированным. Если обе провалились - применяется политика из тега p=.

Alignment бывает relaxed (субдомен считается совпадением с родительским доменом) и strict (требуется точное совпадение). По умолчанию используется relaxed, что покрывает стандартный сценарий отправки с субдоменов вроде mail.example.com или news.example.com.

Три режима DMARC-политики

p=none - мониторинг. Письма доставляются как обычно, но провайдеры отправляют агрегированные отчёты на адрес из rua. Этот режим нужен, чтобы увидеть полную картину: какие серверы шлют от вашего имени, какие проходят проверку, какие нет.

p=quarantine - неаутентифицированные письма попадают в спам. Переходить сюда стоит после 2-4 недель в режиме none, когда все легитимные источники корректно настроены. Тег pct= позволяет применять политику постепенно: сначала к 10% писем, затем к 50%, затем к 100%.

p=reject - полный отказ. Провайдер отклоняет письмо на уровне SMTP, оно не попадает ни во входящие, ни в спам. Это конечная цель для любого домена, который хочет защитить себя от подделки. Gmail, Yahoo и Microsoft рекомендуют именно этот режим.

Структура записи

Запись публикуется на субдомене _dmarc.example.com как TXT-запись. Минимальный вариант: v=DMARC1; p=none; rua=mailto:dmarc@example.com.

Теги sp= (политика для субдоменов), pct= (процент охвата), adkim= и aspf= (режим alignment) позволяют тонко настроить поведение. Forensic-отчёты (ruf=) дают детализацию по отдельным провалам, но поддерживаются не всеми провайдерами.

Отчёты и мониторинг

Агрегированные отчёты (rua) приходят раз в сутки в формате XML. Каждый крупный провайдер - Gmail, Outlook, Yahoo, Mail.ru - присылает свой отчёт с данными: IP-адреса отправителей, объём писем, результаты SPF и DKIM, применённое действие.

Без инструмента для парсинга отчётов работать с XML неудобно. Существуют специализированные сервисы, которые превращают XML в таблицы и графики. Главное - не игнорировать отчёты: DMARC без мониторинга - это политика без обратной связи.

Типичные ошибки

Переход на reject без мониторинга. Сторонние сервисы - CRM, helpdesk, транзакционные сервисы - часто отправляют письма с нарушенным alignment. Если включить reject до их исправления, легитимная почта перестанет доставляться.

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

SPF есть, DKIM нет. При пересылке письма envelope sender меняется, SPF alignment ломается. Если DKIM не настроен, DMARC проваливается. Именно DKIM обеспечивает прохождение при пересылке, поскольку подпись привязана к содержимому, а не к IP отправителя.

Забытые субдомены. Без тега sp= политика основного домена наследуется субдоменами. Если на субдомене другой почтовый поток, это может привести к блокировке. Задавайте sp= явно или публикуйте отдельные DMARC-записи для субдоменов.

Требования Gmail и Yahoo с 2024 года

С февраля 2024 года Gmail и Yahoo требуют наличие DMARC-записи (минимум p=none) у массовых отправителей (более 5 000 писем в день). Домен без DMARC рискует тем, что письма будут понижены в приоритете или отклонены. Фактически DMARC перестал быть рекомендацией и стал обязательным условием для коммерческих рассылок.

Влияние на доставляемость

DMARC сам по себе не гарантирует попадание во входящие. Это инструмент защиты домена, а не пропуск в inbox. Но косвенное влияние существенно: домен с p=reject защищён от спуфинга, его репутация не страдает из-за действий злоумышленников, и провайдеры видят, что отправитель контролирует свой почтовый поток.

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