|
Professor Seleznov
|
Анализ 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. на теги 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):
| # |
Mailbox provider |
Domains |
Share |
| 1 |
Unknown / Other |
171 044 |
25.91% |
| 2 |
Google Workspace |
143 171 |
21.69% |
| 3 |
Microsoft 365 |
107 277 |
16.25% |
| 4 |
Generic / unmatched (mail.*) |
91 739 |
13.90% |
| 5 |
Generic / unmatched (mx*.*) |
59 783 |
9.06% |
| 6 |
Yandex 360 |
12 587 |
1.91% |
| 7 |
Mimecast |
9 850 |
1.49% |
| 8 |
Generic / unmatched (smtp.*) |
7 649 |
1.16% |
| 9 |
Zoho Mail |
6 800 |
1.03% |
| 10 |
Amazon WorkMail |
4 707 |
0.71% |
Пара наблюдений, которые расходятся с типичной публицистикой:
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-таргетов видно, что лидируют именно регистраторы:
| # |
MX target |
Domains |
| 1 |
route1.mx.cloudflare.net |
7 728 |
| 2 |
route2.mx.cloudflare.net |
7 727 |
| 3 |
route3.mx.cloudflare.net |
7 726 |
| 4 |
eforward5.registrar-servers.com |
6 930 |
| 5 |
mx1.hostinger.com |
5 110 |
| 6 |
smtp.secureserver.net (GoDaddy) |
5 078 |
| 7 |
mx3-hosting.jellyfish.systems |
2 212 |
| 8 |
mx1.privateemail.com (Namecheap) |
1 658 |
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):
| # |
ESP |
Domains |
Share |
| 1 |
Amazon SES |
36 148 |
5.86% |
| 2 |
SendGrid (Twilio) |
28 695 |
4.66% |
| 3 |
Mailgun |
25 066 |
4.07% |
| 4 |
Zendesk |
24 053 |
3.90% |
| 5 |
Mailchimp |
23 606 |
3.83% |
| 6 |
Mandrill |
22 008 |
3.57% |
| 7 |
Salesforce |
15 426 |
2.50% |
| 8 |
Mailjet (Sinch) |
12 720 |
2.06% |
| 9 |
Brevo (ex-Sendinblue) |
6 892 |
1.12% |
| 10 |
Elastic Email |
4 399 |
0.71% |
Несколько важных оговорок к этой таблице:
Доля по доменам ≠ доля по объёму писем.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-отправители
Отдельный слой — бизнес-приложения, которые шлют почту от лица клиента:
| # |
SaaS app |
Domains |
Share |
| 1 |
Shopify |
5 446 |
0.88% |
| 2 |
Pardot (Salesforce) |
5 191 |
0.84% |
| 3 |
KnowBe4 |
3 309 |
0.54% |
| 4 |
Trustpilot |
1 966 |
0.32% |
| 5 |
Atlassian (Jira/Confluence) |
1 864 |
0.30% |
| 6 |
Firebase (Google) |
1 614 |
0.26% |
| 7 |
Lark / Feishu |
1 181 |
0.19% |
| 8 |
BigCommerce |
1 157 |
0.19% |
| 9 |
NetSuite (Oracle) |
1 139 |
0.18% |
| 10 |
Qualtrics |
1 104 |
0.18% |
Что тут любопытно:
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-записей в датасете:
| # |
DMARC record |
Domains |
| 1 |
v=DMARC1; p=none; |
50 658 |
| 2 |
v=DMARC1; p=none |
32 837 |
| 3 |
v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com |
7 172 |
| 4 |
v=DMARC1; p=quarantine; |
4 365 |
| 5 |
v=DMARC1;p=none; |
3 974 |
| 6 |
v=DMARC1; p=quarantine |
3 636 |
| 7 |
v=DMARC1; p=reject; fo=1; rua=…@emaildefense.proofpoint.com; ruf=…@emaildefense.proofpoint.com |
3 333 |
| 8 |
v=DMARC1; p=reject; |
3 319 |
| 9 |
v=DMARC1; p=quarantine; adkim=s; aspf=s |
2 978 |
| 10 |
v=DMARC1; p=reject |
2 753 |
| 11 |
v=DMARC1; p=none; sp=none; rua=mailto:dmarc@mailinblue.com!10m; … |
2 353 |
Складываем всё с 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+).
Что эта метрика измеряет, а что — нет
Ещё раз честный список ограничений, в одном месте:
- DNS-конфигурация ≠ объём писем.Все цифры — про число доменов. Здесь логика та же, что у Lighthouse-метрик: видим декларации, не реальный поток.
- Tranco bias к US/EU.Любой вывод по RU/CN/JP/KR из этих данных будет искажён. Для региональных рынков нужен отдельный список или ccTLD-фильтр.
- SPF flattening занижает доли ESP.Для крупных enterprise-доменов — заметно (5–15%).
- CNAME-чейны на MX не разворачиваются.Часть Microsoft 365 / Google Workspace доменов попадает в "Unknown".
- DKIM не измерим без знания селектора — отсутствует в датасете полностью.
- Vanity-MX security-вендоров (Mimecast/Proofpoint с whitelabel-доменами клиента) — недетектируемы из DNS.
- Срез — это снэпшот.Тренды считаются на разнице снэпшотов. Любая смена ESP/MX в день между снапшотами невидима.
Что дальше
Сейчас система работает в "snapshot mode" — каждый день независимо. Следующие шаги в порядке приоритета:
- CNAME unrolling для MX-таргетов — должно перенести часть "Unknown" в Microsoft 365 / Google Workspace и дать более точную оценку дуополии.
- BIMI-ключи (default._bimi.) — отдельная классификация brand-indicator-сетапов. Это уже follow-up по DMARC: BIMI требует p=quarantine|reject с pct=100 плюс VMC-сертификат.
- MTA-STS / DANE / TLS-RPT — следующий слой email security beyond authentication. У OpenINTEL эти записи запрашиваются, метрика по ним пока не считается.
- Сравнение со срезами по ccTLD — для устранения Tranco bias по региональным рынкам (отдельный datapoint для .ru, .cn, .de, .jp).
- Пересечения: домены с 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/провайдеры — присылайте, обновляются к следующему прогону.-Источник
|
