MX-записи: приоритет, резервный MX и нулевой MX

MX-запись сообщает остальному интернету, какой хост принимает почту для вашего домена. В ней два поля: число приоритета и имя почтового сервера. Когда кто-то пишет на anna@example.com, его сервер запрашивает MX-записи для example.com, сначала пробует хост с наименьшим числом и, если не может подключиться, по порядку переходит к остальным. Вот и весь механизм. Всё, что идёт не так с MX-записями, вытекает из четырёх правил, которые большинство людей никогда не читает: цель должна быть именем хоста, а не IP-адресом; это имя не должно быть CNAME; меньшее число побеждает; а домен совсем без MX всё равно принимает почту на адрес из своей A-записи, если вы не скажете иначе.

В этой статье - синтаксис, что отправители на самом деле делают с приоритетами, стоит ли заводить резервный MX (обычно нет), нулевой MX для доменов, которые никогда не должны получать почту, и команды dig, показывающие, что видит мир.

Запись и два её поля#

example.com.   3600  IN  MX  10 mail.example.com.example.com.   3600  IN  MX  20 mail2.example.com.mail           3600  IN  A   203.0.113.25mail2          3600  IN  A   198.51.100.40

Первое число после MX - это preference, которое обычно называют приоритетом. Это 16-битное значение, то есть от 0 до 65535. Предпочтение отдаётся меньшему. Абсолютные значения ничего не значат, важен только порядок. 10 и 20 ведут себя ровно так же, как 1 и 2 или 100 и 200. По традиции между числами оставляют промежутки, чтобы позже можно было вставить хост посередине без перенумерации.

Второе поле - exchange: имя хоста сервера, который принимает SMTP на порту 25. В файле зоны точка в конце отмечает полностью определённое имя; большинство веб-редакторов DNS добавляют её сами.

Запись находится на том имени, на которое адресована почта. Почта для @example.com использует MX на example.com (apex, который во многих редакторах обозначается @). Почта для @support.example.com использует MX на support.example.com, а это отдельная запись - поддомены не наследуют MX родителя.

Правила, которые ломают почту#

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

1. Exchange должен быть именем хоста, а не IP-адресом. MX 10 203.0.113.25 - некорректная запись. Одни отправители попытаются разрешить 203.0.113.25 как имя и потерпят неудачу; другие догадаются, что вы имели в виду. Создайте A-запись для хоста и направьте MX на это имя.
2. Exchange не должен быть CNAME. RFC 2181 говорит, что у цели MX должны быть собственные адресные записи. Многие отправители терпят CNAME, некоторые нет, и те, что нет, будут возвращать вашу почту с ошибками, которых вы никогда не увидите. Если почтовый провайдер дал вам имя хоста, используйте его напрямую.
3. Exchange должен разрешаться. MX, указывающий на имя без записи A или AAAA, - это чёрная дыра. Отправители считают это временной ошибкой и повторяют попытки днями, прежде чем вернуть письмо.
4. На имени MX могут быть другие записи, но CNAME рядом с ними стоять не может. Apex и так не может быть CNAME; то же правило означает, что CNAME нельзя поставить ни на одно имя, которому также нужен MX.

Что на самом деле делает сервер-отправитель#

Раздел 5.1 RFC 5321 описывает поиск, и его стоит знать по шагам, потому что он объясняет каждый симптом.

1. Отправитель запрашивает MX для домена получателя.
2. Он сортирует ответы по preference, от меньшего к большему. Хосты с одинаковым preference перебираются в случайном порядке, что распределяет между ними нагрузку.
3. Он разрешает каждый exchange в адреса и подключается к порту 25, переходя к следующему хосту, если очередной недоступен или возвращает временную ошибку.
4. Если все хосты дают временную ошибку, письмо остаётся в очереди отправителя, и попытки повторяются. RFC 5321 советует сдаваться только через четыре-пять дней, и большинство серверов придерживаются чего-то близкого, отправляя исходному отправителю предупреждение о задержке через несколько часов.
5. Постоянная ошибка - ответ 5xx, например «нет такого пользователя», - сразу прекращает попытку. При постоянном отказе отправитель не пробует следующий MX.

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

