Проверка DMARC-записи

Назначение инструмента «Проверка DMARC-записи»

Инструмент «Проверка DMARC-записи» предназначен для детального разбора текстовых TXT-записей DMARC, которые вы предоставляете для анализа. Он позволяет администраторам почтовых доменов и специалистам тщательно изучить структуру записи, проверить выбранные политики, параметры выравнивания идентификаторов, адреса для отправки отчетов, а также устаревшие значения процентного покрытия.

В процессе работы инструмент автоматически выявляет недействительные теги, указывает на синтаксические ошибки и предупреждает о возможных проблемах в политике безопасности. Это помогает детально понять, как именно принимающие почтовые серверы будут интерпретировать и применять вашу DMARC-запись.

Входные данные и ограничения

Для проведения анализа пользователю необходимо предоставить один ключевой параметр:

• Значение DMARC TXT (поле ввода «Значение DMARC TXT»): текстовая строка, которая в обязательном порядке должна начинаться с чувствительного к регистру префикса v=DMARC1.
• Обработка кавычек: если ваша DNS-запись разделена на части, заключенные в кавычки, инструмент автоматически примет их и объединит в единую строку перед началом анализа.
• Ограничение на размер: длина анализируемой записи не должна превышать 20 000 символов. При превышении этого лимита система отобразит ошибку: «Эта запись необычно велика. Ограничьте её 20 000 символами.».

Результаты анализа DMARC

После запуска проверки инструмент формирует подробный отчет, разделенный на несколько информационных блоков:

1. Анализ DMARC (основной раздел с результатами проверки).
2. Сводка DMARC, содержащая ключевые параметры конфигурации:
   • p: политика для основного домена.
   • sp: политика для поддоменов.
   • np: политика для несуществующих поддоменов.
   • DKIM / SPF: информация о выравнивании идентификаторов для протоколов SPF и DKIM.
   • rua / ruf: количество указанных адресов для отправки отчетов.
   • pct (RFC 7489): процентное значение для устаревших реализаций DMARC.
3. rua / ruf (детализация направлений отправки отчетов):
   • rua: адреса для отправки агрегированных отчетов.
   • ruf: адреса для отправки отчетов о сбоях авторизации.
4. Разобранные условия (таблица со всеми обнаруженными тегами):
   • Условие: имя тега DMARC.
   • Значение или квалификатор: значение, присвоенное данному тегу.
   • Тип: статус тега (активный — RFC 9989, устаревший — RFC 7489, неизвестный или недействительный).
5. Примечания по синтаксису и политике: список предупреждений, ошибок и замечаний, касающихся структуры и логики вашей политики.

Правила обработки тегов и логика валидации

При анализе DMARC-записи инструмент руководствуется строгими правилами спецификации и обрабатывает различные пограничные случаи:

• Обязательное начало: запись должна строго начинаться с тега v=DMARC1 (с учетом регистра). Этот тег обязан идти самым первым в списке.
• Отсутствие политики: если в записи отсутствует тег p, политика домена автоматически откатывается к значению none.
• Особенность p=none: политика p=none предназначена исключительно для мониторинга и сбора отчетов; она не дает указаний принимающим серверам помещать в карантин или отклонять письма, не прошедшие проверку.
• Режим тестирования (t=y): активация флага тестирования временно снижает строгость обработки писем на стороне получателя — политика quarantine превращается в none, а reject снижается до quarantine.
• Иерархия политик поддоменов: при отсутствии более специфических тегов для поддоменов применяется цепочка наследования (откат): от np к sp, а затем к основной политике p.
• Правила для отчетов:
  • Если в записи нет корректного адреса rua, агрегированные отчеты запрашиваться не будут.
  • Тег fo полностью игнорируется принимающими системами, если не указан валидный адрес ruf для отчетов о сбоях.
  • Суффикс размера !size в URI отчетов признан устаревшим и должен игнорироваться современными почтовыми серверами.
• Устаревшие параметры: тег pct относится к историческому стандарту и ограничивает применение политики только на тех серверах-получателях, которые все еще используют старые спецификации DMARC. Инструмент успешно распознает такие исторические теги, которые современные системы могут игнорировать.

Конфиденциальность и обработка данных

Безопасность ваших данных является приоритетом:

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

---

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

Примечания по синтаксису и политике: p / sp / np?

Если в записи отсутствует тег политики p, она автоматически принимает значение none. При использовании тестового режима t=y строгость политик снижается: reject переходит в quarantine, а quarantine — в none. Для поддоменов действует правило последовательного отката при отсутствии точечных настроек: от np к sp, а затем к p.

RFC 9989: pct / rf / ri?

Нет. Эта страница проверяет только вставленный текст. Она не запрашивает DNS, не раскрывает записи провайдера, не проверяет IP отправителя и не подтверждает ответ принимающего почтового сервера. В соответствии с актуальным стандартом RFC 9989, параметры pct, rf и ri перешли в статус устаревших (historic), в то время как теги np, psd и t классифицируются как активные (active).

Доказывает ли результат без ошибок, что моя настройка DMARC работает?

Нет. Эта страница проверяет только вставленный текст. Она не запрашивает DNS, не раскрывает записи провайдера, не проверяет IP отправителя и не подтверждает ответ принимающего почтового сервера. Для полной проверки работоспособности требуется комплексная настройка DNS и отправка тестовых сообщений.