Анализатор DMARC

Вы готовите переход с мониторинга на enforcement и хотите понять, выдержит ли опубликованная запись проверку принимающими серверами. Маркетинг шлёт через CRM, продуктовые письма идут через transactional-провайдера, а финансовый отдел использует локальный relay. Прежде чем поднять `p` с `none` до `quarantine`, DN01 показывает, валидна ли TXT на `_dmarc.example.com` синтаксически, нет ли дублирующих тегов, которые делают запись невалидной, и не ограничен ли enforcement через `pct`. Эта одна DNS-публикация — то, что оценивают миллиарды почтовых ящиков; опечатка в `p=` или вторая лишняя DMARC TXT может ослабить защиту сразу для всех каналов.

Тикеты по доставляемости часто обвиняют DMARC, хотя SPF отдельно проходит. Письмо может иметь корректный SPF и всё равно провалить DMARC, если envelope From, header From и домен подписи DKIM не выравниваются согласно `aspf` и `adkim`. DN01 показывает режимы alignment: при отсутствии тегов анализатор считает relaxed (`r`) и предупреждает, что получатели могут принимать более широкие совпадения доменов, чем вы ожидаете. Сопоставьте результат DMARC с DKIM Validator, чтобы увидеть активные селекторы, и с DNS Checker для проверки SPF includes.

Команды безопасности используют DMARC как антиспуфинговый контроль для доменов руководства, партнёрских порталов и похожих брендов. Если `_dmarc` отсутствует, DN01 возвращает явную диагностику — `no DMARC record found at _dmarc.<domain>` — и рекомендует опубликовать `v=DMARC1` со стартовой политикой. Это не сбой инструмента, а то же состояние, которое видят получатели, когда фишинг может использовать ваш домен без published rejection policy. Зафиксируйте находку, включите мониторинг с `rua`, затем планируйте enforcement после агрегированных отчётов.

MSP-провайдеры проводят DMARC-ревью десятков клиентских зон при онбординге или продлении контракта. Ручные `dig`-запросы плохо масштабируются, когда нужно сравнить `sp` с `p`, проверить почтовые ящики отчётов и найти невалидный `pct` по портфелю. DN01 возвращает единообразный отчёт с длительностью запроса, инвентарём тегов и рекомендациями для тикетов. SEO-страница результата по домену даёт стейкхолдерам стабильную ссылку на текущую публикацию без доступа к внутренним DNS-инструментам.

Архитектуры с множеством поддоменов — `news.example.com`, `billing.example.com`, `eu.example.com` — зависят от `sp=`, когда дочерние зоны отправляют почту со своими SPF и DKIM. Если `sp` нет, получатели используют `p` для поддоменов, что удивляет команды, считавшие зону изолированной. DN01 показывает оба значения рядом и помечает невалидные политики поддоменов так же, как и организационные. Когда `sp=reject` строже `p=quarantine`, асимметрия видна сразу, а не из отказов рассылки.

Анкеты compliance и vendor security всё чаще требуют доказательств зрелости email authentication, а не галочек в форме. Аудиторы спрашивают, настроен ли aggregate reporting (`rua`), частичен ли enforcement (`pct` меньше 100) и валидна ли запись сегодня, а не в прошлом квартале. DN01 отвечает из живого DNS, сохраняет raw TXT для скриншотов и разделяет жёсткие ошибки (дубликаты тегов, неверные policy) и предупреждения (режим мониторинга, relaxed alignment). Это помогает объяснить, что нужно исправить до enforcement, а что является осознанной стадией rollout.

После волны спуфинга incident response часто начинается с вопроса «DMARC сломан или отсутствует?», а не с выборки писем. Когда несколько TXT на `_dmarc` содержат более одного фрагмента `v=DMARC1`, получатели могут считать конфигурацию невалидной и игнорировать enforcement. DN01 берёт первую подходящую запись для разбора, но всё равно сообщает об ошибках duplicate tag внутри одной строки, помогая отличить split-brain DNS от безвредного исторического TXT. Перепроверьте после TTL, когда authoritative NS согласованы, и сверьте подписи через DKIM Validator перед возвратом к `reject`.

Если DN01 сообщает об отсутствии DMARC, запрашивайте именно `_dmarc.yourdomain.tld`, а не apex TXT, где лежит SPF. Многие команды публикуют SPF в корне и считают, что DMARC наследуется автоматически. Проверьте запись на всех authoritative NS после миграции DNS-провайдера: устаревшие делегации — частая причина, почему один резолвер видит `v=DMARC1`, а другой NXDOMAIN. Ответ об отсутствии записи — намеренная диагностика, а не сбой API.

Когда `valid` ложен при `found` true, сначала читайте массив errors, а не меняйте политику наугад. Дублирующиеся теги `p=`, неизвестные policy, нецелочисленный `pct` или значение вне 0–100 делают запись невалидной для строгих парсеров. Удалите дубликаты в DNS-панели, оставьте одну TXT через точку с запятой и не разбивайте DMARC на несколько TXT без корректной конкатенации у провайдера. После правок дождитесь TTL и перезапустите анализ.

