Проверка DMARC-записи домена
Введите домен, и мы найдем DMARC-запись на _dmarc.<домен> или у родительского домена, разберем политику p= и sp=, адреса отчетов rua, долю pct и режим выравнивания. Покажем, что мешает записи работать, и что поправить перед переходом на reject.
Что эта проверка не показывает
- ✕Мы читаем запись в DNS. Проходят ли ваши письма DMARC на деле, видно только в отчетах rua и в заголовках полученных писем.
- ✕Строгая политика без проверенных отчетов может отправить в спам ваши же рассылки: переходите на quarantine и reject постепенно.
Проверка идет с нашего сервера по публичному DNS. Введенное значение не сохраняется и не пишется в журналы. Число проверок с одного адреса в минуту ограничено.
Что проверяет инструмент
- Есть ли запись v=DMARC1 и одна ли она. По RFC 7489 (раздел 6.6.3), если записей несколько, получатель не применяет DMARC вовсе.
- Где найдена запись: у самого домена или у родительского. Для поддомена без своей записи действует запись родителя, и тогда работает тег sp=, а если его нет, p=.
- Политика p=: none только собирает отчеты, quarantine просит класть не прошедшие проверку письма в спам, reject разрешает их отклонять. Нет p= или значение неизвестно: запись не работает как задумано.
- Отчеты rua: без них вы не узнаете, кто отправляет письма от имени домена и проходят ли ваши рассылки SPF и DKIM. Адрес должен быть в форме mailto:адрес@домен.
- Параметр pct (доля писем, к которым применяется политика) и выравнивание aspf и adkim: строгое (s) требует точного совпадения доменов, мягкое (r) допускает поддомены.
Как читать результат
"Ошибка" значит, что DMARC у получателя не сработает: записи нет, их несколько или нет корректной политики. "Есть замечания" чаще всего означает p=none или отсутствие отчетов: запись формально есть, но домен от подделки не защищает. "В порядке" означает quarantine или reject с отчетами.
Требования Gmail к массовым отправителям включают DMARC-запись, хотя бы с p=none. Поэтому p=none лучше, чем ничего, но это стартовая точка, а не цель.
Типичные ошибки и как их исправить
- Две записи на _dmarc, например, одна от прежнего подрядчика и одна новая. Оставьте одну, объединив адреса отчетов в rua через запятую.
- Запись опубликована на самом домене, а не на _dmarc.<домен>. Получатель ищет ее только на имени с префиксом _dmarc.
- p=reject сразу, без отчетов. Если какой-то сервис рассылок не проходит SPF или DKIM с выравниванием, его письма начнут отклоняться. Сначала p=none с rua, разбор отчетов, затем quarantine и reject.
- Отчеты уходят на адрес другого домена, а он не подтвердил, что их принимает. По RFC 7489 (раздел 7.1) внешний домен публикует для этого отдельную запись, иначе получатели отчеты не шлют.
- Как пройти путь от none до reject, не потеряв письма, описано в статье как настроить DMARC без потери писем, а почему письмо проходит SPF и DKIM, но не проходит DMARC, в статье о выравнивании доменов.
Пример записи для старта
TXT-запись на имени _dmarc.company.ru, отчеты приходят на ваш адрес:
v=DMARC1; p=none; rua=mailto:dmarc@company.ru
Как проверить вручную
dig +short TXT _dmarc.company.ru
nslookup -type=TXT _dmarc.company.ru
Частые вопросы
›Нужна ли отдельная запись на поддомене для рассылок?
Не обязательно: поддомен без своей записи подчиняется записи родителя (тег sp=, а без него p=). Отдельная запись нужна, если политика поддомена должна отличаться.
›Почему после p=reject пропали письма из CRM?
Скорее всего, сервис отправляет от вашего домена, но подписывает DKIM своим доменом и ставит свой Return-Path. Тогда ни SPF, ни DKIM не выровнены с полем "От кого". Настройте в сервисе подпись вашим доменом.
›Когда переходить на quarantine?
Когда отчеты rua за несколько недель показывают, что все ваши источники писем проходят SPF или DKIM с выравниванием, а не прошедшие проверку письма идут с чужих серверов.
Нужна помощь с переходом на reject?
Разберем отчеты DMARC, найдем сервисы, которые отправляют от имени домена без выравнивания, и спланируем переход без потери писем.
Обсудить аудит