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

TL;DR. Используя ежедневные DNS-снэпшоты OpenINTEL поверх списка Tranco top-1M, мы собрали ландшафт email-инфраструктуры публичного веба на 1 января 2026 года. MX-записи опубликовали 660 114 доменов, SPF — 616 352, DMARC — 431 133. Дуополия Google Workspace (21.7%) + Microsoft 365 (16.3%) занимает суммарно ~38% receiving-стороны — заметно меньше, чем принято считать в популярных обзорах. На outbound-стороне Amazon SES вышел вперёд по числу авторизованных доменов (5.86%), обогнав SendGrid (4.66%). DMARC опубликован у двух третей SPF-доменов, но 19% всех DMARC-записей — это пустая v=DMARC1; p=none; без отчётов: формальная галочка, а не защита.

Зачем это нужно

Email — старейший протокол интернета, который при этом остаётся главным каналом B2B-коммуникации и одним из основных векторов фишинга. Парадокс в том, что сама экосистема — кто хостит входящую почту, кто шлёт исходящую от чужих доменов, как настроена аутентификация — почти не описана в публичной аналитике. Большинство вендорских отчётов либо платные, либо завязаны на собственную клиентскую базу, что создаёт системный bias.

Существующие источники, которые я знаю:

• Valimail Email Fraud Landscape — выходит ежегодно с 2017 года, анализирует только DMARC, фокусируется на отдельных индустриях (Fortune 500, US Gov, healthcare). Данные строятся на собственных DMARC-репортах клиентов плюс публичных DNS-запросах.

• Академические работы по OpenINTEL — есть отдельные исследования по DMARC, DKIM, BIMI. Срезы делаются один раз под публикацию, не обновляются.

• BuiltWith, Datanyze — коммерческие сервисы технографики. Данные есть, но не реплицируемы и не для исследований.

Чего не было: открытого ежедневного среза одновременно по четырём измерениям (MX, SPF, DMARC, SaaS-отправители) на масштабе всего Tranco top-1M, с прозрачной методологией и feedback loop для уточнения классификаторов.

Этот пробел я и пытался закрыть. Ниже — методология, текущие цифры и честный список ограничений.

Данные и метод

Источник: OpenINTEL + Tranco

Базовый датасет — ежедневный forward-DNS-снэпшот проекта OpenINTEL (University of Twente / SURFnet / SIDN Labs). OpenINTEL с 2015 года ежедневно опрашивает крупные публичные списки доменов по широкому набору RR-типов (MX, TXT, NS, A, AAAA, SOA, CAA, DS/DNSKEY) и публикует результаты в Apache Parquet.

Метод детально описан в van Rijswijk-Deij et al., IEEE JSAC 2016 — это та же инфраструктура, на которой делалось большинство академических работ по DNS за последние 10 лет.

Список доменов — Tranco, научно-обоснованная замена устаревших Alexa/Cisco Umbrella. Tranco агрегирует несколько источников ranking-а доменов и устойчив к манипуляциям (Le Pochat et al., NDSS 2019). OpenINTEL ежедневно проходит весь top-1M.

Снэпшот за 2026-01-01: после фильтрации служебных записей и нормализации остаётся 660 114 доменов с валидным MX, 616 352 с TXT-записью SPF (v=spf1) и 431 133 с TXT-записью DMARC (v=DMARC1).

Что классифицируем

Mailbox provider (receiving-сторона): для каждого домена берём RRset MX, выбираем запись с наименьшим mx_preference (основной хост), и сопоставляем её с открытым словарём правил mx_providers.py. Логика — сначала специфичные паттерны:

RULES = [

    (r"\.mail\.protection\.outlook\.com$", "Microsoft 365"),

    (r"aspmx.*\.googlemail\.com$|aspmx\.l\.google\.com$", "Google Workspace"),

    (r"mx\d?\.yandex\.net$", "Yandex 360"),

    (r"\.mimecast\.com$", "Mimecast"),

    # ... ~80 правил для названных провайдеров

    # Затем generic fallback'и:

    (r"^mail\.", "Generic / unmatched (mail.*)"),

    (r"^mx\d*\.", "Generic / unmatched (mx*.*)"),

    (r"^smtp\.", "Generic / unmatched (smtp.*)"),

]

Если ни одно правило не сработало — домен попадает в "Unknown / Other", и его MX-таргет логируется в файл топ-100 неклассифицированных хостов для дальнейшего расширения словаря. Принципиальный момент: домены не выбрасываются. Любая отчётность сходится: сумма по провайдерам = общему числу доменов с MX.