Предупреждения о `p=none`, отсутствии `rua` или relaxed alignment не всегда означают, что почта уже падает — они описывают риск. `p=none` мониторит исходы аутентификации, не требуя quarantine или reject. Без `rua` вы не получите aggregate XML с источниками pass/fail. Если в warnings упомянут relaxed alignment, решите, нужны ли `adkim=s` или `aspf=s` до перехода на `reject`.

Если живой DNS расходится с панелью регистратора, сравните поле raw record с `dig +short TXT _dmarc.domain`. Кэширующие резолверы, региональные anycast-различия и частичный импорт зоны делают dashboard неточным. DN01 опрашивает резолвер платформы в момент запроса; сохраните raw TXT для change control, если нужно доказать внешне видимое значение.

Когда легитимная почта падает после ужесточения политики, DMARC может быть корректен, а SPF или DKIM — нет. Через DNS Checker проверьте SPF includes и лимиты flattening, через DKIM Validator — активные селекторы и срок ключей. Частичный enforcement через `pct=50` делает сбои «случайными»; DN01 предупреждает о pct ниже 100, чтобы вы могли сопоставить это с заголовками писем.

DMARC строится поверх SPF и DKIM. SPF проверяет envelope path, DKIM — криптографическую подпись, DMARC спрашивает, выравнивается ли результат с доменом в From, и что делать при провале обоих механизмов. DN01 не отправляет письма и не оценивает отдельные сообщения — он проверяет только DNS-политику для получателей. Поэтому связка с DKIM Validator и DNS Checker завершает картину: публикация, подпись и alignment — три разных проверки.

Тег `p=` обязателен. Допустимы только `none`, `quarantine` и `reject`; любое другое значение помечается невалидным. `none` подходит для стартового мониторинга, но DN01 предупреждает, что он не велит блокировать failing mail. `quarantine` обычно отправляет сбои в спам, `reject` просит отбрасывать письма. Путь к enforcement должен опираться на `rua`-отчёты, а не только на дедлайны в календаре.

Тег `pct` ограничивает долю failing-сообщений, к которым применяется политика. Значения ниже 100 означают частичное enforcement — полезно для поэтапного rollout, но мешает диагностике, потому что часть сбоев всё ещё доставляется. DN01 парсит `pct` как целое число и выдаёт ошибку при нечисловом значении или диапазоне вне 0–100. Для production-брендов финальная цель обычно `pct=100` после чистых отчётов.

Агрегированные отчёты идут на `rua`, чаще всего `mailto:`-адреса, которые должны быть зарегистрированы у процессора отчётов. DN01 перечисляет все значения через запятую и предупреждает об отсутствии `rua`, потому что без отчётов enforcement делается вслепую. Forensic `ruf` опционален и чувствителен к приватности; многие организации оставляют только `rua`. Анализатор показывает оба тега, если они опубликованы.

Теги alignment `adkim` и `aspf` задают strict (`s`) или relaxed (`r`) сопоставление доменов. При отсутствии DN01 считает оба relaxed и предупреждает, что получатели могут принять комбинации apex и subdomain, которые вы не планировали. Strict-режимы часто включают перед `reject`, чтобы снизить риск прохождения look-alike поддомена при header From на apex-бренде.

Флаг valid в DN01 означает отсутствие блокирующих ошибок разбора на момент проверки. Запись мониторинга с `p=none` и без `rua` может быть found с предупреждениями — полезный сигнал для risk review. Считайте `valid=false` дефектом DNS stop-ship до исправления, потому что часть получателей полностью игнорирует malformed policies.

Команда `dig TXT _dmarc.example.com` быстро показывает сырой TXT, но интерпретация политики остаётся на операторе. Нужно помнить, что дубли `p=` делают запись невалидной, `sp` управляет поддоменами, а без `rua` нет отчётности. DN01 кодирует эти правила и возвращает рекомендации за один проход — быстрее для handoff между DNS и mail-командами.

DNS Checker на DN01 показывает все TXT зоны, что полезно, когда рядом лежат SPF, DKIM и verification tokens. Он не оценивает риск DMARC policy и не подсвечивает частичный `pct`. Используйте DNS Checker для контекста зоны, DMARC Analyzer — когда вопрос именно в политике на `_dmarc`.

Aggregate XML в почтовом ящике показывает историю источников и долю сбоев, но приходит с задержкой и отражает прошлый трафик. Это не доказывает текущую DNS-публикацию после экстренного изменения. DN01 отвечает на вопрос live publication за секунды, а отчёты остаются ключом для решения об ужесточении `p`.

Консоли DMARC у вендоров дают дашборды и парсинг отчётов, но внешним аудиторам и DNS-операторам всё равно нужен нейтральный lookup TXT, который видит интернет. DN01 не зависит от report mailbox и работает даже без `rua` — как раз когда нужно подтвердить, что мониторинг никогда не настраивали.

Онлайн-валидаторы SPF иногда не проверяют DMARC-специфичные теги. DN01 использует тот же Go-парсер, что и production API, поэтому SEO-страница и API разделяют логику `p`, `sp`, `pct`, дубликатов и alignment defaults.

Таблицы DMARC-статуса клиентов устаревают после правки у регистратора или CDN DNS. Shareable URL результата DN01 даёт support и delivery актуальный снимок с query name, raw record и timing без shell-доступа.