Анализ DNS-снэпшота OpenINTEL за 2026-07-25

TL;DR. В январе я публиковал общий срез email-инфраструктуры Tranco top-1M — кто на чём принимает и шлёт почту. Самый частый вопрос в комментариях был про DMARC: «ну хорошо, запись есть у двух третей, а толку?» Отвечаю развёрнуто. Из 468 749 доменов top-1M, опубликовавших DMARC, реально применяют политику (p=quarantine/reject) 49.31%. Ещё 25.61% сидят на p=none, но хотя бы получают агрегатные отчёты — это легитимная фаза внедрения. А 25.04% — 117 384 домена — опубликовали запись, у которой p=none и нет ни одного рабочего адреса для отчётов. Такая запись не запрещает ничего, не сообщает никому ничего и существует в DNS исключительно ради галочки. При этом формально во всех отчётах и сканерах эти домены проходят как «DMARC: yes». Ниже — откуда взялся этот слой, чьи подписи в нём видны, почему доля enforcement при этом падает, и что произойдёт с половинчатыми политиками, когда получатели перейдут на DMARCbis.

Зачем вообще нужна p= в этой записи

Короткая вводная для тех, кто пропустил январскую статью (остальные — мотайте к цифрам).

DMARC — это TXT-запись на _dmarc.<domain>, которая делает две вещи. Первая: говорит принимающему серверу, что делать с письмом, которое провалило SPF/DKIM-выравнивание — то есть с письмом, где в поле From стоит ваш домен, а отправил его кто-то левый. Варианты: p=none (доставлять как ни в чём не бывало), p=quarantine (в спам), p=reject (не принимать). Вторая: тег rua= задаёт адрес, на который принимающие серверы шлют агрегатные XML-отчёты — кто, откуда и сколько отправлял от вашего имени и что из этого прошло аутентификацию.

Отсюда простое следствие, которое почему-то не пишут в мастерах настройки: запись v=DMARC1; p=none; без rua= эквивалентна отсутствию записи с точки зрения защиты. Спуфинг от вашего имени доставляется получателям ровно так же, как доставлялся бы без DMARC. Разница только одна — сканеры соответствия теперь показывают зелёную галочку.

Три состояния вместо бинарной метрики

Стандартный способ считать DMARC — бинарный: enforced / not enforced. Он прячет самое интересное, потому что валит в одну кучу домен, который месяц читает отчёты перед включением карантина, и домен, который поставил заглушку и забыл. Я разделил все 468 749 записей на три класса:

Состояние

Критерий

Доменов

Доля

Enforcing

p=quarantine или p=reject

~231 тыс.

49.31%

Monitoring

p=none, но есть рабочий rua=

~120 тыс.

25.61%

Инертные

p=none и ни одного рабочего rua=

117 384

25.04%

Monitoring — это нормально. Так и выглядит правильное внедрение: публикуешь p=none с отчётами, несколько недель смотришь, кто на самом деле шлёт от твоего домена (спойлер: всегда находится забытый CRM или скрипт на старом сервере), потом поднимаешь политику. Проблема не в p=none как таковом, а в p=none, у которого нет глаз.

Инертные записи — четверть всех DMARC-публикаций интернета. И это не преувеличение через хитрое определение: я считаю инертной только запись, где отчётного адреса нет вообще. Если добавить домены, у которых rua= формально присутствует, но парсится в мусор (в снэпшоте таких 960 — опечатки в mailto:, запятые вместо точек, адреса без домена), и домены с нерабочими адресами — цифра «DMARC публикуется, но отчёты не приходят никому» вырастает до 166 442 доменов, 35.51% всех DMARC-публикаций.

Откуда взялся этот слой: февраль 2024-го

Инертный DMARC — это не глупость админов. Это осадок от вполне конкретного события.

В феврале 2024 Google и Yahoo ввели требования к bulk-отправителям: шлёшь на Gmail больше 5000 писем в день — изволь иметь SPF, DKIM и DMARC хотя бы с p=none. В апреле 2025-го Microsoft объявила то же самое для Outlook. Требование разумное, но формулировка «хотя бы p=none» породила предсказуемый эффект: сотни тысяч доменов опубликовали минимально проходную запись. Регистраторы и хостинги встроили в панели кнопку «включить DMARC», которая генерирует заглушку. Дедлайн закрыт, письма ходят, все свободны.

Это отлично видно по верватим-топу — самым частым дословным строкам записи в датасете:

#1  v=DMARC1; p=none;    — 58 997 доменов
#2  v=DMARC1; p=none     — 33 310 доменов
#7  v=DMARC1;p=none;     —  3 809 доменов
#16 v=DMARC1;p=none      —  1 824 домена

Четыре самые популярные «пустые» записи интернета — это буквально одна и та же строка с разным количеством пробелов и точек с запятой. В сумме ~98 тысяч доменов, то есть основная масса инертного слоя — не самописные конфиги с ошибками, а растиражированные заглушки из одного и того же копипаст-источника: документации «как пройти требования Gmail за 5 минут», шаблонов панелей и статей-инструкций.

