MX-запись для почты: настройка и безопасная смена

MX-запись сообщает отправляющим почтовым системам, куда передавать письма для вашего домена. Когда кто-то пишет на info@example.uz, сервер отправителя запрашивает MX для example.uz, выбирает подходящий узел и устанавливает с ним SMTP-соединение. Поэтому ошибка в одной DNS-записи может затронуть всю входящую почту домена, даже если веб-сайт продолжает работать как обычно.

Сам MX не создаёт почтовые ящики, не переносит старые письма и не подтверждает право сервера отправлять сообщения от имени домена. Для этого нужны отдельные компоненты: настроенные ящики, SMTP и IMAP, а также SPF, DKIM и DMARC. Их взаимосвязь подробно разобрана в статье SPF, DKIM и DMARC: как домен подтверждает подлинность писем.

Что находится внутри MX-записи

У MX есть три важных части: имя домена, приоритет и имя принимающего сервера. Условная запись выглядит так:

example.uz.  3600  IN  MX  10  mail.example.uz.

example.uz — домен, для которого принимают почту. 3600 — TTL, то есть время, в течение которого DNS-ответ разрешено хранить в кэше. 10 — приоритет. mail.example.uz — полное доменное имя почтового сервера.

Чем меньше число приоритета, тем предпочтительнее сервер. Если опубликованы MX с приоритетами 10 и 20, отправляющая система сначала попробует узел с числом 10, а при недоступности сможет обратиться к узлу с числом 20. Одинаковый приоритет допускает выбор между несколькими серверами, но сам по себе не превращает их в надёжный кластер: синхронизацию очередей, ящиков и правил доставки всё равно нужно проектировать отдельно.

Значением MX должно быть имя хоста, а не IP-адрес. У этого имени должна корректно разрешаться A-запись, AAAA-запись или обе. По правилам SMTP цель MX не должна быть псевдонимом CNAME. Для Cloudflare важно ещё одно различие: обычный почтовый хост публикуют в режиме DNS only. Стандартный HTTP-прокси Cloudflare не принимает SMTP-трафик вместо вашего почтового сервера.

Как сервер отправителя выбирает маршрут

Процесс начинается с DNS-запроса, а не с открытия сайта и не с проверки панели хостинга. Отправитель получает список MX, сортирует доступные цели по приоритету, разрешает имя выбранного узла в IP-адрес и пытается подключиться по SMTP. Если соединение временно не удалось, письмо обычно остаётся в очереди отправителя и повторяется позднее в соответствии с политикой этой системы.

Это объясняет два частых заблуждения. Во-первых, MX влияет прежде всего на входящий маршрут. Для исходящей почты клиент использует SMTP-сервер, указанный в его настройках; подлинность исходящих сообщений подтверждают другие механизмы. Во-вторых, резервный MX полезен только тогда, когда он действительно способен безопасно принять письмо для ваших адресов и передать его основной системе. Случайный второй сервер может создать новую точку отказа или канал для нежелательной почты.

Если MX отсутствует, стандарт SMTP предусматривает попытку доставки на адрес самого домена, но рассчитывать на такое поведение в рабочей конфигурации не стоит. Явная корректная MX-запись делает маршрут понятным, проверяемым и переносимым между провайдерами.

Что подготовить до изменения DNS

Переключение лучше начинать не с кнопки «Сохранить», а с короткой инвентаризации. Нужен полный список действующих адресов, алиасов, групп и пересылок. Каждый адрес, на который уже пишут клиенты или сервисы, должен иметь понятное назначение в новой системе. Иначе DNS начнёт направлять письма на сервер, который ещё не знает такого получателя.

До смены MX проверьте:

• созданы ли нужные ящики и алиасы;
• принимает ли новый сервер домен и конкретных получателей;
• доступен ли его SMTP-порт из внешней сети;
• совпадает ли имя сервера с его TLS-сертификатом;
• настроены ли SPF, DKIM и DMARC для исходящего потока;
• сохранён ли доступ к старой системе для переноса архива;
• известен ли прежний TTL и учтено ли время DNS-кэшей.

