У 43 доменов из нашего обхода есть DMARC, но не задан адрес для агрегированных отчётов. Из них 33 публикуют reject или quarantine: просят получателя отклонять подозрительные письма или помещать их в карантин, а отчёты через rua не запрашивают.

Мы проверили публичные DNS-записи 254 доменов из 17 секторов. Хотели увидеть, что настроено для защиты почты от подделки. Получили срез, в котором наличие записи оказалось только началом проверки: дальше нужны её параметры, ограничения самого чекера и сведения о реальных письмах.

Сначала посчитали записи

Список собрали вручную: ритейл, IT, промышленность, финансы, медиа, госсектор, телеком и другие отрасли. Это выборка заметных российских доменов, без претензии на представительность для всего рынка.

Срез относится к 28 сентября 2026 года. Чекер запрашивал MX, SPF, DMARC и перебирал 14 типовых DKIM-селекторов. Писем мы не отправляли. Падений скрипта на 254 доменах было 0, но это не значит, что ответил каждый DNS-сервер: 2 домена вернули SERVFAIL на все запросы и учтены как домены без записей.

Доли ниже рассчитаны от всех 254 доменов и округлены до десятых процента.

Наличие MX, SPF, DKIM и DMARC. Доли от всех доменов.

На уровне наличия записей картина выглядит неплохо. Но каждая строка отвечает на свой вопрос.

MX описывает приём почты. SPF позволяет проверить, разрешён ли серверу отправитель для домена в SMTP-конверте. DKIM проверяет подпись письма от домена подписанта. Ни найденная SPF-запись, ни опубликованный DKIM сами по себе не доказывают, что письмо отправлено от имени домена в видимом поле From.

Эту связь проверяет DMARC. Для успешной проверки нужен проходящий SPF или DKIM с согласованием домена с From; такое согласование называют alignment. Если подходящего результата нет, политика домена сообщает получателю, как обработать письмо. Окончательное решение остаётся за получателем.

Почему мы не стали считать ненайденный DKIM отсутствующим

По DNS нельзя получить полный список DKIM-селекторов. Наш чекер перебирал типовые имена, поэтому 62,2% означают долю доменов, где он нашёл запись по одному из них. Это нижняя граница обнаружения записей, а не измерение доли подписанных писем.

У остальных 37,8% подпись могла использовать нестандартный селектор. Даже найденная запись не подтверждает, что отправляемая сейчас почта подписана и проходит проверку: писем в этом эксперименте нет.

Что именно делал чекер и что осталось за пределами замера

Сценарий обхода описан в scripts/domain_sweep.py, проверки и селекторы находятся в src/services/domain_checker.py. Полный набор из 14 селекторов:

mail, default, dkim, selector1, selector2, google,
mailru, yandex, k1, s1, smtp, mx, key1, zoho

В SPF чекер учитывал политику по цепочке redirect=. Поэтому итоговое ~all могло находиться в другой записи, а не в TXT исходного домена.

Вывод обхода в терминале, 254 домена.

DNSBL в статистику не включали: по журналу подготовки черновика проверка у всех 254 доменов была помечена «не проверено». Недоступный ответ нельзя засчитывать как отсутствие домена в списке.

Первые записи сырого JSONL с результатами обхода.

Это срез DNS на одну дату. Он не показывает доставляемость, число попыток подделки или потери легитимной почты.

Страница приложения с агрегатами по секторам на emailstorm.ru.

Источники чисел и ограничения редакторской проверки собраны в приложении с агрегатами по секторам.

Такое ограничение метода влияет и на остальные выводы. DNS показывает, какую политику домен опубликовал. Проверить её работу на письмах по одному DNS нельзя.

DMARC есть. Что он просит делать?

Среди доменов с DMARC распределение политик получилось таким. Знаменатель здесь уже только домены с найденной DMARC-записью.

Политики среди доменов с DMARC.

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

Следом посмотрели SPF. Доли в этой таблице рассчитаны среди доменов с найденной SPF-записью.

Отдельно от долей: два крайних случая в абсолютных числах.

Окончания SPF: длина столбцов, число доменов; проценты, среди доменов с SPF.

У 32 доменов из 254 нашлось сочетание ~all и p=reject. Назвать это противоречием было бы ошибкой. Softfail не даёт SPF Pass для DMARC; при этом письмо может пройти DMARC по согласованной DKIM-подписи. Если подходящего результата нет ни по SPF, ни по DKIM, ~all само по себе не отменяет p=reject.

