Отсутствующая или неправильно настроенная DMARC-запись оставляет ваш домен открытым для спуфинга почты - злоумышленники могут рассылать фишинг, который выглядит как письма с вашего адреса, и ничто их не блокирует. Однако публикация политики p=reject без предварительной проверки настроек SPF и DKIM может заблокировать вашу собственную легитимную почту. Это руководство охватывает корректную проверку DMARC-записи, значение каждого тега, инструменты, которые находят ошибки до того, как они вызовут проблемы, и безопасный путь от мониторинга к полному принудительному режиму.
Что такое DMARC-запись?
DMARC расшифровывается как Domain-based Message Authentication, Reporting, and Conformance. Это DNS TXT-запись, опубликованная на `_dmarc.yourdomain.com`, которая указывает принимающим почтовым серверам, что делать, когда письмо, якобы отправленное с вашего домена, не проходит проверки аутентификации. Без DMARC любой может отправлять письма, которые выглядят как исходящие с вашего домена - техника, называемая спуфингом домена, используемая в фишинговых атаках и атаках Business Email Compromise.
DMARC-запись делает две вещи: задаёт политику (какое действие применять к непрошедшим проверку письмам) и настраивает отчётность (куда отправлять сводки результатов аутентификации). Политика может быть `none` (только мониторинг, без действий), `quarantine` (доставка в спам) или `reject` (полная блокировка письма). Теги отчётности указывают адреса, на которые крупные почтовые провайдеры ежедневно отправляют XML-агрегированные отчёты.
Структура DMARC-записи
# Запись только для мониторинга (безопасная отправная точка)
v=DMARC1; p=none; rua=mailto:[email protected]
# Карантин с частичным внедрением и форензик-отчётами
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r
# Полный reject - используйте только после подтверждения прохождения всеми отправителями
v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s- v=DMARC1: Тег версии - обязателен, должен быть первым, ровно в таком виде.
- p=: Политика для домена - `none`, `quarantine` или `reject`.
- sp=: Политика для поддоменов - переопределяет p= для поддоменов, если задана.
- rua=: Адрес агрегированных отчётов - mailto:-URI (или URI сервиса отчётности).
- ruf=: Адрес форензик-отчётов - отдельные отчёты о сбоях (реже, есть нюансы приватности).
- pct=: Процент писем, к которым применяется политика - полезно для поэтапного развёртывания (1-100).
- adkim=: Режим выравнивания DKIM - `r` (relaxed) или `s` (strict).
- aspf=: Режим выравнивания SPF - `r` (relaxed) или `s` (strict).
Note
Как DMARC работает со SPF и DKIM
DMARC сам по себе не аутентифицирует почту - это слой оркестрации поверх SPF и DKIM. Когда принимающий почтовый сервер получает письмо, якобы из вашего домена, он проверяет две вещи: прошло ли письмо SPF или DKIM и выравнивается ли аутентифицированный домен с доменом из заголовка From. Если хотя бы один прошёл и выровнялся - DMARC пройден. Если ни один не прошёл с выравниванием, принимающий сервер применяет политику из вашей DMARC-записи.
Аутентификация и выравнивание SPF
SPF (Sender Policy Framework) определяет, каким почтовым серверам разрешено отправлять письма от имени вашего домена. Проверка выполняется по отправителю SMTP-конверта (адресу `MAIL FROM`), а не по видимому заголовку From. Для выравнивания DMARC домен в `MAIL FROM` должен совпадать с доменом заголовка From (или быть его поддоменом в relaxed-режиме). Когда вы отправляете через сторонний сервис вроде Mailchimp или SendGrid, их домен return-path часто `mailchimp.com` - это ломает выравнивание SPF, если не настроить кастомный поддомен return-path. Используйте SPF Record Validator, чтобы проверить SPF-запись на синтаксические ошибки и превышение лимита lookup-ов, прежде чем полагаться на неё для выравнивания DMARC.
Аутентификация и выравнивание DKIM
DKIM (DomainKeys Identified Mail) добавляет к исходящим письмам криптографическую подпись. Подпись включает тег `d=`, указывающий подписывающий домен. Для выравнивания DMARC домен `d=` должен совпадать с доменом заголовка From (или быть его поддоменом в relaxed-режиме). Выравнивание DKIM надёжнее для сторонних отправителей, потому что их можно настроить подписывать вашим доменом, а не своим. DKIM Record Validator проверяет, что DNS-запись открытого ключа для данного селектора корректно отформатирована и доступна.
| Аутентификация | Что проверяет | Цель выравнивания | Проверка Aback Tools |
|---|---|---|---|
| SPF | Какие серверы могут отправлять для домена | Домен MAIL FROM vs заголовок From | SPF Record Validator |
| DKIM | Криптографическая подпись письма | Домен тега d= vs заголовок From | DKIM Record Validator |
| DMARC | Оркестрация политики + выравнивания | Требует выравнивания SPF или DKIM | DMARC Record Validator |
Чтобы пройти аутентификацию DMARC, письма должны быть аутентифицированы SPF или DKIM, а аутентифицирующий домен должен выравниваться с доменом в заголовке From.
Warning
Как проверить свою DMARC-запись
Проверка DMARC-записи требует трёх вещей: что DNS-запись существует и доступна, что синтаксис корректен и что SPF и DKIM настроены так, чтобы поддерживать выравнивание, от которого зависит DMARC. Каждый шаг быстро выполняется подходящими инструментами.
Посмотрите текущую DMARC-запись
В терминале выполните `dig TXT _dmarc.yourdomain.com` (Linux/macOS) или `nslookup -type=TXT _dmarc.yourdomain.com` (Windows). Вывод должен содержать TXT-запись, начинающуюся с `v=DMARC1`. Если результата нет - DMARC-запись не опубликована. Если видите перенаправление или ошибку, проверьте, что запрашивали `_dmarc.yourdomain.com` с ведущим подчёркиванием.
Проверьте синтаксис с DMARC Record Validator
Скопируйте исходное значение DMARC-записи (всё после типа записи TXT в ответе DNS) и вставьте в DMARC Record Validator. Инструмент проверяет, что `v=DMARC1` идёт первым, что `p=` присутствует с допустимым значением, что все URI `rua=` и `ruf=` корректно отформатированы, а значения процентов и выравнивания находятся в допустимых диапазонах. Ошибки сообщаются с указанием конкретного тега, вызвавшего сбой.
Проверьте SPF и DKIM по отдельности
Используйте SPF Record Validator, чтобы проверить SPF-запись на лимит lookup-ов (максимум 10 DNS lookup-ов - превышение вызывает permerror в SPF), синтаксические ошибки и отсутствующие механизмы. Используйте DKIM Record Validator с вашим селектором и доменом, чтобы убедиться, что запись открытого ключа корректно опубликована. DMARC силён ровно настолько, насколько сильны поддерживающие его записи SPF и DKIM.
Спланируйте поэтапное внедрение
Используйте DMARC Policy Rollout Planner, чтобы составить безопасный график перехода от `p=none` к `p=quarantine` и `p=reject`. Планировщик учитывает текущие показатели прохождения аутентификации и предлагает поэтапную прогрессию pct=, минимизирующую риск блокировки легитимной почты во время перехода.
DMARC Record Validator
Проверяйте DNS-записи DMARC на синтаксические ошибки, недопустимые значения политики и отсутствующие обязательные теги - локально в браузере с диагностикой по каждому тегу.
Частые ошибки DMARC и их исправление
Большинство проблем проверки DMARC попадают в предсказуемые категории. Многие - простые синтаксические ошибки, которые валидатор находит сразу; другие - более тонкие проблемы конфигурации, требующие понимания выравнивания для корректной диагностики.
Синтаксические ошибки и ошибки тегов
- v=DMARC1 отсутствует как первый тег: Тег версии должен быть первым полем. Если другой тег стоит раньше, запись недействительна.
- Отсутствует тег p=: Тег политики обязателен. Запись без p= некорректна и большинством почтовых серверов игнорируется.
- Недопустимое значение p=: Допустимы только `none`, `quarantine` и `reject`. Любое другое значение (например, `monitor`) приводит к отклонению записи.
- Отсутствуют точки с запятой между тегами: Теги должны разделяться точками с запятой. Пропущенный разделитель заставляет парсер слить два тега в один недопустимый.
- Пробелы вокруг знаков =: `p = none` (с пробелами) недопустимо в некоторых парсерах. Используйте `p=none` без пробелов.
- Неверный формат URI в rua=: Значение rua= должно быть корректным `mailto:`-URI. Голый адрес без `mailto:` - синтаксическая ошибка.
Ошибки выравнивания и аутентификации
Ошибки выравнивания диагностировать сложнее, чем синтаксические, потому что требуют понимания почтовых заголовков. Самый частый сценарий: вы настроили SPF корректно для прямой отправки с собственного почтового сервера, но когда письма уходят через стороннюю маркетинговую платформу, `MAIL FROM` использует домен платформы - выравнивание SPF ломается. Решение - либо настроить подпись DKIM своим доменом на сторонней платформе, либо завести кастомный поддомен return-path, который отображается на ваш домен.
| Ошибка | Симптом | Причина | Исправление |
|---|---|---|---|
| Нет DMARC-записи | dig не возвращает TXT-запись | Запись не опубликована | Создайте TXT на _dmarc.yourdomain.com |
| Неверное место в DNS | Запись игнорируется серверами | Отсутствует префикс _dmarc. | Опубликуйте на _dmarc.yourdomain.com |
| Отсутствует тег p= | Запись считается недействительной | Пропущен обязательный тег | Добавьте p=none, p=quarantine или p=reject |
| Сбой выравнивания SPF | DMARC падает для сторонних отправителей | Домен MAIL FROM не совпадает | Настройте кастомный поддомен return-path |
| Сбой выравнивания DKIM | DMARC падает несмотря на валидный DKIM | Домен d= не совпадает | Настройте подпись DKIM своим доменом |
| Превышен лимит lookup SPF | permerror в SPF, DMARC падает | Более 10 DNS lookup-ов | Используйте SPF Flatten Checker для консолидации |
| pct= вне диапазона | Валидатор сообщает об ошибке | Значение не от 1 до 100 | Задайте pct= целым числом от 1 до 100 |
Tip
Переход от none к принудительному режиму
Самая частая ошибка при внедрении DMARC - установка `p=reject` до подтверждения, что все легитимные почтовые потоки корректно аутентифицируются. Письма от забытых сервисов отправки - транзакционные платформы, CRM, тикет-системы, интеграции с партнёрами - будут блокироваться незаметно, и отправитель может не заметить, пока не получит жалобы или пока пользователи не сообщат о пропавших письмах.
Развёртывание в три фазы
Безопасное развёртывание DMARC следует трём фазам. В фазе 1 (недели 1-4) публикуется `p=none` с адресом отчётов `rua=`, и агрегированные отчёты анализируются, чтобы выявить все источники отправки и их показатели прохождения. В фазе 2 (недели 5-10) происходит переход на `p=quarantine; pct=10` с постепенным увеличением `pct=`, пока отчёты подтверждают рост показателей - старт с 10% означает, что в карантин попадает лишь 10% непрошедших писем, ограничивая радиус воздействия. В фазе 3 (с 11-й недели) переход на `p=reject`, когда все легитимные отправители стабильно проходят, а агрегированные отчёты показывают минимальные или нулевые сбои аутентификации от легитимных источников.
На что смотреть в агрегированных отчётах
Агрегированные отчёты показывают каждый источник, отправлявший письма якобы с вашего домена. Ищите собственные почтовые серверы, провайдеров почтовых сервисов и всех авторизованных сторонних отправителей - у всех должны быть высокие показатели прохождения и SPF, и DKIM. Любой источник со значительным объёмом и низкими показателями требует разбирательства: либо это легитимный отправитель, которому нужно починить аутентификацию, либо неавторизованный, которого должен блокировать принудительный режим. DMARC Policy Rollout Planner помогает интерпретировать эти сигналы и выбирать подходящий момент для каждого перехода между фазами.
Warning
Отчётность и мониторинг DMARC
Отчётность DMARC - это петля обратной связи, которая делает принудительный режим безопасным. Без агрегированных отчётов вы действуете вслепую - невозможно узнать, какие источники проходят или проваливают аутентификацию, или не сломало ли что-то недавнее изменение почтовой инфраструктуры. Правильная настройка отчётности так же важна, как и самой политики.
Агрегированные отчёты (rua=)
Тег `rua=` задаёт `mailto:`-URI, на который каждый крупный почтовый провайдер (Google, Microsoft, Yahoo и др.), обрабатывающий почту вашего домена, ежедневно отправляет XML-агрегированные отчёты. Каждый отчёт - сжатый XML-файл с количеством писем, IP источников, результатами SPF/DKIM/DMARC и применённой политикой. Адрес получателя должен быть в том же домене, что и DMARC-запись, либо это междоменный URI с записью разрешения, опубликованной в домене стороннего сервиса. Большинство организаций используют специализированный сервис отчётности DMARC вместо прямого почтового ящика, потому что сырые XML-отчёты требуют инструментов разбора.
Форензик-отчёты (ruf=)
Тег `ruf=` настраивает форензик-отчёты (отчёты о сбоях) - отдельные копии писем, не прошедших DMARC. Они содержат больше деталей, чем агрегированные, но имеют нюансы приватности: могут включать почтовые заголовки, а некоторые провайдеры прекратили их отправку из-за GDPR. Большинство практиков DMARC используют только `rua=` для агрегированных данных и опускают `ruf=`, если не нужен форензик-анализ конкретных сбоев.
Сторонние сервисы отчётности DMARC
- Google Postmaster Tools: Бесплатная панель с репутацией вашего домена и показателями прохождения аутентификации с точки зрения Gmail.
- Postmark DMARC: Бесплатный парсер агрегированных отчётов с визуальной панелью - хорош для старта без платного сервиса.
- Dmarcian: Комплексная платная платформа с анализом по источникам, оповещениями о проблемах аутентификации и помощью в развёртывании.
- Valimail: DMARC-платформа корпоративного уровня с автоматизированными рекомендациями по внедрению на основе анализа отчётов.
- EasyDMARC: Платформа мониторинга и управления DMARC для среднего бизнеса с практическими инсайтами по каждому источнику отправки.
Лучшие практики DMARC
Следование этим практикам гарантирует, что внедрение DMARC даёт реальную защиту без помех для легитимной почты, а конфигурация остаётся корректной по мере развития вашей инфраструктуры отправки.
Всегда проверяйте весь стек почтовой аутентификации
DMARC-запись эффективна ровно настолько, насколько эффективны поддерживающие её записи SPF и DKIM. Проверяйте все три вместе: DMARC Record Validator - для записи политики, SPF Record Validator - для синтаксиса механизмов и лимита в 10 lookup-ов, DKIM Record Validator - чтобы убедиться, что открытый ключ корректно опубликован для каждого используемого селектора. Повторяйте проверку всех трёх после любых изменений почтовой инфраструктуры - новый сервис отправки, миграция домена или продление SSL-сертификата могут повлиять на публикацию ключей DKIM.
Используйте relaxed-выравнивание во время перехода
Режим выравнивания по умолчанию и для SPF, и для DKIM - relaxed (`adkim=r; aspf=r`), который позволяет поддоменам удовлетворять выравниванию для родительского домена. Это правильная настройка на время развёртывания, потому что многие легитимные отправители используют поддомены вашего домена для аутентификации. Переходите на strict-выравнивание (`adkim=s; aspf=s`) только при конкретном требовании безопасности и после подтверждения, что все отправители используют точное совпадение домена - strict-выравнивание с единственным неправильно настроенным отправителем ломает DMARC для каждого его письма.
- Начинайте с p=none, никогда с p=reject: Сначала наберите доверие к показателям прохождения аутентификации, потом включайте принудительный режим.
- Настройте rua= прежде всего остального: Без данных агрегированных отчётов невозможно принимать обоснованные решения по политике.
- Проверьте планировщик селекторов DKIM: Используйте DKIM Selector Planning Helper при ротации ключей DKIM, чтобы избежать ошибок наложения.
- Используйте pct= для поэтапного внедрения: Начинайте с pct=10 при переходе на quarantine или reject - это ограничивает последствия в случае ошибки конфигурации.
- Перепроверяйте после смены почтовой платформы: Добавление нового маркетингового инструмента, CRM или тикет-системы обычно требует обновления SPF и настройки DKIM.
- Следите за распространением DNS: После публикации или изменения DMARC-записи используйте DNS Propagation ETA Estimator, чтобы знать, когда изменение станет видно глобально.
DMARC Policy Rollout Planner
Планируйте поэтапный переход DMARC от none к quarantine и reject с пошаговым графиком на основе ваших данных аутентификации.
Key takeaways
- DMARC надстраивается над SPF и DKIM - он задаёт политику для непрошедших проверку писем и требует, чтобы хотя бы один из SPF или DKIM выравнивался с доменом заголовка From.
- Проверяйте весь стек: используйте вместе DMARC Record Validator, SPF Record Validator и DKIM Record Validator.
- Самые частые ошибки - отсутствие тега `p=`, недопустимые значения политики, неверное место в DNS (нет префикса `_dmarc.`) и сбои выравнивания SPF/DKIM у сторонних отправителей.
- Не прыгайте сразу на `p=reject` - начните с `p=none`, анализируйте агрегированные отчёты 2-4 недели, затем постепенно переходите к quarantine и reject с помощью `pct=`.
- Требования Google и Yahoo к массовым отправителям 2024 года предписывают DMARC уровня `p=none` и выше для отправителей свыше 5 000 писем в день - но реально блокирует спуфинг только `p=reject`.
- Настройте агрегированную отчётность `rua=` с первого дня - без данных о том, какие источники проходят и проваливают аутентификацию, безопасные решения о внедрении невозможны.
- Используйте DMARC Policy Rollout Planner, чтобы построить безопасный поэтапный путь от мониторинга к полному принудительному режиму.