Ростелеком ТВ 

Запись типа mx. Примеры запроса MX-записи. Подтверждение домена для Яндекс Почты

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

Если просуммировать все записи описания ресурсов, которые предлагалось указывать в описании зоны, то посвященных электронной почте RR-ов (Resource Records) было бы большинство.

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

Запись MX может быть определена как для всей зоны, так и для отдельно взятой машины. MX RR имеет следующий формат:

IN MX

Поле name определяет имя машины или домена, на который может отправляться почта. Это может быть как полностью определенное имя, так и частичное имя машины. Поле ttl обычно оставляют пустым. В поле preference указывается приоритет почтового сервера, имя которого указано последним аргументом в поле данных MX-записи.

Прежде чем перейти к подробному обсуждению назначения и практики применения MX записей следует понять основные принципы построения обмена электронной почтой в Интернет.

В своих рассуждениях мы будем опираться на концепцию, которая изложена в RFC 2821. Данный документ заменил старожилов - RFC 821 и RFC 974.

RFC 821 определяло протокол доставки почты - SMTP, а второй документ - взаимодействие электронной почты с системой доменных имен. Новый документ обобщил опыт применения первых двух на практике (например, отменил требование проверки наличия WKS записи для хоста, указанного в качестве шлюза в MX записи, которое все равно никто не соблюдал) и прояснил некоторые недостаточно четко сформулированные требования.

Во-первых, следует остановиться на самом понятии почтового шлюза. Наиболее распространенным в этом контексте были термин MTA (Mail Transfer Agent) и термин MUA (Mail User Agent). Данные термины применяли для того, чтобы подчеркнуть некоторое отличие MTA от почтового сервера, который являлся конечным получателем почты и от клиентского программного обеспечения (MUA), которое обеспечивало только "первую и последнюю мили" пути почтовго сообщения.

Сейчас предпочтение отдано терминологии "клиент-сервер" и термины МТА MUA следует употреблять с осторожностью.

Все дело в том, что ситуация в почтовой службе несколько изменилась. Раньше (во времена существования UUCP, которому посвящено не меньше места в старых RFC) наиболее распространенной процедурой доставки почты была многозвенная доставка с использованием большого числа промежуточных узлов. При этом почта передавалась из одних сетей в другие, в том числе, и с использованием сетей посредников.

При такой технологии работа электронной почты напоминала работу обычной почты, основанную на отделениях связи. Существовали и существуют до сих пор многочисленные узлы-шлюзы. С их списком можно ознакомиться по адресу http://www.faqs.org/faqs/mail/inter-network-guide/.

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

Рисунок.1. Схема доставки и отправки почты.

Кроме того, в почте от первых двух названных (relay и gateway) еще отличают хост, который, собственно, является хранителем почтовых ящиков. Локальная доставка писем адресатам.

Все попытки внедрить в обиход подобное разделение и для системы DNS пока ни к чему не привели. Записи типа MB (Mail Box) в описаниях зон Вы не найдете "днем с огнем, а ночью ощупью".

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

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

Ключевым элементом в почтовом сообщении являются адреса отправителя и получателя. Адреса принято записывать в виде:

local-part@domain

Нас с точки зрения DNS интересует только та часть, которая называется "domain". На самом деле, вовсе не обязательно, что domain представляет из себя правильное доменное имя. Просто название этой части адреса созвучно DNS доменам.

Все обмены данными между шлюзам в рамках интернет производятся по протоколу SMTP (Simple Mail Transfer Protocol). Наверное, каждый пользователь, а уж тем паче администратор, имеет опыт настройки программ чтения и отправки почтовых сообщений на работу с таким шлюзом или, как их еще называют, relay-ем.

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

Во-первых, в рамках SMTP-обмена в качестве доменных имен допускаются только полные доменные имена (fully-qualified domain names), которые можно разрешить при помощи поиска MX или A записей в системе DNS. Т.е. в поле domain почтового адреса должно быть имя, для которого есть MX или A запись. В принципе, допускаются и синонимы, т.е. имена для которых в DNS можно найти записи CNAME, перенаправляющие на MX или A записи. На самом деле многие шлюзы настроены таким образом, что CNAME записи игнорируются.

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