Есть и запасной вариант на случай, когда MX нет вообще. Если запрос MX не вернул записей, но у домена есть запись A или AAAA, отправитель считает сам домен неявным MX с preference 0 и доставляет почту на этот адрес. Поэтому домен, на котором только сайт, всё равно может получать почту на IP веб-сервера, если там что-то слушает порт 25, - и поэтому для доменов, которые никогда не должны получать почту, стоит публиковать нулевой MX.

Одинаковые приоритеты, переключение и нагрузка#

Две записи с одинаковым preference делят входящую почту случайным образом:

example.com.  IN  MX  10 mx1.example.com.example.com.  IN  MX  10 mx2.example.com.

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

Разные preference дают упорядоченное переключение. Вторичный хост получает почту, только пока основной недоступен. Именно так провайдеры почтового хостинга перечисляют несколько своих серверов - текущая схема Google Workspace состоит из одной записи smtp.google.com, а в старых инструкциях было пять хостов с preference 1, 5, 5, 10 и 10. Используйте ровно то, что говорит ваш провайдер, и при переезде полностью удаляйте записи старого.

Резервный MX: почему сегодня это обычно плохая идея#

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

• Отправители и так ставят почту в очередь. Любой почтовый сервер повторяет попытки днями. Если ваш основной сервер лежит полдня, почта ждёт на стороне отправителей и приходит, когда вы вернётесь. Резерв не добавляет ничего, чего отправитель уже не делает.
• Спамеры целятся в резервные MX. Они намеренно подключаются к MX с наибольшим числом, потому что у резервных серверов часто слабее фильтрация и они принимают почту на любой адрес. Затем резерв передаёт спам вашему основному серверу, который ему доверяет.
• Backscatter. Резерв, не знающий ваших действующих ящиков, принимает почту для несуществующих адресов, а потом вынужден возвращать её - на поддельные адреса отправителей. Это превращает ваш резерв в источник спама для ни в чём не повинных третьих лиц и приводит его в блок-листы.

Резервный MX имеет смысл, только если у него тот же список получателей, что и у основного (чтобы он отклонял неизвестных пользователей ещё во время SMTP-диалога), та же спам-фильтрация и те же проверки аутентификации. В этот момент вы уже держите два почтовых сервера. Для небольшого домена лучше один ухоженный сервер плюс собственные очереди повторов у отправителей.

Нулевой MX для доменов, которые никогда не получают почту#

RFC 7505 определяет способ сказать «этот домен почту не принимает»:

example.net.   3600  IN  MX  0 .

Одна MX-запись с preference 0 и exchange . (корень). Отправитель, увидев её, сразу получает постоянную ошибку, вместо того чтобы пробовать A-запись домена или днями держать письмо в очереди. Публикуйте её на:

• Доменах, которые используются только для сайтов или редиректов.
• Припаркованных доменах и старых доменах брендов, которые вы держите для защиты.
• Поддоменах, у которых есть A-записи, но которые никогда не должны быть адресатами почты, например www или api, если хотите сделать всё основательно.

Дополните её SPF-записью v=spf1 -all и DMARC-записью с p=reject на доменах, которые также никогда не отправляют почту. Вместе они говорят «ничто, приходящее на этот домен или с него, не настоящее», и домен перестаёт быть мишенью для подделки. Нулевой MX должен быть единственной MX-записью на этом имени; сочетать его с настоящими MX-записями нельзя.

Проверка MX-записей через dig#

# The MX set as your resolver sees it$ dig +short MX example.com10 mail.example.com.20 mail2.example.com.# Ask a public resolver to avoid your own cache$ dig @1.1.1.1 +short MX example.com# Confirm the target is not a CNAME and has an address$ dig +short CNAME mail.example.com$ dig +short A mail.example.com# Then confirm something answers on port 25$ nc -vz mail.example.com 25

В Windows - Resolve-DnsName example.com -Type MX или nslookup -type=MX example.com 1.1.1.1.

Нужный результат - пустой ответ на запрос CNAME и адрес на запрос A. Если запрос CNAME что-то возвращает, исправьте это. Если nc извне вашей сети завершается таймаутом, с DNS всё в порядке, а порт недоступен - файрвол или, на арендованном сервере, ещё не проброшенный порт 25. Проверка из сети, которая блокирует исходящий порт 25 (это большинство домашних подключений), тоже закончится таймаутом, поэтому запускайте её с сервера или используйте веб-сервис для проверки SMTP.

Как выглядят типичные сбои MX