Замена ~all на -all не заменяет проверку alignment. По такому сочетанию записей нельзя объявить домен открытым для подделки.

Жёсткая политика тоже требует чтения целиком

У 27 доменов в выборке одновременно были p=reject или p=quarantine и sp=none. Основной домен просит строгую обработку, но для поддоменов задаёт режим наблюдения.

Здесь нужно проверять, какую политику наследует конкретный поддомен: у него может быть собственная DMARC-запись. Утверждать по родительской записи, что любой поддомен не защищён, нельзя. Практический вопрос к владельцу: осознанно ли выбрана разница между политиками?

В срезе встретились и pct=5 (1 домен), и pct=10 (2 домена). При трактовке pct как доли применения политики значение меньше 100 требует отдельного внимания: настройка может отражать постепенное включение ограничений. Это не обещание доставить все остальные письма. Получатель может применить собственные фильтры; результат зависит и от запрошенной политики.

По DNS мы видим параметры, но не причину их выбора. Временный этап внедрения и забытая настройка выглядят одинаково, пока не поговоришь с владельцем почты.

Где теряется обратная связь

Адреса rua заданы у 81,0% доменов с DMARC: у 183 доменов из 226 в записи указан адрес для отчётов rua. У оставшихся 19,0%, то есть у 43 доменов из 226, таких адресов в записи нет. Из этих 43 доменов 33 используют reject или quarantine.

С DMARC: две ветви, с rua и без rua. Строгие без rua выделены цветом.

Это самый полезный для практики результат обхода. Агрегированные отчёты помогают увидеть источники отправки и результаты проверок, в том числе для забытых легитимных рассылок. При строгой политике такие сведения нужны, чтобы разбирать отказы.

Отсутствие rua означает, что запись не запрашивает агрегированные отчёты этим способом. У владельца могут быть другие журналы и средства наблюдения. И обратное тоже верно: наличие адреса ещё не доказывает, что отчёты приходят, разбираются и приводят к исправлениям.

Здесь заканчиваются возможности нашего замера. Мы нашли конфигурации, которые стоит проверить, но не измерили ущерб от них. Сколько писем потеряно и сколько времени ушло на разбор, этот обход не показывает.

Что получилось по секторам

Ниже часть среза. Все проценты в строке, включая reject, рассчитаны от общего числа доменов соответствующего сектора. DKIM означает обнаружение по типовым селекторам.

Сектор	Доменов	SPF	DKIM	DMARC	reject
IT	33	100%	66,7%	100%	36,4%
Финансы	22	100%	45,5%	100%	59,1%
Телеком	10	100%	60%	80%	60%
Ритейл	35	94,3%	62,9%	88,6%	34,3%
Гос	10	80%	40%	60%	50%
Еда	10	70%	50%	70%	10%

Доли доменов с DMARC внутри каждого сектора из таблицы статьи.

В показанном срезе IT и финансы имеют полное покрытие SPF и DMARC. Объяснить разницу качеством работы ИБ по этим сведениям нельзя: способ отбора доменов и небольшие группы ограничивают сравнение.

Что проверить на своём домене

Начать можно с роли домена. В выборке нашлось 7 доменов с MX, но без SPF. Приём почты не доказывает, что домен что-либо отправляет. Прежде чем менять запись, надо выяснить, есть ли исходящая почта и какие сервисы её отправляют.

Затем стоит прочитать SPF целиком, включая зависимости. В срезе нашлась запись длиной 1241 символ: в ней напрямую перечислялись диапазоны IP вместо подключения записи провайдера. Длина сама по себе не доказывает нарушение лимита DNS lookup. При ручном списке нужно отдельно следить, соответствует ли он действующим отправителям.

Дальше нужна проверка на реальных письмах: проходит ли SPF или DKIM и совпадает ли нужный домен с From. Для DKIM селектор можно взять из заголовка DKIM-Signature, чтобы не гадать по типовым именам.

После этого имеет смысл посмотреть политику поддоменов и отчёты. Адрес rua стоит проверить на практике: приходят ли отчёты, кто их читает, как из них находят легитимные источники с ошибками. Ужесточать политику без этого разбора рискованно для собственной почты.

Обход начали с простого вопроса: у кого опубликованы записи? Самый полезный следующий вопрос оказался другим: чем владелец проверяет, что политика работает на его письмах? Если вы ужесточали DMARC, какой легитимный отправитель первым обнаружился в отчётах с ошибками?