По этому имени шлюз производит поиск MX записей. Если он находит CNAME, то заменяет исходное имя каноническим и снова повторяет поиск (мы уже писали, что довольно часто эта возможность отключена в реальной жизни).

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

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

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

Если MX записи имеют одинаковые предпочтения, то на практике шлюз выбирает наиболее предпочтительную из них случайным образом (во всяком случае, так делают Sendmail и Postfix).

Как только почта успешно отправлена, перебор шлюзов-получателей прекращается.

Приведем пример использования записей MX в описании зоны:

$TTL 3600
$ORIGIN vega.ru.
@ IN SOA vega-gw.vega.ru paul.kiae.su (
101 ; serial number
86400 ; refresh within a day
3600 ; retry every hour
3888000 ; expire after 45 days
3600) ; negative caching
IN NS vega-gw.vega.ru.
IN NS ns.relarn.ru.
IN NS polyn.net.kiae.su.
IN A 194.226.43.1
IN MX 10 vega-gw.vega.ru.
IN MX 20 ns.relarn.ru.
IN MX 30 relay.relarn.ru.
;
vega-gw IN A 194.226.43.1
IN MX 0 vega-gw
IN MX 10 ns.relarn.ru.
IN MX 20 relay.relarn.ru.
;
www IN CNAME vega.ru.

В данном примере мы определили несколько записей типа MX для почтовой рассылки.

Записи в описании зоны, сразу после A-записи, следующей за записью SOA, определяют пути поступления почты на хост-тезку данного домена. Для получения почты по имени домена эта адресная запись не нужна. Ее используют для других интернет-сервисов, скажем для доступа к web-сайту домена не только по доменному имени www.vega.ru, но и по доменному имени vega.ru.

Самый высокий приоритет здесь имеет прямая отправка почты на шлюз vega-gw.vega.ru. Если отправить почту на эту машину не удастся, то почтовый агент должен попробовать путь через почтовый сервер ns.relarn.ru . Если и этот путь окажется невозможным, то почту можно попытаться отправить на пересыльный пункт relay.relarn.ru . Такой порядок опроса почтовых серверов определяется полем preference - чем меньше значение поля, тем выше приоритет сервера в записи MX.

В нашем домене, который мы использует в качестве примера, большинство почтовых ящиков пользователей расположено на машине vega-gw.vega.ru. Для этой машины также указаны несколько записей MX. Наибольший приоритет среди них имеет запись с именем почтового сервера vega-gw. Обратите внимание на то, что данное имя не оканчивается точкой. Это значит, что оно расширяется именем текущей зоны. Все же другие имена серверов - это полностью определенные доменные имена (fully-qualified).

Одной из главных проблем пересылки почты является зацикливание при невозможности отправки непосредственно адресату. Представим ситуацию, когда хост vega-gw.vega.ru недоступен.

Тогда согласно процедуре, описанной выше, почта должна быть отправлена на ns.relarn.ru, он, в свою очередь, не может отправить почту на vega-gw.vega.ru. Себе он отправлять почту тоже не будет, поэтому отправит на relay.relarn.ru, а тот снова на ns.relarn.ru, и так по кругу.

На самом деле ничего подобного не произойдет, т.к. шлюзы обязаны исключать из списка MX записи, которые имеют больший или такой же приоритет, как и они сами. В нашем случае почта будет "отлеживаться" на ns.relarn.ru.

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

MX записи - это один из немногих случаев, где действительно имеет смысл применять wildcard в доменном имени. Если в описании зоны поместить запись вида:

*.domain.ru. IN MX 10 host.domain.ru.

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

В настоящее время среди прочих коммерческих услуг достаточно популярной стала услуга перенаправления почты - mail forwarding. Ее идея заключается в том, что регистрируется домен с коротким легкозапоминающемся именем и почтовые адреса указываются относительно этого домена. При этом реальные почтовые ящики могут находиться где угодно.

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