Возвращённое отправителю письмо об ошибке обычно называет проблему, если уметь его читать.

• «Domain not found» или `NXDOMAIN` - домена получателя в DNS нет вообще. Опечатка в адресе или домен, регистрация которого истекла.
• «No MX or A records» или «unrouteable address» - домен существует, но у него нет ни MX, ни адреса, на который можно откатиться. Обычно это свежезарегистрированный домен, записи которого так и не создали.
• «Host not found» для exchange - MX указывает на имя без A-записи, часто потому, что почтовый хост переименовали, а MX не обновили.
• Доставка задерживается, connection timed out - MX разрешается, но на порту 25 никто не отвечает. Сервер лежит, закрыт файрволом или порт не проброшен. Отправитель продолжает попытки, поэтому сначала это выглядит как предупреждение о задержке, а через несколько дней - как возврат письма.
• `550 5.1.1` user unknown - с DNS и сервером всё в порядке; ящика нет на сервере, на который указывает MX. После смены провайдера это часто означает, что MX всё ещё указывает на старого провайдера, где ящик уже удалён.
• `554 5.7.1` relay access denied - принимающий сервер не считает себя ответственным за ваш домен. Домен так и не добавили на почтовый сервер, или MX указывает на чужой сервер.

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

Полная картина того, как работают запросы и кэширование, - в статье DNS-записи простыми словами; о TXT-записях, которые соседствуют с MX, - в статье SPF, DKIM и DMARC простыми словами.

Смена почтового провайдера без потери писем#

Перенос MX - самое рискованное изменение DNS, которое делает большинство людей, потому что почта, отправленная во время переключения, может попасть на любую из сторон.

1. Снизьте TTL записи MX до 300 заранее, как минимум за один период старого TTL, - за сутки, если он был 86400.
2. Сначала полностью настройте новый сервер: домен, ящики, DKIM-ключи, опубликованные под новыми селекторами. Проверьте его, отправив на него почту напрямую, до переключения.
3. Поменяйте MX-записи на новый сервер. Старые удалите полностью; если оставить старого провайдера с большим числом, часть почты будет уходить туда при каждом сбое нового.
4. Не закрывайте старые ящики хотя бы несколько дней. Отправители с закэшированными ответами MX будут доставлять почту туда, пока не истечёт их TTL. Проверяйте их и переносите всё, что приходит.
5. Обновите SPF под новый путь отправки и только после этого удалите include старого провайдера.
6. Скопируйте старую почту по IMAP. Об imapsync и порядке действий - в статье перенос почты на собственный сервер.

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

Как это устроено на RE:NODE Mail Server#

На тарифе Mail Server MX вашего домена указывает на имя хоста, которое вы даёте своему серверу, а A-запись содержит адрес, показанный в панели. Эти записи вы создаёте там, где размещён ваш DNS, - редактора зон на нашей стороне нет, - а веб-админка Stalwart показывает полный набор, который она ожидает для каждого домена. MX заработает только тогда, когда порт 25 будет доходить до сервера, а это поддержка настраивает по запросу; на один адрес приходится один почтовый сервер, поскольку принимать почту на порту 25 конкретного IP может только один сервер. Остальное о первом часе работы - в статье настройка почтового сервера Stalwart.

FAQ#

Какое число приоритета использовать?

Любое. Для одного почтового сервера привычно 10. Для нескольких важен только порядок, поэтому оставляйте промежутки (10, 20, 30), чтобы потом было легко вносить изменения. Если вы пользуетесь почтовым хостингом, ставьте ровно те значения, которые дал провайдер.

Может ли MX-запись указывать на IP-адрес?

Нет. Она должна указывать на имя хоста с собственной записью A или AAAA. Создайте mail.example.com с адресом и направьте MX на это имя.

Почему почта всё ещё идёт к старому провайдеру, хотя я сменил MX?

Отправители закэшировали старый MX на время его TTL. Запись с TTL 86400 секунд может направлять почту на старый сервер ещё сутки. Не закрывайте старые ящики, пока TTL не истечёт, и проверяйте их.

Нужна ли MX-запись, если я только отправляю почту?

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

Использует ли поддомен MX родительского домена?

Нет. Почта для user@news.example.com ищет MX на news.example.com. Если его нет, отправитель откатывается к A-записи этого поддомена, а не к MX родителя.