Свежая динамика подтверждает, что конвейер работает до сих пор: за последние 30 дней число DMARC-доменов в top-1M выросло на 9 173, и 74% этого прироста — записи с p=none.

Подписи в DNS: кто и как штампует записи

Верватим-топ — вообще довольно откровенный источник. Раз запись в DNS публична, а вендоры генерируют клиентам шаблоны со своими отчётными адресами, то по строке записи видно, кто её ставил.

v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:dmarc_rua@onsecureserver.net; — 3 620 доменов. Это автогенерация GoDaddy: узнаваемый шаблон, единый отчётный адрес на весь клиентский парк. Заметьте — p=quarantine, не p=none. Мастер настройки, который сразу ставит enforcement, существует, и это скорее хорошая новость.

v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com — 9 171 домен. Шаблон Brevo (ex-Sendinblue). Формально — monitoring, отчёты собираются. Но в январском снэпшоте эта же строка стояла на 7 172 доменах, и все — на p=none. За полгода запись расползлась ещё на две тысячи доменов, а фаза «мониторим перед включением» не закончилась ни у кого. Rollout, который никогда не завершается, — это отдельный, четвёртый режим существования DMARC.

v=DMARC1; p=reject; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com; ... — 3 159 + 1 480 доменов (два варианта строки). Enterprise-клиенты Proofpoint. Тут всё по учебнику: reject и централизованные отчёты.

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc.report@axa.com; — 1 556 доменов. Одна страховая компания. Это, судя по всему, весь защитный портфель доменов AXA — типосквоттинг-регистрации, региональные зоны, брендовые домены — накрытый единой жёсткой политикой с отчётами в собственный SOC. Хрестоматийный пример того, как это делается на корпоративном масштабе: не «настроили DMARC на основном домене», а проштамповали p=reject; sp=reject на полторы тысячи имён.

Контраст между последними двумя примерами и первой парой — и есть главный сюжет этого среза. DMARC расслоился: наверху корпорации со штампованным reject, внизу конвейер заглушек.

Парадокс: внедрение растёт, enforcement падает

Доля enforcement среди DMARC-публикаций за 30 дней снизилась на 0.42 п.п. — при том, что доменов с DMARC стало на девять тысяч больше. Никакого массового отката политик за этим нет: по ежедневному диффу доменов видно, что даунгрейды p=reject→none единичны. Это чистая арифметика разбавления: каждый день в знаменатель приходят сотни свежих p=none-заглушек, и средняя температура по больнице падает, хотя ни одному «старому» домену хуже не стало.

Практический вывод для всех, кто читает вендорские отчёты об «adoption rate»: рост числа DMARC-записей сам по себе не значит ничего. С 2024 года это метрика скорости конвейера заглушек. Смотреть надо на enforcement rate и его динамику — а он растёт настолько медленнее adoption, что доля даже проседает.

Отдельная песня: куда уходят отчёты

У 169 728 доменов (36.21% DMARC-публикаций) все агрегатные отчёты уходят только на внешний домен — вендору DMARC-аналитики, ESP или хостеру. Распределение отчётных вендоров такое: 46.27% адресов self-hosted или неклассифицированные, дальше Cloudflare DMARC (5.81%), Valimail (3.07%), Proofpoint EFD (2.71%), Brevo (2.66%), dmarcian (2.11%).

Сдавать разбор отчётов вендору — нормальная практика, XML-агрегаты руками читать невозможно. Но у конструкции «отчёты только наружу» есть два тихих свойства, о которых стоит помнить.

Первое: жизненный цикл. Триал у DMARC-аналитики кончился, компания сменила вендора, проект закрыли — а rua= в DNS остался. Запись выглядит настроенной, отчёты улетают на адрес, который никто не читает (или который вендор уже отключил), и домен годами летит вслепую. Отличить такую запись от рабочей извне нельзя — но, судя по количеству rua-адресов давно переименованных сервисов в датасете (dmarc@mailinblue.com — 2 123 домена всё ещё шлют отчёты на адрес шаблона Sendinblue, бренда, который с 2023 года называется Brevo; работает ли этот legacy-ящик — снаружи не проверить), слой «отчётов в никуда» заметно больше формальных 960 битых записей.

Второе: с 36% доменов интернета полная карта их легитимной отправляющей инфраструктуры — все IP, все ESP, все объёмы — течёт третьей стороне. Это не уязвимость, это осознанный трейд-офф, но его стоит хотя бы осознавать.

Кстати, про внешний rua= есть механика, о которой не знают даже многие админы со стажем: если отчётный адрес лежит на чужом домене, получатель обязан проверить авторизацию — TXT-запись <вашдомен>._report._dmarc.<домен-вендора>. Вендоры публикуют wildcard и всё работает прозрачно, но если вы указали внешний адрес «просто так» (например, свой gmail), часть получателей молча не пришлёт вам ни одного отчёта. Ещё один способ получить мониторинг, который выглядит настроенным.

Enforcement — функция размера

Один и тот же снэпшот, нарезанный по позиции в Tranco:

Ярус

Доменов с MX

SPF

