MX-записи: как устроена маршрутизация почты

Адрес электронной почты состоит из имени ящика и домена. Чтобы отправить письмо на адрес в домене example.com, почтовому серверу нужно узнать, какой именно машине его передать. Ответ находится в DNS: запись MX (Mail Exchanger) перечисляет серверы, принимающие почту домена. Сайт домена и почта могут жить в разных местах: сайт на одном хостинге, почта у специализированного сервиса. MX-записи как раз и позволяют так разделить.

В отличие от адресных записей, MX указывает на имя сервера, а не на IP. Само имя затем разрешается обычным образом через A или AAAA.

У каждой MX-записи есть число, называемое предпочтением. Чем оно меньше, тем выше приоритет. Отправляющий сервер сначала пытается доставить письмо на узел с наименьшим значением, а при неудаче переходит к следующему. Если у нескольких записей одинаковое число, нагрузка распределяется между ними. Поэтому типичная схема выглядит так: основной сервер с малым числом и один-два резервных с большими.

Резервный сервер принимает письма, когда основной недоступен, и затем передаёт их дальше. Вместе с тем каждый лишний узел — потенциальная точка, где следует поддерживать те же правила фильтрации, иначе он станет лазейкой для нежелательной почты.

Логика такая. Сервер-отправитель выделяет домен адресата, запрашивает MX-записи, сортирует по предпочтению, разрешает имена в адреса и подключается по протоколу SMTP. Протоколам почты посвящены страницы smtp, imap и pop3. Если MX-записей нет вообще, по правилам стандарта отправитель пробует доставить почту на адрес, указанный в A или AAAA самого домена. Но полагаться на этот запасной вариант не стоит: явная MX-запись надёжнее.

Специальное значение «null MX» с пустым именем означает, что домен принципиально не принимает почту, и отправителям не имеет смысла даже пытаться.

Одних MX недостаточно, чтобы почта дошла до адресата и не попала в спам. Рядом лежат текстовые записи с политиками SPF, DKIM и DMARC, о них подробнее на странице dns-zapis-txt. Они описывают, кто вправе отправлять письма от имени домена и как проверять подпись. Принимающий сервер сверяет входящее письмо с этими правилами.

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

Распространённые проблемы: MX указывает на CNAME (стандарт этого не рекомендует), MX указывает на голый IP-адрес, что недопустимо, в записи забыли имя сервера, две системы конфликтуют из-за одинаковых приоритетов. После смены почтового провайдера письма первое время могут приходить по старому и новому адресам из-за кэша и TTL.

Посмотреть записи можно командой dig example.com MX или nslookup -type=MX example.com. Сортируйте результат по числу и убедитесь, что имена серверов разрешаются в адреса.

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

Отдельная тема — шифрование при передаче между серверами. Поддержка STARTTLS позволяет серверам договориться об использовании TLS, но по умолчанию его можно понизить до открытой передачи. Для строгой политики существует механизм MTA-STS, публикуемый через TXT-запись и веб-файл: он требует от отправителей использовать TLS с проверкой сертификата. Полезно знать и про домены, которые не отправляют почту: для них публикуют запрещающую SPF-запись, чтобы никто не подделывал письма от их имени.

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