Содержание12
- Что такое MX-запись?
- Как отправитель находит сервер
- Приоритет MX: какой сервер получит письмо первым
- Примеры MX-записей для Яндекса, Google и своего домена
- Как сменить MX-запись?
- MX-запись и сайт: что на что влияет
- Как проверить MX-запись?
- Частые ошибки в MX-записях
- Домен без почты: Null MX
- С чего начать
- Частые вопросы
- Источники
MX-запись — строка в DNS домена, которая говорит отправителям, на какой сервер доставлять письма для адресов вида info@site.ru. Если запись неверна, письма не доходят до вашего ящика, а отправитель узнаёт об этом не сразу. Сайт эта запись не трогает — он открывается по другой записи.
Что такое MX-запись?
MX расшифровывается как Mail eXchanger — «почтовый обменник». Это запись типа MX в зоне домена, где указаны имя сервера и приоритет. По справке Яндекс 360, MX-запись указывает на сервер, принимающий почту для вашего домена. Если вы делегировали домен на серверы Яндекса, она настраивается автоматически.
Запись нужна только для входящей почты. Когда кто-то пишет на info@site.ru, его почтовый сервис ищет MX-записи домена site.ru и по ним понимает, куда отправить письмо. Google в справке Workspace описывает то же самое: компьютер отправителя проверяет MX-записи для вашего почтового домена, чтобы определить, куда доставить письмо.
Подпись писем и защита от подделки к MX отношения не имеют: ими занимаются SPF, DKIM и DMARC. MX отвечает на один вопрос — где письма будут приняты.
Как отправитель находит сервер
Порядок поиска задаёт стандарт SMTP, RFC 5321. Отправляющий сервер берёт домен из адреса получателя и запрашивает у DNS его MX-записи. Дальше возможны три случая.
Второй случай опасен для сайтов без почты. Если у домена нет MX, письма на него будут пытаться попасть на веб-сервер, а он почту не принимает. Отправитель в итоге получит отказ, а вы не узнаете, что вам писали.
Обратное правило тоже важно: если хоть одна MX-запись есть, адресные записи домена для почты не используются, кроме найденных через MX. Поэтому сменить MX достаточно, чтобы переехать с почты хостинга на отдельный сервис, даже если сайт остаётся на старом месте.
Приоритет MX: какой сервер получит письмо первым
Приоритет — число рядом с именем сервера. По RFC 1035 это 16-битное целое, и меньшее значение означает более предпочтительный сервер. Приоритет 10 побеждает приоритет 20: сначала письмо идёт на сервер с десяткой, и только при его недоступности отправитель пробует двадцатку.
Если у нескольких записей приоритет одинаковый, отправитель обязан выбирать между ними случайно. Так почтовые сервисы распределяют нагрузку между своими серверами.
| Приоритет | Что происходит с письмом |
|---|---|
| Наименьшее число | Пробуется первым |
| Большее число | Резерв: используется, если сервер с меньшим числом не отвечает |
| Одинаковые числа | Отправитель выбирает любой из них случайным образом |
Для Яндекс 360 справка называет приоритет 10, а если панель такой не позволяет, годится любой ненулевой. Справка Google Workspace называет одно значение MX, smtp.google.com, поэтому вопрос порядка там не встаёт. Несколько записей с разными приоритетами нужны, когда почту принимает собственный сервер с запасным или когда сервис сам публикует несколько адресов.
Мнение. Если вся почта домена живёт в одном облачном сервисе, прописывайте ровно те MX-записи, которые он выдал, и ничего к ним не добавляйте. Дополнительный «резервный» сервер, о котором сервис не знает, может увести часть писем туда, где их никто не читает.
Примеры MX-записей для Яндекса, Google и своего домена
Готовые значения выдаёт почтовый сервис. Для домена site.ru они выглядят так:
| Сервис | Имя (хост) | Значение | Приоритет |
|---|---|---|---|
| Яндекс 360 | @ | mx.yandex.net. | 10 |
| Google Workspace | @ | smtp.google.com | по справке Google |
| Старый Google Workspace (подключён до 2023 года) | @ | значения, начинающиеся с aspmx | как в вашей зоне |
Google отмечает, что у доменов, подключённых к Workspace до 2023 года, значения могут быть другими и начинаться с «aspmx». Если почта работает, менять их не нужно: старые значения продолжают поддерживаться.
В файле зоны запись выглядит одной строкой:
site.ru. 21600 IN MX 10 mx.yandex.net.
Здесь site.ru. — домен, 21600 — время жизни записи в секундах, IN — класс, MX — тип записи, 10 — приоритет, mx.yandex.net. — сервер. Яндекс советует указывать TTL 21600, если панель его требует. В панели регистратора эти же данные разложены по полям: «Хост» или «Поддомен» — @, «Значение» — имя сервера, «Приоритет» — число.
Два нюанса из справки Яндекс 360. Точка в конце имени сервера обязательна, если панель управления не добавляет её сама: без неё панель может дописать к имени ваш домен. А если поле хоста не принимает ни @, ни имя домена, его оставляют пустым.
Как сменить MX-запись?
Смена MX — момент, когда письма теряют чаще всего. Порядок работ, который следует из справки Яндекс 360:
Перед удалением старых записей сохраните их значения, например скриншотом: если новый сервис не подхватит домен, вернуть прежнее будет быстро. И заранее убедитесь, что ящики на новом сервисе уже созданы: письма начнут приходить туда сразу после обновления DNS.
Факт. По справке Яндекс 360, DNS-серверы в интернете могут обмениваться данными о новых записях до 72 часов, и повторно проверять настройку советуют только после этого срока.
MX-запись и сайт: что на что влияет
MX и сайт живут в одной DNS-зоне, но друг от друга не зависят. Сайт открывается по A-записи (или AAAA для IPv6), которая ведёт на IP-адрес веб-сервера. Почта ходит по MX. Можно держать сайт у одного хостера, почту в Яндекс 360, а регистрацию домена у третьей компании.
Из этого следует правило при переезде сайта. Перенос на новый хостинг меняет A-запись, а MX остаётся как есть, если почта была не на хостинге. Если же ящики лежали на хостинге, вместе с сайтом переезжает и почта, и MX нужно менять осознанно, по шагам из предыдущего раздела.
Граница применимости такая: MX не помогает, когда проблема в отправке. Если письма с вашего адреса попадают в спам у получателей, дело в SPF, DKIM и DMARC, а не в MX. А если письма на ваш адрес не приходят, смотрите сначала MX, потом место, куда она ведёт.
Если домен регистрировали у нас, DNS-записи для почты добавим мы: это часть услуги по регистрации домена. О том, как устроены уровни домена и DNS в целом, рассказывает статья что такое домен сайта.
Как проверить MX-запись?
Проверка занимает минуту и нужна после каждой правки зоны.
В терминале подойдёт одна из команд, где вместо site.ru подставьте свой домен:
nslookup -type=mx site.ru
dig MX site.ru +short
Команда dig покажет только приоритеты и имена серверов, nslookup — подробнее. Ответ для Яндекса должен содержать ровно одну строку: приоритет 10 и mx.yandex.net. Без командной строки справка Яндекс 360 предлагает веб-сервис digwebinterface.com: в поле имён вводят домен, в поле типа выбирают MX и нажимают dig.
Ответ считается неверным, если сервер не отвечает, значение не совпадает с нужным или в ответе есть лишние записи. Второй этап проверки: убедитесь, что значение из ответа указывает на работающий сервер, то есть имя из MX само имеет A-запись. Проверьте её тем же способом: nslookup mx.yandex.net.
И последний шаг — живой тест. Отправьте письмо на адрес домена с личного ящика на другом сервисе и убедитесь, что оно дошло. Если письмо не пришло, дождитесь окончания срока обновления DNS и повторите проверку.
Частые ошибки в MX-записях
Чаще всего почта ломается по одной из причин ниже. Каждая проверяется за минуту в DNS-зоне.
- 01 Вместо имени сервера указан IP-адрес
RFC 5321 требует, чтобы в ответе стояло доменное имя, у которого есть адресная запись. Прямой адрес в этом поле не годится.
- 02 Имя в MX — псевдоним (CNAME)
RFC 2181 запрещает такое имя в значении MX, а RFC 5321 выводит CNAME за пределы стандарта. Поведение при этом стандартом не определено, поэтому ошибка проявляется выборочно: одни письма доходят, другие нет.
- 03 Рядом с новой записью осталась старая
Часть писем уходит на прежний сервер, потому что приоритеты у записей сравниваются, а не заменяют друг друга.
- 04 Нет точки в конце имени
Если панель не добавляет её сама, к имени может дописаться ваш домен, и получится mx.yandex.net.site.ru.
- 05 Нулевой приоритет у обычной записи
Справка Яндекс 360 просит для своего сервера десятку или любое другое ненулевое значение.
- 06 MX на поддомене настроена, а на основном домене нет
Письма на info@site.ru не приходят, а на info@mail.site.ru приходят: у каждого имени своя запись.
Домен без почты: Null MX
Если домен только показывает сайт и почту не принимает, стоит прямо сказать об этом отправителям. Без MX у письма есть запасной путь: по правилу неявной MX оно уйдёт на IP сайта, и отправитель будет ждать, пока веб-сервер ответит. Стандарт RFC 7505 вводит для таких доменов Null MX.
По RFC 7505 домен, который не принимает почту, объявляет одну MX-запись с приоритетом 0 и точкой вместо имени сервера:
site.ru. 21600 IN MX 0 .
Точка тут — не опечатка: она означает «почтового сервера нет». По RFC 7505 отправитель узнаёт на первой же попытке, что адрес недоставим, и не ставит письмо в очередь с повторами. Подходит для доменов, купленных про запас, и для служебных поддоменов, на которые писать никто не должен.
Если почта на домене нужна, Null MX не ставят: он отсекает все входящие письма. Всё сказанное про приоритеты и смену записей относится к обычным MX.
С чего начать
Определите, где сейчас лежит почта вашего домена: на хостинге, в облачном сервисе или у владельца сервера. Откройте DNS-зону и посмотрите, какие MX там стоят. Сверьте их со справкой того сервиса, который должен принимать почту. Если записи не совпадают, смените их по шагам из раздела про смену и проверьте командой. Для переезда сайта вместе с почтой пригодится чек-лист переноса на другой хостинг.
Источники
- MX-запись — Яндекс 360 для бизнеса
- Настройка MX-записей для Google Workspace — Справка Google Workspace
- RFC 5321. Simple Mail Transfer Protocol — IETF
- RFC 1035. Domain Names: Implementation and Specification — IETF
- RFC 2181. Clarifications to the DNS Specification — IETF
- RFC 7505. A "Null MX" No Service Resource Record — IETF