Старые письма не «переезжают через MX». MX определяет путь новых входящих сообщений. Архив копируют отдельным этапом, часто по IMAP, а результат сверяют по папкам и количеству сообщений. Полный порядок работ есть в материале Перенос корпоративной почты без потери входящих.

Как выполнить переключение без лишнего риска

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

Практическая последовательность выглядит так:

1. Зафиксируйте текущие MX, A/AAAA, SPF, DKIM и DMARC, а также время проверки.
2. Подготовьте и протестируйте новую почтовую систему до изменения публичного маршрута.
3. Уменьшите TTL заранее, если это допускает ваша DNS-панель и график работ.
4. Замените MX на выданное имя сервера и проверьте, что приоритет введён отдельным числом.
5. Убедитесь, что имя из MX разрешается в ожидаемый IP-адрес и не проксируется как веб-трафик.
6. Отправьте контрольные письма с нескольких независимых внешних сервисов.
7. Следите за журналами приёма, очередью и сообщениями об ошибках старого и нового сервера.
8. Не отключайте старую систему, пока не закончился согласованный период наблюдения и перенос архива.

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

Как проверить результат из нескольких точек

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

dig MX example.uz
dig A mail.example.uz

В Windows аналогичную проверку выполняют через nslookup -type=mx example.uz. Смотрите не только на имя MX, но и на приоритет, TTL и адрес его цели. Повторите запрос через другой публичный резолвер или внешнюю сеть: локальный провайдер мог сохранить старый ответ в кэше.

После DNS‑проверки подтвердите реальную доставку: отправьте письмо на новый ящик, ответьте с него и изучите технические заголовки. Для входящего теста важны факт принятия и правильный конечный ящик. Для исходящего — результат SPF, DKIM и DMARC, обратное имя сервера и реакция принимающей стороны. Эти проверки создают техническую основу доставляемости; итоговую фильтрацию определяет получатель.

Частые ошибки и их последствия

IP-адрес вместо имени. Поле назначения MX принимает доменное имя. IP задаётся в A или AAAA для этого имени.

MX у поддомена вместо корня. Запись для mail.example.uz не управляет письмами на user@example.uz. В DNS-панели имя корневой записи обычно обозначается @, пустым полем или самим доменом — формат зависит от интерфейса.

Проксирование почтового хоста. Оранжевое облако Cloudflare предназначено для поддерживаемого прокси-трафика. Почтовый DNS-хост для обычного SMTP оставляют DNS only.

Удаление старого MX до готовности ящиков. Новый сервер может отвергать реальных получателей. Сначала создают адреса и проверяют приём, затем переключают маршрут.

Слишком раннее отключение старого сервиса. Часть отправителей ещё может видеть закэшированный MX. Переходный период и наблюдение за обоими узлами помогают обнаружить такие доставки.

Ожидание, что MX исправит исходящую доставляемость. MX нужен для приёма. Проблемы исходящих писем исследуют по SMTP-ответам, заголовкам аутентификации, репутации и правилам получателя. Практический разбор есть в статье Почему письма попадают в спам и что проверять.

Короткий контрольный список

Перед сохранением убедитесь, что MX относится к правильному домену, содержит имя сервера и корректный приоритет. Проверьте A/AAAA этого имени, отсутствие случайного веб-прокси, готовность всех адресов и доступность старой системы. После изменения запросите публичный DNS, проведите входящий и исходящий тесты, сохраните технические заголовки и наблюдайте за очередями.

Главная мысль проста: MX — это указатель маршрута, а не миграция и не сертификат качества почты. Надёжное переключение получается из согласованной последовательности: подготовить сервер, проверить записи, изменить маршрут, протестировать реальную доставку и только затем завершать старую схему.

Источники

• RFC 5321: Simple Mail Transfer Protocol
• Cloudflare: DNS records for email
• Cloudflare: Network ports compatible with the proxy
• Google Workspace: Troubleshoot MX records