DMARC enforced

top-1k

694

93.66%

73.05%

1k–10k

6 509

92.89%

56.46%

10k–100k

64 804

91.17%

43.34%

100k–1M

481 059

89.91%

29.81%

вне текущего списка

118 627

87.75%

19.10%

SPF по ярусам почти не меняется — четыре процентных пункта между вершиной и хвостом. DMARC enforcement обрушивается с 73% до 19–30%. То есть опубликовать аутентификацию могут все, а довести политику до enforcement — это функция наличия выделенной команды безопасности. Хвост списка — сотни тысяч обычных компаний с почтой на хостинге — и есть то место, где живут заглушки. И то место, откуда удобнее всего спуфить: поддельное письмо «от бухгалтерии» поставщика из третьего эшелона Tranco дойдёт до получателя без единого флага почти втрое вероятнее, чем подделка от банка из top-1k (70% доменов без enforcement против 27%).

DMARCbis: у половинчатых политик кончается срок годности

В этом году DMARC получил новую редакцию стандарта (DMARCbis, RFC 9989–9991 вместо RFC 7489). Среди изменений есть одно с прямыми операционными последствиями: тега pct= больше нет.

В старом стандарте p=quarantine; pct=25 означало «карантинить четверть проваливших писем» — механизм плавного включения. Получатель, перешедший на DMARCbis, тег pct= просто игнорирует — и ваша «четверть» превращается в 100%. По этому снэпшоту разница уже измерима: под RFC 7489 (pct=100 обязателен для enforcement) доля enforcing — 46.95%, под DMARCbis-семантикой — 49.31%. Два процентных пункта доменов прямо сейчас сидят в состоянии «частичный enforcement», которое исчезнет как класс по мере обновления принимающего софта — причём не по их решению, а по решению получателей.

Новые теги DMARCbis пока не внедряет почти никто: np= (политика для несуществующих сабдоменов — кстати, полезная штука против спуфинга с выдуманных хостов) опубликован у 249 доменов из миллиона, psd= — у 63.

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

Проверить, в каком вы классе: dig TXT _dmarc.вашдомен +short. Если в ответе p=none и нет rua= — вы в тех самых 25%.

Дальше стандартная лестница, только с граблями, которые видны из датасета. Ставите p=none; rua=mailto:dmarc@вашдомен (или вендора — но тогда проверьте, что подписка живая) и две-четыре недели читаете отчёты: почти наверняка обнаружится легитимный источник, о котором вы не помнили — CRM, тикетница, рассыльный скрипт на старом VPS. Чините SPF/DKIM для всего найденного. Потом p=quarantine — и лучше сразу без pct=, потому что его семантика уже поплыла (см. выше); если страшно, режьте по сабдоменам через sp=, а не по процентам. Пожив на карантине, переходите на p=reject. Не забудьте sp= — политика апекса не закрывает сабдомены, а спуфят охотно именно invoice.вашдомен. И финальный штрих, который делает полтора человека на миллион: np= для несуществующих сабдоменов.

Чего делать не надо — публиковать заглушку и считать вопрос закрытым. Как видно из цифр, компания у вас будет большая, 117 тысяч доменов, но не та, в которой хочется состоять.

Данные и воспроизводимость

Датасет — ежедневные forward-DNS-снэпшоты OpenINTEL (University of Twente / SURFnet / SIDN Labs) поверх Tranco top-1M: MX, TXT, NS и прочие RR-типы всего списка, каждый день, в Apache Parquet. Методика измерений описана в van Rijswijk-Deij et al., IEEE JSAC 2016. Классификация отчётных адресов rua= — открытый словарь dmarc_vendors.py; enforced в базовой метрике — p∈{quarantine, reject} при pct=100 или отсутствующем pct (по RFC 7489 §6.6.4 дефолт — 100).

Все цифры этой статьи — из снэпшота за 2026-07-25. Срез пересобирается ежедневно и публикуется целиком — верватим-топ записей, разбивка по ярусам, классификация вендоров, исторические ряды с 2016 года — на check.live-direct-marketing.online/email-stats, вместе с хешами словарей классификаторов, так что любую таблицу отсюда можно сверить с завтрашним прогоном. Замеченные ошибки классификации попадают в следующий ежедневный запуск.

Ограничения, честно

DNS-срез видит декларации, не поток писем: домен с p=reject и нулём отправлений и домен с миллионом писем в день весят одинаково. Tranco смещён к US/EU — выводы по отдельным региональным рынкам из этих данных делать нельзя. «Рабочий rua=» здесь означает «синтаксически валидный адрес»: проверить, читает ли его живой человек, снаружи невозможно, поэтому реальная доля слепых записей — выше измеренной, а не ниже. Ежедневный дифф ловит смену политики между снэпшотами, но не внутри суток. И, как обычно: если ваша запись попала в статистику не в тот класс — пишите, поправим словарь к следующему прогону.

Январский срез (общий ландшафт MX/SPF/ESP): «Кто на чём шлёт и принимает почту: измеряем email-инфраструктуру 660 тысяч доменов из Tranco top-1M».

Ссылки