ESP (sending-сторона): для каждой SPF-записи извлекаем все include: и redirect= таргеты, резолвим против словаря esps.py (Amazon SES, SendGrid, Mailgun, Mailchimp, Brevo, Mailjet, Salesforce, etc.). Один домен может авторизовать несколько ESP, поэтому суммарная доля по ESP превышает 100% SPF-доменов.

SaaS senders: тот же механизм, но против отдельного словаря saas_senders.py — это бизнес-приложения, которые шлют почту от лица клиента (Shopify, Atlassian, Pardot, KnowBe4, Trustpilot, NetSuite). Концептуально — третий слой email-стека: не где лежит ящик, не чем рассылка, а какие SaaS подписали ваш домен в свой Return-Path.

DMARC: парсим TXT-запись _dmarc.<domain> на теги p=, sp=, pct=, rua=, ruf=. Домен считается enforced, если p ∈ {quarantine, reject} и (pct=100 или pct отсутствует — по RFC 7489 §6.6.4 дефолт 100).

Что не делается (важно для честности)

• CNAME-цепочки на MX не разворачиваются. Если домен имеет MX mail.example.com, который CNAME'ом ведёт на example-com.mail.protection.outlook.com — он попадёт в "Unknown / Other", хотя по факту это Microsoft 365. Поправка на эту погрешность — отдельная задача и пока не реализована.