Естественно, что на самом хосте соответствующим образом должен быть настроен и почтовый шлюз. Типичный пример можно найти в ru-rucenter (https://www.nic.ru/dns/service/no_primary.html)

И напоследок несколько цифр характеризующих проблему обмена электронной почтой с точки зрения DNS. Согласно отчету 2002 года компании men&mice в TLD com из 5000 обследованных доменов не имеют MX записей 18.68% зон. В эти зоны нельзя отправить почту. В 3.3% случаев МХ записи указывают на CNAME, т.е. на синонимы, что для некоторых почтовых программ недопустимо. В 4.16%-ах случаев почтовые серверы соответствующих доменов не работают с DNS правильно, т.е. согласно принятым спецификациям.

  1. P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
  2. P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
  3. Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
  4. Документация по BIND 9. Справочное руководство системного администратора. ()
  5. 4. J.Klensin. RFC 2821. Simple Mail Transfer Protocol. 2001. (http://www.ietf.org/rfc/rfc2821.txt?number=2821)
  1. Inter-Network Mail Guide (http://www.faqs.org/faqs/mail/inter-network-guide/) - руководство по пересылке почты между различными почтовыми системами.
  2. Craig Partridge. RFC 974. MAIL ROUTING AND THE DOMAIN SYSTEM. 1986. (http://www.ietf.org/rfc/rfc974.txt?number=974) - стандарт интернет, который использовался до RFC 2821.
  3. http://www.menandmice.com/infobase/mennmys/vefsidur.nsf/index/5.1 - статистика проблем электронной почты, связанных с неточностью настройки DNS

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

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

Общая инструкция по настройке MX-записи

    Войдите в вашу панель управления на сайте компании, которая предоставляет вам DNS-хостинг.

    Удалите существующие MX-записи.

    Создайте новую MX-запись со следующими значениями полей (в разных панелях управления названия полей могут различаться):

    • Значение - «mx.yandex.net.» . Точка в конце имени сервера обязательна, если ваша панель управления не добавляет ее по умолчанию.

      Приоритет - 10.

      Если приоритет со значением «10» не предусмотрен в панели управления, укажите любой другой отличный от нуля приоритет.

      Имя поддомена - «@» .

      В некоторых панелях управления вместо символа @ нужно указать имя вашего домена (например, «example.com.» ). Если вам не удается указать ни @, ни имя домена, оставьте это поле пустым.

Общая инструкция по настройке MX-записи

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

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

Если вы делегировали домен на серверы Яндекса, MX-подпись будет настроена автоматически. Вы можете просмотреть и отредактировать ее параметры в DNS-редакторе Почты для домена.

    Войдите в вашу панель управления на сайте компании, предоставляющей вам услуги DNS-хостинга.

    Удалите существующие MX-записи.

    Создайте новую MX-запись со следующими значениями полей (в разных панелях управления названия полей могут отличаться):

    • Значение - «mx.yandex.net.» .

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

      Приоритет - 10.

      Если приоритет со значением «10» не предусмотрен в панели управления, укажите любой другой отличный от нуля приоритет.

      Имя поддомена - «@» .

      В некоторых панелях управления вместо «@» нужно указать имя вашего домена (например, «yourdomain.tld.» ). Если вам не удается указать ни «@» , ни имя домена, оставьте это поле пустым.

      Если это поле отсутствует в панели управления, можно его не указывать.

    Подождите, пока изменения в DNS вступят в силу. Этот процесс может длиться до 72 часов.

На сегодняшний день у некоторых организаций имеются свои почтовые серверы, которые не посредственно расположены физически в самой организации а веб сайт находиться на хостинге в интернете так как же быть? Чтобы почта доходила до сервера почтового в компании а при наборе доменного адреса в браузере запрос перенаправлялся на хостинг где расположенный сайт.
Всё это можно сделать грамотно настроив MX запись на DNS сервере.
Что нам для этого надо?
1.Выделенный IP адрес белый на шлюзе или почтовом сервере в организации

2.Доступ к редактировнаию записей DNS на хостинге или на локаунте регистратора(если не знаете о чём идёт речь задайте этот вопрос регистратору или хостер вашему на котором располагается домен или сайт)

Если выше описанные два пункта выполняются тогда кратко какие бывают записи DNS и как они не посредственно работают те которые нам не посредственно понадобиться.

1.Запись A (address record) или запись адреса связывает имя хоста с адресом IP..226.224.102 , на этом IP адресе физически располагается сайт www.сайт . Синтаксис написание сайт 86400 IN A 87.226.224.102 (86400 это время жизни данной записи после чего она обновиться повторно с сервера DNS)
2.Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена..ru , Синтаксис написание сайт 86400 IN MX 10 сайт (86400 это время жизни данной записи после чего она обновиться повторно с сервера DNS, MX это тип данных описываемых, 10 это приоритет по которому выбирается адрес доставки почты чем меньше число тем выше приоритет,если у вас всего один почтовый сервер то вам сойдёт любое число от 0 до 10)
вот собственно и всё что мы будем редактировать.

И так приступим мы имеем почтовый сервер который располагается на внешнем IP или внешнем шлюзе с IP адресом 10.10.10.10 и веб сайт с доменным именем www.test.ru который располагается на сервере хостинга тот который в свою очередь находиться на IP адресе 20.20.20.20 , заходим в админку хоста или админку регистратора имени и смотрим записи DNS на наше доменное имя test.ru и видим следующую картину



test.ru 86400 IN MX 10 test.ru (или своё доменное имя обычно второго уровня хостинговое)

теперь расшифровываем домен *.test.ru c любым префиксом располагается физически на IP адресе 20.20.20.20 дальше домен test.ru располагается физически на IP адресе 20.20.20.20 это понятно, почтовая служба домена test.ru есть и она располагается на адресе test.ru всё вроде бы понятно.
Теперь нам надо сделать так чтоб те кто набирал в адресной строке браузера www.test.ru или test.ru попадали на сайт наш который расположен на хостенге,а те которые писали письмо на почту нашего домена например на Данный адрес e-mail защищен от спам-ботов, Вам необходимо включить Javascript для его просмотра. то это письмо не посредственно отправлялась на нашу почтовую машины расположенную в нашей конторе по адресу 10.10.10.10 так вот чтоб это сделать надо перезаписать MX запись на DNS сервере, можно сделать это так test.ru 86400 IN MX 10 10.10.10.10 что будет соответствовать для доменного имени test.ru почтовый сервер находиться на IP адресе 10.10.10.10 многие так и думают да эта запись будет работать и даже вы сможете отправлять и получать письма но не все почтовые сервера будут с вами работать, так как крупные почтовые сервисы такие как mail.ru считают хорошим тоном что MX запись на DNS сервера получателя почты должна быть не IP адресом а не посредственным доменным именем это так компания майл ру беспокоиться за нелегальные почтовые сервера и опасаются за спам. В связи с чем почтовый сервис майл ру не будет с вами работать по обмену почтой, все остальные будут работать и почта нормально будет доходить до вас и с рамблера и с гугли и с яндекса. Но как же нам сделать чтоб наш домен был полноценным и принимал и отправлял почту на любые почтовые сервисы и на любые почтовые домены не опасаясь что письмо пропадёт или не дойдёт до вашего почтового сервера? Нам надо превратить наш IP 10.10.10.10 в доменное имя которое мы запищим в MX запись и которое будет у почтовых систем ассоциироваться с IP адресом 10.10.10.10.......тут есть два варианта первый это зарегистрировать доменное имя любое у любого регистратора и указать на A записи в его настройках наш IP 10.10.10.10 то есть сопоставить имя доменное и адрес расположение. Данный способ работает конечно но он трудно-затратен это линии оплаты 600 рублей в год за доменное имя + за DNS к этому доменному имени и того 1000 рублей точно встанет в год и если сказать честно этот способ хоть и рабочий но не совсем правильный, нет он работать будет со всеми почтовыми сервисами но есть но по правилам хорошего тона.
Второй способ более нам и всем подходящий,поскольку мы имеем белый IP адрес на нашем шлюзе или почтовом сервере 10.10.10.10 то наш провайдер по нашей просьбе должен у себя на DNS сервере своём прописать обратную зону DNS для нашего доменного имени. Что такое обратная зона dns вы уж найдите и прочитайте сами в интернете.
Хочу сказать одно нам не нужна обратная зона dns домена первого уровня нашего test.ru которая будет выглядеть так 10.10.10.10.in-addr.arpa и соответствовать test.ru нам надо попросить нашего провайдера чтоб он нам прописал в обратной зоне dns доменное имя второго уровня например mx1.test.ru на ip адрес 10.10.10.10 и всё после того как он пропишет его нам остаётся только подставить mx1.test.ru в нашу MX запись на нашем dns сервере и окончательно наши записи днс должны выглядит следующем образом

*.test.ru 86400 IN A 20.20.20.20
test.ru 86400 IN A 20.20.20.20
test.ru 86400 IN MX 10 mx1.test.ru

всё теперь у нас всё настроено и через сутки после обновления всех российских днс почта будет приходит для нашего домена на наш почтовый сервер который находиться у нас в конторе и не один почтовый сервис не будет возвращать письма из за не корректных записей MX DNS сервера домена.

Я за свою практику встречал несколько раз когда различные компании или люди не правильно всё это дело настраивали в случаи нашем когда почтовый сервер находиться не на хосте хостинговой компании а не посредственно в организации. Ну много сейчас есть контор которые имеют сайт на хосте покупном а почтовый сервер находиться физически в конторе, так как там свой домен своя сеть и тд.....Теперь рассмотрим типичные ошибки которые я встречал с подобной настройкой и которые вы не должны повторить
1.Один сервер был настроен вот так
*.test.ru 86400 IN A 20.20.20.20
test.ru 86400 IN A 10.10.10.10
test.ru 86400 IN MX 10 test.ru
тут всё работало только сайт открывался в браузере только по адресу www.test.ru и не хотел открываться если я просто набираю test.ru, зато почта ходила исправно.
Данный человек не знал видимо что можно у провайдера прописать обратную зону днс и знал что не все почтовые сервисы будут работать с MX записью где адресом является IP адрес машины с почтовым сервером и решил сделать так он сопоставил адрес www.test.ru c IP 20.20.20.20 там где находиться физически сайт и адрес test.ru (без www) сопоставил с IP адресом машины сервера почтового ну и конечно в MX записи прописал test.ru обслуживает почтовик test.ru в итоги всё работало кроме того что те люди которые в браузере набирали просто test.ru не могли попасть на сайт, а это есть плохо не только для удобства человека но это ещё и отображается на SEO раскрутки сайта так как многие каталоги и доски объявлений в строке веб сайт любят отображать не www.test.ru а http://test.ru в итоги люди не могут попасть на сайт. Это одна из типичных ошибок настройки DNS домена.
Второй ошибочный вариант выглядит следующим образом: среди DNS записей есть такая запись типа CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя или адрес так вот некоторые люди делают так они помимо A,MX записей делают запись CNAME с указанием сопоставления например mx1.test.ru на IP адрес 10.10.10.10 то есть на физический адрес почтового сервера или щлюза и уже в свою очередь в MX записи прописывают test.ru 86400 IN MX 10 mx1.test.ru то есть они пытаются сопоставить mx1.test.ru с IP 10.10.10.10 и уже в MX записи прописать mx1.test.ru это тоже не правильно так как современные почтовые системы уже не реагируют на записи CNAME которые имеют свою запись в MX записи, почтовые сервиси всё ровно распознают такой приём как обманный и тем самым не ведут обмен писем с данным доменом.

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

Если кто знает ещё не правильные способы то буду рад выслушать а за свой опыт работы других не встречал.