Почтовые сервисы Mail: пошаговое подключение своего домена

Если SPF и DKIM не настроены, исходящая почта теряет доверие у принимающих систем. Если домен не подтверждён, VK WorkMail не сможет использовать его как рабочую зону.

Почтовые сервисы Mail для бизнеса сейчас работают в составе VK Workspace. В интерфейсе можно подключить собственный домен, создать адреса сотрудников и перенести обслуживание почты на инфраструктуру Mail.ru. Но процесс требует последовательного выполнения нескольких независимых операций: подтвердить владение доменом, заменить MX, опубликовать SPF, настроить DKIM и дождаться обновления DNS.

Почта на собственном домене начинается не с создания ящика, а с корректной маршрутизации MX-записей.

Что именно подключается к Mail.ru

При подключении домена не создаётся отдельный почтовый сервер в инфраструктуре компании. Домен остаётся зарегистрирован у текущего регистратора, а DNS-зона продолжает обслуживаться либо его серверами, либо внешним DNS-провайдером. В VK Workspace регистрируется доменная область и создаётся конфигурация для работы с почтой.

Схема выглядит следующим образом:

• домен используется как адресная зона, например company.ru;
• DNS определяет, какой сервер принимает сообщения для этой зоны;
• MX-запись направляет входящую почту на emx.mail.ru;
• SPF сообщает принимающим системам, какие серверы имеют право отправлять сообщения от имени домена;
• DKIM добавляет криптографическую подпись к исходящим письмам;
• пользователи работают с ящиками через веб-интерфейс Mail.ru, мобильные приложения или почтовые клиенты.

Адреса сотрудников после настройки могут иметь вид user@company.ru. При этом сам домен должен быть доступен для технической проверки. Заблокированные и просроченные домены подключить нельзя. Кириллические доменные зоны, включая .рф и .рус, VK WorkMail официально не поддерживает.

Проверяйте доменную зону до начала работ. Если домен не делегирован, истёк срок регистрации или DNS-серверы недоступны, любые действия в панели VK Workspace завершатся ошибкой проверки.

Подготовка домена перед настройкой

Сначала определите, где редактируются DNS-записи. Это может быть панель регистратора, хостинг-провайдера, DNS-сервис или корпоративная система управления зоной. Панель VK Workspace не меняет записи автоматически, если DNS обслуживается внешней площадкой.

Зафиксируйте текущую конфигурацию зоны. Сохраните существующие MX, TXT, CNAME и другие записи. Не удаляйте их без проверки. Особенно опасно стирать TXT-записи: среди них могут находиться SPF для других сервисов, записи подтверждения владения, параметры облачных платформ и политики безопасности.

Перед изменениями составьте таблицу:

Главная ошибка на этом этапе — попытка добавить несколько SPF-записей. Для одного домена должна использоваться единая SPF-политика. Если уже опубликована запись с v=spf1, добавьте разрешение Mail.ru в неё, а не создавайте вторую TXT-запись с новым v=spf1.

Подтверждение владения доменом

Откройте VK Workspace и перейдите к подключению домена. Система предложит подтвердить контроль над DNS-зоной. Доступно четыре способа.

HTML-файл в корне сайта

Сервис выдаёт файл, который необходимо разместить в корневом каталоге сайта. После загрузки VK Workspace обращается к заданному адресу и проверяет наличие файла.

Метод подходит, если:

• сайт работает;
• есть доступ к файловой системе или панели хостинга;
• веб-сервер корректно отдаёт статические файлы;
• домен открывается без обязательной авторизации.

Проверьте, что файл доступен именно в корне домена, а не во вложенном каталоге. Если сайт перенаправляет HTTP на HTTPS, проверка должна проходить по итоговому адресу. CDN, WAF и правила доступа могут блокировать запрос к файлу.

Meta-тег в секции head

Второй вариант — добавить выданный сервисом meta-тег в секцию head главной страницы сайта. Этот метод требует доступа к шаблону или CMS.

Проверяйте результат в исходном HTML-коде страницы. Наличие тега в редакторе CMS недостаточно, если шаблон не опубликован или тег удаляется системой оптимизации. Кэш сайта также может отдавать старую версию страницы. После публикации очистите кэш на уровне CMS, CDN и прокси, если они используются.

TXT-запись DNS

Наиболее универсальный способ — создать TXT-запись для подтверждения домена. В панели VK Workspace будет показано значение с префиксом mailru-domain. Его необходимо скопировать без изменений.

Обычно поле имени записи в DNS-панелях заполняется одним из вариантов:

• @;
• пустое значение;
• полное доменное имя.

Конкретное поведение зависит от панели. Если интерфейс автоматически добавляет имя домена, не вводите полное имя повторно. Иначе можно получить запись в неправильном месте, например company.ru.company.ru.

После публикации TXT-записи запустите проверку в VK Workspace. Если запись не обнаружена, сначала проверьте авторитетные DNS-серверы, а не локальный кэш компьютера.

Делегирование NS-серверов

Четвёртый способ — передать обслуживание DNS-серверов Mail.ru через делегирование NS. Это наиболее масштабное изменение. Оно затрагивает не только почту, но и весь домен: сайт, поддомены, сервисы аналитики, VPN, сертификаты, интеграции и корпоративные приложения.

Не выполняйте делегирование без инвентаризации зоны. Сначала перенесите все требуемые записи на новую площадку, затем проверьте их через внешние DNS-проверки. Ошибка в NS может одновременно отключить сайт, API, поддомены и почту.

Для обычного подключения почты предпочтительнее TXT-подтверждение. Оно изменяет только одну запись и не передаёт управление всей DNS-зоной.

Настройка MX: перевод входящей почты

После подтверждения домена измените MX-запись. Основной сервер Mail.ru — emx.mail.ru. Рекомендуемый приоритет — 10. В отдельных DNS-панелях или конфигурациях используется значение 0; ориентируйтесь на инструкцию, отображаемую в рабочем пространстве и на формат конкретного провайдера.

Для корня домена запись имеет примерно такую структуру:

Если в зоне остаются старые MX-записи с более высоким приоритетом, часть отправителей продолжит доставлять сообщения прежнему провайдеру. Это создаёт расщеплённую маршрутизацию. Один сотрудник получит письмо в Mail.ru, другой — в старый ящик. Такая ситуация особенно часто возникает после добавления новой MX-записи без удаления устаревших маршрутов.

Порядок действий:

1. Зафиксируйте старые MX-записи.

2. Добавьте MX для emx.mail.ru.

3. Удалите старые MX, если миграция полностью завершена.

4. Проверьте отсутствие MX-записей, указывающих на прежний сервис.

5. Запустите проверку домена в VK Workspace.

6. Отправьте тестовое сообщение с внешнего ящика.

7. Проверьте доставку на новый адрес.

8. Отправьте ответ и убедитесь, что исходящее сообщение также проходит.

Не меняйте MX до создания пользователей, если сотрудники должны сразу получать новую почту. Но и не рассчитывайте на мгновенную миграцию маршрута. Обновление DNS-записей в глобальной сети занимает от 2 до 72 часов. Разные отправляющие серверы могут видеть старую и новую конфигурацию в течение этого периода.

MX определяет доставку, но не доказывает подлинность отправителя. Для репутации домена нужны SPF и DKIM.

SPF: разрешение на отправку

SPF публикуется как TXT-запись для корня домена. Стандартное значение для Mail.ru:

v=spf1 redirect=_spf.mail.ru

Если от имени домена отправляют дополнительные системы — CRM, сервис рассылок, сайт, helpdesk, ERP — их источники необходимо сохранить в общей SPF-политике. В такой конфигурации используется вариант с включением Mail.ru:

v=spf1 include:_spf.mail.ru ~all

Эти значения нельзя механически публиковать одновременно. Две TXT-записи, каждая из которых начинается с v=spf1, создают конфликт. Принимающий сервер выберет некорректную или неопределённую политику.

Проверьте существующий SPF:

• найдите все TXT-записи для корня домена;
• определите, какая из них начинается с v=spf1;
• перечислите все легитимные отправляющие сервисы;
• добавьте _spf.mail.ru в действующую политику;
• удалите дублирующие SPF-записи;
• проверьте итоговую запись через DNS-инструмент.

Параметр ~all означает мягкую обработку источников, не включённых в список. Для переходного периода это обычно безопаснее жёсткого запрета. Но SPF не заменяет DKIM и не защищает адрес от подмены во всех сценариях. Он проверяет сервер отправки, а не содержание письма и не факт, что пользователь действительно инициировал отправку.

Учитывайте ограничения SPF по числу DNS-запросов. Сложная политика с большим количеством include, a, mx и redirect может выйти за допустимый предел обработки. В результате часть принимающих систем перестанет корректно оценивать запись.

DKIM: подпись исходящих сообщений

DKIM настраивается в панели VK Workspace. Сервис генерирует индивидуальный ключ для домена. Публичная часть ключа публикуется в DNS как TXT-запись для поддомена:

mailru._domainkey

Имя записи не следует заменять на произвольное. DKIM-селектор является частью механизма поиска ключа. Если изменить его, почтовый сервер Mail.ru будет подписывать сообщения одним именем, а DNS-проверка будет искать ключ по другому.

Базовый порядок:

1. Откройте настройки домена в VK Workspace.

2. Найдите раздел DKIM.

3. Сгенерируйте или получите уникальный ключ.

4. Создайте TXT-запись для mailru._domainkey.

5. Вставьте значение ключа без сокращений и переносов.

6. Сохраните запись.

7. Дождитесь обновления DNS.

8. Запустите проверку DKIM в панели.

9. Отправьте тестовое письмо на внешний адрес.

10. Изучите заголовки сообщения и найдите результат dkim=pass.

Некоторые DNS-панели автоматически разбивают длинные TXT-значения на фрагменты. Это допустимо, если итоговый DNS-ответ возвращает единое корректное значение. Не добавляйте кавычки вручную, если интерфейс панели вставляет их самостоятельно.

Типовые ошибки DKIM:

• запись создана для @, а не для mailru._domainkey;
• селектор введён с опечаткой;
• значение ключа скопировано не полностью;
• TXT опубликован в неправильной DNS-зоне;
• старый кэш скрывает новую запись;
• исходящие сообщения на самом деле отправляет не Mail.ru, а внешний сервис;
• домен используется несколькими системами, но DKIM настроен только для одной.

Если отправка выполняется через сервис рассылок, подпись Mail.ru не подтверждает сообщения, отправленные этим сервисом. Для каждой внешней системы требуется отдельная настройка DKIM и SPF.

Создание ящиков и подключение клиентов

После подтверждения домена создайте пользователей в VK Workspace. Не смешивайте технические адреса и персональные ящики. Для общих функций используйте отдельные адреса или группы, если это предусмотрено текущей конфигурацией рабочего пространства. Адрес info@, персональные ящики и служебные уведомления должны иметь понятное назначение.

Перед массовым созданием учётных записей определите:

• какие адреса должны существовать постоянно;
• какие адреса используются только для переадресации;
• кто имеет доступ к общим ящикам;
• какие пользователи работают через веб-интерфейс;
• каким сотрудникам нужны мобильные приложения;
• какие клиенты используют IMAP или другие способы подключения;
• где хранятся резервные копии и экспорт переписки.

Для браузерной работы используется веб-интерфейс Mail.ru. На мобильных устройствах применяется почтовое приложение. В настольных клиентах параметры подключения зависят от актуальных настроек сервиса и конкретного приложения. Не переносите настройки старого провайдера без проверки. Имя сервера, порт, тип шифрования и способ авторизации должны соответствовать документации VK Workspace.

Проверяйте не только входящие сообщения. Для каждого тестового ящика выполните полный цикл:

1. Отправьте письмо с внешнего адреса в новый ящик.

2. Ответьте на него из VK WorkMail.

3. Откройте сообщение в получающей системе.

4. Проверьте SPF, DKIM и DMARC в заголовках.

5. Отправьте письмо с вложением.

6. Проверьте доставку на адрес другого почтового провайдера.

7. Убедитесь, что ответ возвращается в новый ящик.

8. Проверьте работу с мобильного устройства и почтового клиента.

Размер одного вложения без использования «Облака Mail.ru» ограничен 30 МБ. Более крупные файлы передавайте через облачное хранилище, а в письме размещайте ссылку с контролируемыми правами доступа. Не пытайтесь обходить ограничение разбиением файла на десятки вложений: это ухудшает контроль, усложняет аудит и увеличивает вероятность блокировки сообщения.

Проверка после изменения DNS

Проверяйте DNS с внешнего узла. Локальный компьютер может использовать старый ответ из кэша. Срок обновления зависит от TTL, цепочки DNS-серверов и кэширования у отправляющих систем. Даже после успешной проверки в одной сети другой оператор может видеть прежние записи.

Минимальный набор проверок:

• MX корневого домена указывает на emx.mail.ru;
• старые MX удалены или имеют осознанное назначение;
• для корня опубликована единая SPF-политика;
• SPF содержит разрешение _spf.mail.ru;
• mailru._domainkey возвращает TXT с публичным DKIM-ключом;
• запись подтверждения домена видна извне;
• в VK Workspace отображается подтверждённый статус;
• тестовое сообщение доходит с внешних систем;
• заголовки исходящего письма содержат успешные результаты проверки.

