Почтовый сервер Mail.ru: пошаговое подключение и настройка DNS
Подключение почтового сервера Mail.ru к собственному домену начинается с DNS-зоны. Ошибка «почта настроена, но письма не приходят» часто означает, что MX-запись всё ещё указывает на прежнего провайдера.
Исходящая почта требует отдельной настройки: SPF разрешает отправку, DKIM добавляет подпись, а DMARC проверяет, согласуются ли результаты с доменом в поле From. Если проверка DMARC не проходит, дальнейшая обработка зависит от политики домена и правил принимающего сервера.
У этих записей разные задачи. MX направляет входящие письма, SPF описывает разрешённые источники исходящей почты, DKIM позволяет получателю проверить подпись. DMARC связывает результаты SPF и DKIM с адресом отправителя, который видит получатель. Поэтому настройку стоит вести последовательно: сначала подтвердить права на домен, затем переключить маршрутизацию и настроить исходящую почту.
Подготовка домена и подтверждение прав в VK WorkMail
Проверьте исходное состояние зоны
Перед изменением DNS зафиксируйте текущие записи. Удаляйте их из рабочего набора только после того, как выясните, какие сервисы от них зависят.
1. Откройте панель управления DNS у регистратора или хостинга. Убедитесь, что домен управляется из аккаунта, где можно менять TXT-, MX- и NS-записи.
2. Проверьте существующие MX-записи. При переходе на VK WorkMail записи прежнего почтового провайдера нужно будет убрать.
3. Найдите TXT-записи, связанные с почтой: SPF, DKIM, DMARC и подтверждение домена. Старые разрешения SPF могут понадобиться, если через прежнего провайдера ещё отправляются письма.
4. Составьте список всех источников отправки: почтовые ящики Mail.ru, сайт, CRM, корпоративный SMTP и сервисы рассылок. Без него легко разрешить в SPF только Mail.ru и случайно нарушить отправку с сайта или из CRM.
5. Посмотрите текущий TTL записей, которые планируете менять. Если провайдер позволяет, заранее уменьшите TTL и дождитесь окончания срока кэширования старых ответов.
Аккаунт VK WorkMail должен быть создан до начала настройки. В панели понадобятся домен и значения, сгенерированные для подтверждения прав и DKIM. Не пытайтесь восстановить токен или ключ по примеру из чужой инструкции: используйте именно значения для своего домена.
Выберите способ подтверждения прав
VK WorkMail поддерживает несколько способов подтверждения домена. Подойдёт один из них.
| Способ | Где выполняется | Что требуется |
|---|---|---|
| DNS TXT | В DNS-зоне домена | Добавить проверочную запись вида mailru-domain:... |
| HTML-файл | В корне веб-сервера | Загрузить сгенерированный файл |
| Метатег | В HTML сайта | Вставить сгенерированный тег |
| Делегирование NS | В панели регистратора | Передать управление DNS-зоной NS-серверам сервиса |
Если DNS уже управляется из доступной вам панели, TXT обычно проще всего: скопируйте значение из VK WorkMail целиком, вместе с префиксом mailru-domain:. Имя записи зависит от интерфейса провайдера. Для корня зоны это может быть @, полное имя домена или пустое поле. После сохранения проверьте, что запись действительно появилась по нужному имени.
HTML-файл и метатег подходят, когда у вас есть доступ к сайту, но нет возможности менять DNS. Файл размещают в корне веб-сервера, метатег добавляют в HTML главной страницы. При делегировании NS меняется управление всей зоной. Перед переключением перенесите записи сайта, почты и других сервисов: иначе после передачи зоны часть ресурсов может перестать работать.
Подтверждение прав на домен не создаёт MX, SPF и DKIM. Эти записи настраиваются отдельно.
После успешной проверки не удаляйте TXT-токен без необходимости. Сначала завершите подключение и убедитесь, что сервис принимает настройки домена.
Настройка MX-записи для входящей почты
MX-запись указывает, куда другие почтовые системы должны передавать письма для вашего домена. Для корпоративной почты Mail.ru в DNS используется emx.mail.ru.
Порядок настройки
1. Откройте DNS-зону домена.
2. Если вы переводите почту с другого провайдера, удалите его MX-записи после того, как подготовили ящики и завершили перенос.
3. Добавьте MX-запись для корня домена. В поле имени укажите @ или полное имя, если так устроена панель DNS.
4. Укажите приоритет 10.
5. В качестве цели задайте emx.mail.ru.
6. Сохраните запись и проверьте её через публичный DNS.
Пример:
| Имя | Тип | Приоритет | Значение |
|---|---|---|---|
@ | MX | 10 | emx.mail.ru. |
Точка в конце emx.mail.ru. обозначает полное доменное имя. Одни панели добавляют её автоматически, другие отображают адрес без точки. Важно, чтобы цель записи осталась emx.mail.ru, а интерфейс не приписал к ней имя вашего домена.
Для корпоративного домена используйте указанное значение, а не адреса вроде mx.mail.ru или pop.mail.ru: они не заменяют точку входа VK WorkMail для этой настройки.
Если DNS делегирован NS-серверам VK WorkMail, запись создаётся в панели сервиса. Если зона остаётся у регистратора или хостинга, измените MX там. После переключения проверьте, что сторонние MX не остались в зоне: при нескольких почтовых провайдерах отправители могут выбирать разные маршруты, и часть писем окажется не в том ящике.
Новый MX не переносит старые письма автоматически. Если вы меняете провайдера, отдельно продумайте миграцию почтовых ящиков и момент переключения, чтобы не потерять сообщения, поступающие во время перехода.
Настройка SPF для отправки писем
SPF описывает, каким серверам разрешено отправлять почту от имени домена. Проверка использует технический адрес отправителя в MAIL FROM, который может отличаться от адреса в видимом поле From. Поэтому SPF со статусом pass ещё не гарантирует, что DMARC тоже пройдёт.
Оставьте одну SPF-запись
SPF публикуется в TXT-записи корня домена. Для домена должна существовать одна логическая запись, начинающаяся с v=spf1. Не создавайте отдельную SPF-запись для Mail.ru, сайта и CRM: несколько самостоятельных записей могут привести к ошибке PermError.
| Источники отправки | Пример значения SPF | Как применять |
|---|---|---|
| Только инфраструктура Mail.ru | v=spf1 redirect=_spf.mail.ru | Используйте, если исходящая почта идёт только через Mail.ru |
| Mail.ru и собственный или сторонний SMTP-сервер | v=spf1 ip4:192.0.2.10 include:_spf.mail.ru ~all | Замените пример IP реальным адресом и добавьте разрешения остальных отправителей |
Адрес 192.0.2.10 здесь служит документационным примером, а не рабочим адресом для копирования. В реальной записи используйте IP вашего сервера или механизм, который рекомендует соответствующий почтовый сервис.
redirect и include применяются по-разному. redirect=_spf.mail.ru передаёт проверку политике указанного домена. Такой вариант подходит, если отправка идёт только через Mail.ru. include:_spf.mail.ru подключает разрешения Mail.ru к общей SPF-записи домена. Он нужен, когда почту отправляют также другие системы.
Если домен уже использовался для отправки через сторонний сервис, перенесите нужные разрешения в единственную SPF-запись. Старую запись удаляйте только после проверки, что все источники отправки учтены. Порядок действий такой:
1. Найдите TXT-записи, содержащие v=spf1.
2. Определите, какие серверы и сервисы действительно отправляют почту от имени домена.
3. Соберите разрешения для этих источников в одну запись.
4. Удалите лишние SPF-записи.
5. Проверьте результат через публичный DNS и отправьте тестовое письмо.
DNS-панели могут отображать длинное значение TXT несколькими фрагментами. Это не обязательно означает, что создано несколько записей: важно, чтобы в зоне оставался один логический SPF-ресурс. А вот две отдельные записи с v=spf1 могут вызвать PermError.
У SPF есть ограничение на количество DNS-запросов, выполняемых во время проверки. В большинстве реализаций учитывается предел в десять lookup. Длинная цепочка include: и устаревшие разрешения повышают риск превышения лимита, поэтому не оставляйте в записи сервисы, которые уже не отправляют почту.
Если сайт отправляет письма через собственный SMTP или хостинг, настройки Mail.ru не распространяются на него автоматически. Авторизуйте отправителя отдельно и добавьте его разрешения в SPF. Для подписи писем сайта также потребуется настройка DKIM на стороне сервиса, через который сайт отправляет почту.
Одна SPF-запись описывает все разрешённые источники домена. Вторая запись с v=spf1 не становится запасным маршрутом.Настройка DKIM через панель VK WorkMail
DKIM добавляет к письму криптографическую подпись. Получатель использует открытый ключ из DNS, чтобы проверить подпись и убедиться, что подписанные данные не были изменены. DKIM не шифрует письмо, а помогает обнаруживать подмену содержимого и подтверждать связь подписи с доменом.
Получите и опубликуйте ключ
1. Откройте панель VK WorkMail.
2. Перейдите в раздел «Состояние сервера».
3. Найдите параметры DKIM для нужного домена.
4. Скопируйте сгенерированный публичный ключ.
5. Создайте TXT-запись в DNS-зоне.
Запись будет выглядеть примерно так:
| Имя | Тип | Значение |
|---|---|---|
mailru._domainkey | TXT | v=DKIM1; k=rsa; p=... |
Вместо ... вставьте полный ключ из панели. Не сокращайте его и не меняйте символы в v=DKIM1, k=rsa и p=. Если интерфейс DNS просит указать только субдомен, укажите mailru; полное имя записи будет включать ._domainkey и ваш домен. Поле может называться Name, Host или Subdomain.
Публичный ключ Mail.ru относится к письмам, которые отправляет инфраструктура сервиса. Письма сайта или CRM, направленные через сторонний SMTP, не получат эту подпись автоматически. Для каждого такого отправителя проверьте его собственную настройку DKIM.
После публикации ключа отправьте тестовое письмо и изучите служебные заголовки. DKIM=Pass означает, что подпись проверена. DKIM=None обычно указывает на отсутствие подписи. При DKIM=fail проверьте селектор и точность TXT-значения, затем убедитесь, что DNS уже отдаёт новый ключ.
При плановой смене ключа разумно сначала опубликовать новый селектор, проверить отправку с ним и только потом убирать старую запись. Так у получателей останется возможность проверить письма, отправленные до переключения.
Внедрение DMARC и контроль источников
DMARC сообщает принимающим серверам, как домен предлагает обработать письма, которые не проходят проверку или не согласуются с доменом в поле From. Это политика домена, а не команда, которая гарантированно заставляет любой сервер выполнить конкретное действие.
При внешнем управлении DNS запись DMARC создаётся вручную. Для неё используют имя _dmarc и TXT-тип.
Начните с наблюдения
Минимальная запись с политикой наблюдения выглядит так:
| Имя | Тип | Значение |
|---|---|---|
_dmarc | TXT | v=DMARC1; p=none |
p=none сообщает о политике домена, но сам по себе не запрашивает агрегированные отчёты. Чтобы получать их, добавьте параметр rua с адресом для отчётов, например:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Указанный почтовый ящик должен существовать и принимать служебные сообщения. Если отчёты не нужны или адрес для них ещё не подготовлен, оставьте p=none без rua: это не включает отправку агрегированных отчётов.
Отчёты помогают увидеть, какие источники отправляют почту от имени домена и как проходят проверки SPF и DKIM. Они не заменяют проверку настроек каждого сервиса: агрегированные данные нужно соотнести с сайтом, CRM, платформами рассылки и другими разрешёнными отправителями.
Проверьте alignment
Для прохождения DMARC недостаточно, чтобы SPF или DKIM просто возвращали pass. Как минимум один из этих механизмов должен пройти проверку и быть согласован с доменом в видимом поле From.
Для корпоративной почты полезно проверить, что:
- технический домен отправителя в MAIL FROM связан с организацией;
- SPF проходит для фактического отправляющего сервера;
- домен в DKIM-подписи согласован с доменом в From;
- письма от сайта, CRM и рассылочных платформ проходят проверку не только при тестовой отправке, но и в реальном сценарии.
SPF может завершиться успешно, а DMARC при этом вернуть fail. Например, письмо отправлено через стороннюю платформу, у которой MAIL FROM использует другой домен, а согласованной DKIM-подписи нет. Пересылка тоже способна нарушить SPF: принимающая система видит уже не исходный сервер. Для регулярных рассылок проверьте поддержку DKIM и настройку домена отправителя на стороне платформы.
Ужесточайте политику после проверки источников
После того как легитимные отправители найдены и настроены, можно перейти от p=none к более строгой политике. Сначала проверьте отчёты и устраните ошибки, затем меняйте запись на p=quarantine. Эта политика предлагает принимающему серверу помещать не прошедшие DMARC письма в карантин, но конкретный сервер может применить собственные правила и переопределить рекомендацию домена.
p=reject задаёт более строгую политику и просит отклонять сообщения, не прошедшие проверку DMARC. Но и здесь решение об обработке принимает получающая сторона. Прежде чем переходить к такой настройке, убедитесь, что через домен не отправляются забытые автоматические письма, уведомления сайта, счета или сообщения из редко используемых сервисов.
Для поддоменов политику можно задать параметром sp. Это полезно, если домен верхнего уровня и отдельные поддомены отправляют почту по разным сценариям. Меняйте политику осознанно: жёсткая настройка, которая не учитывает легитимного отправителя, способна ухудшить доставку нужных писем.
Проверка конфигурации и устранение ошибок
Сверьте итоговый набор записей
После настройки зона обычно содержит следующие записи:
| Назначение | Тип | Имя | Значение |
|---|---|---|---|
| Подтверждение домена | TXT | @ | Строка mailru-domain:... из панели |
| Входящая почта | MX | @ | Приоритет 10, цель emx.mail.ru. |
| SPF | TXT | @ | Одна запись v=spf1... |
| DKIM | TXT | mailru._domainkey | v=DKIM1; k=rsa; p=... |
| DMARC | TXT | _dmarc | v=DMARC1; p=... |
Значения в таблице служат ориентиром. Для верификации и DKIM всегда копируйте персональные значения из панели, а в DMARC указывайте ту политику и адрес отчётов, которые выбрали для своего домена.
Если настройка не проходит, проверьте наиболее частые причины:
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| Права на домен не подтверждены | Неверный токен или имя TXT-записи | Сверить запись с панелью и проверить, где именно опубликован TXT |
| MX показывает старого провайдера | Сторонняя запись осталась в зоне или резолвер хранит старый ответ | Проверить авторитетный DNS и публичный резолвер |
SPF возвращает PermError | В зоне несколько SPF-записей или превышен лимит lookup | Объединить разрешения и убрать неиспользуемые include: |
SPF возвращает fail | Источник отправки не указан в SPF | Проверить фактический сервер и добавить корректный механизм |
DKIM возвращает fail | Ошибка в ключе, имени записи или селекторе | Сверить TXT с панелью и проверить запись по полному имени |
DMARC возвращает fail при SPF=Pass | Нет alignment между доменом отправителя и From | Сверить домены MAIL FROM, From и DKIM-подписи |
| Письма с сайта не подписаны DKIM | Отправка идёт через отдельный SMTP без настроенного ключа | Проверить настройки почтового сервиса сайта |
Учитывайте TTL и кэш DNS
Изменения не появляются одновременно у всех получателей. Авторитетный DNS может начать отдавать новое значение сразу после сохранения, но рекурсивные резолверы продолжают использовать ответы из кэша в пределах прежнего TTL. Поэтому при плановом переключении TTL полезно уменьшить заранее и дождаться окончания срока кэширования старых ответов.
Редактирование записи не сбрасывает TTL уже закэшированного ответа у резолвера. Если изменить значение повторно, резолвер всё равно может продолжать отдавать старое значение до истечения TTL, отсчитанного с момента получения старого ответа. Проверяйте отдельно авторитетные серверы и публичные резолверы: расхождение между ними часто означает именно кэширование, а не ошибку в панели.
Публичные DNS-ответы могут обновляться с разной скоростью. Не переключайте запись туда-сюда только потому, что один резолвер пока показывает прежнее значение. Сначала проверьте, что авторитетный сервер отдаёт нужные данные, затем дождитесь обновления кэшей.
Проверьте DNS из консоли
Замените example.com на свой домен:
1. dig MX example.com +short покажет MX. В ответе должна быть цель emx.mail.ru. с нужным приоритетом.
2. dig TXT example.com +short покажет TXT-записи корня. Найдите SPF и убедитесь, что логическая запись с v=spf1 одна.
3. dig TXT mailru._domainkey.example.com +short покажет ключ DKIM.
4. dig TXT _dmarc.example.com +short покажет политику DMARC и, если он задан, адрес агрегированных отчётов в rua.
5. dig +trace MX example.com поможет проследить путь запроса до авторитетных NS-серверов.
Если dig недоступен, используйте nslookup с типами записей MX и TXT. Для DKIM и DMARC укажите полное имя каждой записи.
Завершайте настройку не по одному зелёному индикатору в панели, а после проверки реальной отправки и приёма. Отправьте письмо с корпоративного ящика на внешний адрес, проверьте его заголовки, затем ответьте на него и убедитесь, что ответ приходит в нужный ящик. Отдельно протестируйте письма с сайта и других сервисов, если они используют тот же домен.
Так видны ошибки, которые не обнаруживаются простой проверкой MX: забытый источник отправки, несовпадение доменов в DMARC или DKIM, настроенный только для части трафика. Подключение корпоративной почты Mail.ru заканчивается не публикацией записей, а подтверждением того, что DNS направляет входящие письма и разрешает все нужные исходящие отправители.