• SPF flattening (когда include: цепочка заменена сырыми IP-сетями ради лимита 10 lookup'ов из RFC 7208 §4.6.4) скрывает реального ESP. Все измерения долей ESP систематически занижены на этот фактор. Оценка масштаба: по выборочным проверкам — 5–15% доменов с явно flattened SPF.

• DKIM не измеряется. Чтобы прочитать DKIM-ключ, нужно знать селектор (selector1._domainkey.example.com) — а селекторы выбираются произвольно. Без активной разведки выявить DKIM нельзя, и OpenINTEL это не запрашивает.

• Vanity domains для security/ESP-вендоров (когда клиент Mimecast/Proofpoint использует свой брендовый MX-хост, заворачивающий трафик внутрь вендора) с DNS не определяются.

Ландшафт receiving: куда приходит почта top-1M

Распределение по основному MX (доля от 660 114 доменов с MX):

Пара наблюдений, которые расходятся с типичной публицистикой:

1. "Дуополия Google + Microsoft" — миф в чистом виде. Их совместная доля — 37.94%. Доминирующая, но далеко не подавляющая. Длинный хвост из размещённых на собственных серверах, у регистраторов, в небольших SaaS-провайдерах — это половина рынка (Unknown 25.91% + три generic-сегмента 24.12% = 50.03%).

2. Generic-сегменты ≠ "самохост". Хост вида mail.example.com — это типичный паттерн для cPanel/DirectAdmin shared hosting (Hostinger, GoDaddy, OVH и десятки региональных хостингов). По топ-100 неклассифицированных MX-таргетов видно, что лидируют именно регистраторы:

Cloudflare Email Routing с 23 тыс. доменов в одной только этой выборке — отдельный любопытный сюжет. Это бесплатный сервис forwarding'а, у него нет полноценного inbox'а, но как первичный MX он используется массово.

3. Yandex 360 — 1.91%. Это сильно занижено относительно реальной доли в RU-сегменте. Tranco смещён к US/EU и глобальным SaaS, ru-домены с низкой международной видимостью в нём недопредставлены. Любой вывод по российскому рынку из этого датасета будет неверным — нужен отдельный срез по ccTLD .ru или другой источник списка.

Sending: чем шлют outbound

Доля от 616 352 SPF-публикующих доменов. Сумма >100% — у одного домена обычно несколько ESP (например, маркетинг через Mailchimp + транзакции через SendGrid):

Несколько важных оговорок к этой таблице:

Доля по доменам ≠ доля по объёму писем. Amazon SES — лидер по числу авторизованных доменов, но реальная доля от мирового объёма email'а у него скорее ниже, чем у SendGrid: SES часто используют как дешёвый IaaS-уровень, на котором сидят небольшие проекты, а крупные рассылки идут через специализированные платформы. DNS-метрика этого не различает.

Mandrill = транзакционный продукт Mailchimp. Если их объединить, доля семейства Intuit MailChimp выходит на 7.40% — формально первое место. По доменам люди обычно держат Mandrill в SPF на старых проектах и забывают убрать после миграции, поэтому реальная активность ниже.

Zendesk на 4-м месте — это support-почта (support@yourcompany.com, обслуживаемая через Zendesk). Не маркетинг и не транзакционка, а отдельная категория, которую часто упускают в обзорах.

Salesforce 2.5% — это _spf.salesforce.com. Если добавить отдельный Pardot (Salesforce) из таблицы SaaS-отправителей (5191 домен, 0.84%), реальная доля экосистемы Salesforce заметно выше.

Самое важное: все эти цифры — нижняя граница. SPF flattening, который применяется примерно у 5–15% крупных корпоративных доменов (точная оценка — будущая работа), маскирует реального ESP. Если завтра все одновременно расфлатят SPF, доли Mailgun/SES/SendGrid вырастут на единицы процентных пунктов.

Длинный хвост: SaaS-отправители

Отдельный слой — бизнес-приложения, которые шлют почту от лица клиента:

Что тут любопытно:

KnowBe4 на 3-м месте (3309 доменов). KnowBe4 — это security-awareness training: симулированные фишинговые письма для обучения сотрудников. Чтобы система могла отправлять эти "симулированные атаки" с домена клиента не попадая в спам, клиент добавляет KnowBe4 в SPF. Цифра 3309 = это число организаций, которые на момент снэпшота активно платят KnowBe4 за такие тренировки (с поправкой на flattened SPF). Прокси-метрика рынка security-awareness, который иначе очень сложно мерить.

Lark / Feishu (китайский Slack от ByteDance) — 1181 домен в Tranco. Видно западную экспансию платформы.

Shopify первый — что закономерно: каждый магазин на Shopify добавляет _spf.shopify.com в SPF своего домена, чтобы транзакционные письма не попадали в спам. 5446 — нижняя граница числа Shopify-магазинов, у которых свой домен попадает в Tranco-1M.

DMARC: декларация vs реальность

Из 616 352 доменов с SPF — 431 133 (69.95%) опубликовали валидный DMARC. На первый взгляд — отличный показатель. Но дьявол, как обычно, в pct=.

Топ-11 наиболее частых верватим-DMARC-записей в датасете:

Складываем всё с p=none без rua= (записи #1, #2, #5 — это голая декларация без отчётов): 87 469 доменов, 20.3% всех DMARC-записей. Это DMARC compliance theater — формально домен "имеет DMARC", по факту не настроен ни мониторинг, ни enforcement. Зачастую это автогенерация мастером настройки у регистратора: "галочка для соответствия Google/Yahoo bulk sender requirements 2024".

При этом видно сразу несколько любопытных подписей вендоров:

Запись #3 — rua=mailto:rua@dmarc.brevo.com на 7172 доменах. Brevo (бывший Sendinblue) автоматически генерирует и предлагает клиентам шаблон DMARC-записи со своим адресом для агрегатных репортов. По этой подписи можно посчитать активную клиентскую базу Brevo, у которой настроен DMARC по их шаблону: примерно 7–10 тыс. доменов в Tranco-1M (сложить #3 + #11).

Запись #7 — Proofpoint Email Defense на 3333 доменах. Похожий паттерн: enterprise-клиенты Proofpoint настраивают агрегатные репорты на их emaildefense.proofpoint.com, и это видно в DNS как уникальная подпись.

Записи Valimail (dmarc_agg@vali.email). В сумме ~3700 доменов используют Valimail как DMARC-aggregator. Это ниже их публично заявленных 65 тыс. клиентов (Sacra estimate, 2024) — потому что большая часть клиентов Valimail (особенно SMB) не попадает в Tranco top-1M.

Главный практический вывод: считать DMARC adoption по числу опубликованных записей — методологическая ошибка. Корректная метрика — enforcement rate: доля доменов с p ∈ {quarantine, reject} и pct=100. По этой метрике картина сильно скромнее, и тренд на её рост (+1.86% за 90 дней по нашим данным) — медленный.

Воспроизводимость

Каждый ежедневный отчёт фиксирует:

• дату OpenINTEL-снэпшота;

• SHA256-хеши словарей классификаторов (mx_providers.py, esps.py, saas_senders.py);

• топ-100 не классифицированных MX-хостов и SPF-include таргетов — публично, чтобы любой читатель мог предложить дополнение в словари.

Снапшот публикуется ежедневно на check.live-direct-marketing.online/blog. Исторические срезы — последние 90 дней целиком, более старые проредаются до месячных. Базовая инфраструктура спроектирована так, чтобы при наличии архива OpenINTEL восстановить ряд назад — теоретически с 2015 года, на практике — с момента, когда в OpenINTEL появился сам список Tranco (2018+).

Что эта метрика измеряет, а что — нет

Ещё раз честный список ограничений, в одном месте:

1. DNS-конфигурация ≠ объём писем. Все цифры — про число доменов. Здесь логика та же, что у Lighthouse-метрик: видим декларации, не реальный поток.

2. Tranco bias к US/EU. Любой вывод по RU/CN/JP/KR из этих данных будет искажён. Для региональных рынков нужен отдельный список или ccTLD-фильтр.

3. SPF flattening занижает доли ESP. Для крупных enterprise-доменов — заметно (5–15%).

4. CNAME-чейны на MX не разворачиваются. Часть Microsoft 365 / Google Workspace доменов попадает в "Unknown".

5. DKIM не измерим без знания селектора — отсутствует в датасете полностью.

6. Vanity-MX security-вендоров (Mimecast/Proofpoint с whitelabel-доменами клиента) — недетектируемы из DNS.

7. Срез — это снэпшот. Тренды считаются на разнице снэпшотов. Любая смена ESP/MX в день между снапшотами невидима.

Что дальше

Сейчас система работает в "snapshot mode" — каждый день независимо. Следующие шаги в порядке приоритета:

8. CNAME unrolling для MX-таргетов — должно перенести часть "Unknown" в Microsoft 365 / Google Workspace и дать более точную оценку дуополии.

9. BIMI-ключи (default._bimi.<domain>) — отдельная классификация brand-indicator-сетапов. Это уже follow-up по DMARC: BIMI требует p=quarantine|reject с pct=100 плюс VMC-сертификат.

10. MTA-STS / DANE / TLS-RPT — следующий слой email security beyond authentication. У OpenINTEL эти записи запрашиваются, метрика по ним пока не считается.

11. Сравнение со срезами по ccTLD — для устранения Tranco bias по региональным рынкам (отдельный datapoint для .ru, .cn, .de, .jp).

12. Пересечения: домены с p=reject среди клиентов конкретного ESP, доля доменов на Cloudflare Email Routing с DMARC, и т.п. — двумерные срезы для более интересных историй.

Что с этим делать читателю

Если ты владелец/инженер-владелец домена:

• Проверь свою DMARC-запись. Если у тебя v=DMARC1; p=none; без rua= — ты в той самой группе compliance theater. Ставь rua=mailto:dmarc@yourdomain.com, дай ей покрутиться 2–4 недели, потом переходи к p=quarantine; pct=10 и далее по эскалации.

• Посмотри, не флатнут ли твой SPF. Если в твоей записи 30 IP-сетей вместо include: — ты теряешь видимость для аналитики и нагружаешь DNS-резолверы клиентов.

• Если у тебя крупный корпоративный домен — разверни CNAME для MX в реальный target. Это не повлияет на доставку, но улучшит обнаруживаемость в индустриальной аналитике и отчётах безопасности.

Если ты ESP/security-вендор:

• Видишь свою долю в этой статистике. Это нижняя граница (из-за SPF flattening). Как меняется — отдельный сюжет, но даже моментальный snapshot показывает позицию в индустрии.

• Подпись твоего DMARC-шаблона видна в DNS. Если ты массово настраиваешь клиентам rua=mailto:...@yourbrand.com, это де-факто публичная customer-метрика.

Если ты исследователь:

• Датасет открыт и воспроизводим. Словари классификаторов в публичном репозитории, методология описана, OpenINTEL — академический проект с понятными data agreements. Любые корректировки в словарях принимаются и в следующем снэпшоте отражаются.

Приглашение к корректуре

Если в топ-100 неклассифицированных MX-таргетов или SPF-include'ов вы видите свой ESP/SaaS — пишите на support@live-direct-marketing.online или открывайте issue. Словари обновятся к следующему ежедневному прогону.

Список миссклассификаций, на которые я уже знаю — его исправлять:

• eforward*.registrar-servers.com — это Namecheap email forwarding, надо вынести в отдельный класс из generic.

• route*.mx.cloudflare.net — Cloudflare Email Routing, отдельный класс.

• mailstore1.secureserver.net — GoDaddy, надо классифицировать.

К следующей публикации эти три уже должны быть учтены — и доля "Unknown" заметно уменьшится.

Ссылки

• OpenINTEL

• Tranco list

• van Rijswijk-Deij et al., "A High-Performance, Scalable Infrastructure for Large-Scale Active DNS Measurements", IEEE JSAC 2016

• Le Pochat et al., "Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation", NDSS 2019

• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)

• RFC 7208 — Sender Policy Framework (SPF)

• Текущий ежедневный отчёт

Статья описывает срез на 2026-01-01. Данные обновляются ежедневно. Замеченные ошибки и пропущенные ESP/провайдеры — присылайте, обновляются к следующему прогону.