В Linux и macOS базовые проверки можно выполнять командами dig MX company.ru, dig TXT company.ru и dig TXT mailru._domainkey.company.ru. В Windows используйте nslookup -type=MX company.ru и nslookup -type=TXT company.ru. Для проверки конкретного DNS-резолвера задайте его явно: dig @8.8.8.8 MX company.ru или nslookup company.ru 1.1.1.1.

Не делайте вывод по одному DNS-серверу. Сравните ответы нескольких публичных резолверов. Если один из них показывает старую MX, изменения ещё не распространились полностью.

Траблшутинг: где искать отказ

Домен не подтверждается

Проверьте метод подтверждения. Для TXT-метода убедитесь, что запись создана для корня домена и содержит префикс mailru-domain. Для HTML-файла проверьте доступность файла из внешней сети. Для meta-тега откройте исходный код опубликованной страницы, а не редактор CMS.

Если используется делегирование NS, запросите актуальные NS у регистратора и убедитесь, что новая DNS-зона содержит все необходимые записи. Частичная миграция DNS не считается рабочей конфигурацией.

Почта продолжает приходить в старый сервис

Проверьте MX через внешний резолвер. Если старые записи ещё видны, дождитесь завершения распространения. Если старые записи уже удалены, проверьте кэш отправляющей стороны и настройки локального клиента.

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

Исходящие письма попадают в спам

Начните с заголовков. Проверьте spf=pass и dkim=pass. Затем убедитесь, что отправитель использует именно тот домен, для которого опубликованы записи. Проверьте наличие конфликтующих SPF-записей и корректность DKIM-селектора.

Не меняйте сразу несколько политик. Сначала исправьте SPF, затем проверяйте DKIM, после этого анализируйте DMARC и репутацию домена. Массовое изменение параметров лишает диагностику последовательности.

VK Workspace видит запись, но считает её неверной

Сравните имя и значение записи посимвольно. Частые причины:

• DNS-панель добавила домен к имени автоматически;
• значение TXT обрезано;
• запись создана у регистратора, хотя авторитетными являются другие NS;
• существует несколько записей одного типа;
• используется старый кэш;
• в значении присутствуют лишние пробелы или переносы.

В таких случаях проверяйте не форму в панели регистратора, а фактический ответ DNS-командой dig или nslookup.

Консольный набор для финальной проверки

Перед переводом домена в рабочий режим выполните последовательность:

1. dig NS company.ru — определить авторитетные DNS-серверы.

2. dig MX company.ru — проверить маршрут входящей почты.

3. dig TXT company.ru — найти SPF и запись подтверждения.

4. dig TXT mailru._domainkey.company.ru — получить DKIM-ключ.

5. dig @8.8.8.8 MX company.ru — проверить внешний резолвер.

6. dig @1.1.1.1 TXT company.ru — сравнить TXT-ответ у другого оператора.

7. nslookup -type=MX company.ru — выполнить аналогичную проверку в Windows.

8. nslookup -type=TXT mailru._domainkey.company.ru — проверить DKIM-селектор.

9. Отправить тестовое письмо на внешний адрес.

10. Изучить заголовки и зафиксировать результаты SPF, DKIM и DMARC.

Команды заменяют домен company.ru на фактическое имя зоны. Не используйте внутренний DNS как единственный источник результата: корпоративный резолвер может возвращать локальные ответы, отличающиеся от публичной зоны.

Итоговая последовательность

Подключение собственного домена к почтовому сервису Mail.ru выполняйте в таком порядке:

1. Проверьте регистрацию и доступность домена.

2. Убедитесь, что доменная зона не кириллическая.

3. Определите авторитетные DNS-серверы.

4. Сохраните текущие записи зоны.

5. Подтвердите владение доменом через HTML-файл, meta-тег, TXT или NS.

6. Создайте MX для emx.mail.ru.

7. Удалите неиспользуемые старые MX.

8. Настройте единую SPF-запись с разрешением _spf.mail.ru.

9. Опубликуйте DKIM для mailru._domainkey.

10. Создайте пользователей и рабочие адреса.

11. Проверьте доставку из внешних систем.

12. Проверьте заголовки и состояние DNS через 2–72 часа после изменений.

Основной риск при миграции — не интерфейс VK Workspace, а расхождение между ожидаемой и фактической DNS-конфигурацией. Контролируйте авторитетную зону, не создавайте дублирующий SPF, не оставляйте случайные MX и проверяйте DKIM по реальным заголовкам сообщений. После этого почта на собственном домене работает как управляемая инфраструктура, а не как набор ящиков с непредсказуемой маршрутизацией.