Доставляемость почты в Рунете в 2026 году: кто держит почту и почему это важно

27 августа 2026 года мы запросили записи MX у 600 доменов (по 150 на зону) и сопоставили их с известными почтовыми службами. Из 150 доменов .ru почту принимают 94:

Для сравнения — международные зоны:

Оговорки: провайдер определяется по имени хоста в записи MX, поэтому пересылка через промежуточный шлюз учитывается как шлюз. Это домены, которые кто-то приводил в наши инструменты, а не случайный срез зоны; сравнение зон корректно, они набраны одинаково.

Первое: рынок раздроблен. В .com две компании закрывают 37% доменов с почтой. В .ru крупнейший игрок берёт 20%, а чтобы набрать те же 37%, нужны уже три. Это меняет практику: инструкции по настройке SPF, ограничения на рассылку и способы разбора инцидентов у пяти провайдеров разные, и универсального «как у всех» не существует.

Второе: четверть доменов сидит на почте хостинг-компании. Reg.ru, Beget и Timeweb вместе — 26% доменов .ru с почтой. В международных зонах эта категория практически отсутствует.

Это важно для доставляемости напрямую. Почта хостера обычно уходит с адресов, общих для многих клиентов: репутация отправляющего адреса общая. Один сосед по серверу, начавший рассылать спам, портит доставку всем остальным, и повлиять на это нельзя — рычаг у хостера, а не у вас. Специализированные почтовые службы разделяют потоки клиентов заметно строже.

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

Из тех же данных получается неожиданное сочетание. В .ru 59% доменов отдали почту внешней службе — против 45% в .com. То есть российские владельцы чаще передают почту тому, кто в ней разбирается.

При этом по нашему же замену аутентификации строгий SPF стоит у 8% доменов .ru против 34% в .com, а DMARC — у 36% против 56%.

Сочетание странное, потому что провайдер обычно даёт готовую строку SPF в инструкции по подключению. Наиболее правдоподобное объяснение: запись ставится один раз при подключении — в мягком режиме ~all, который провайдер и рекомендует как безопасный старт, — и больше к ней никто не возвращается. Мягкий режим задуман как временный, но временем никто не управляет.

Это тот же мотив, что мы видели в других замерах: HSTS без includeSubDomains, robots.txt без реальных запретов. Настройка доводится до состояния «работает» и не доводится до состояния «защищает».

1. Начните с того, кто отправляет. Если почта на хостинге вместе с сайтом — проверьте, не числится ли исходящий адрес в списках. Это самая частая причина внезапного падения доставки, и она не связана с вашими настройками.
2. Сверьте SPF со списком провайдера. При смене почтовой службы старая запись часто остаётся: в ней перечислены серверы, которые вы уже не используете, а новых нет.
3. Проверьте лимит в десять DNS-запросов. Он расходуется вложенными include, и при превышении запись перестаёт действовать целиком — молча, без ошибки.
4. Включите DMARC на p=none с отчётами. Через пару недель вы увидите полный список отправителей от вашего имени — обычно там находится забытая рассылка или система, о которой не помнили.
5. Не ужесточайте SPF до -all, пока отчёты не чистые. Порядок именно такой: сначала увидеть, потом запрещать.

Проверить записи своего домена можно в проверке почтовых записей, а разобрать заголовки конкретного недоставленного письма — в анализаторе заголовков.