MX-запись - Почта для домена. Помощь

Запись MX

За́пись MX (от англ. m ail ex changer ) - это один из типов записей в DNS , указывающий способ маршрутизации электронной почты . MX-записи для данного домена указывают серверы, на которые нужно отправлять электронную почту, предназначенную для адресов в данном домене. Кроме того, MX-записи указывают приоритет каждого из возможных серверов для отправки.

Имя хоста , указанного в записи MX, должно содержать IP-адрес , определённый с помощью записи IN A. Псевдонимы IN CNAME не могут иметь своих MX-записей.

Чтобы отправить электронную почту на определённый адрес, сервер-отправитель делает DNS-запрос, запрашивая MX-запись домена получателя электронного сообщения (то есть части адреса после символа «@»). В результате запроса возвращается список имён хостов почтовых серверов , принимающих входящую почту для данного домена, а также величину приоритета для каждого из хостов. Сервер-отправитель затем пытается установить SMTP -соединение с одним из этих хостов, начиная с того, у кого значение величины приоритета наименьшее, перебирая каждый из них, пока не удастся установить соединение хотя бы с одним из них. Если же имеется несколько хостов с одинаковыми приоритетами, то должны быть предприняты попытки установить соединение с каждым из них.

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

Особенности обработки MX при маршрутизации почты

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

Примеры запроса MX-записи

С помощью утилиты host в UNIX -подобных ОС

С помощью утилиты host в ОС GNU/Linux , FreeBSD и т. п. запросим запись MX для домена wikipedia.org.

$ host -t mx wikipedia.org. wikipedia.org mail is handled by 50 lists.wikimedia.org. wikipedia.org mail is handled by 10 mchenry.wikimedia.org.

Здесь список почтовых серверов, обслуживающих почту домена, представлен двумя хостами: lists.wikimedia.org. и mchenry.wikimedia.org. MX-приоритеты у них 50 и 10 соответственно. Таким образом, при попытке доставить почту адресату в домене wikipedia.org. , первым будет выбран сервер mchenry.wikimedia.org.

С помощью утилиты nslookup

С помощью утилиты nslookup в ОС семейства Microsoft Windows запросим запись MX для домена wikipedia.org.

C:\>nslookup -type=mx wikipedia.org ns2.wikimedia.org Server: ns2.wikimedia.org Address: 91.198.174.4 wikipedia.org MX preference = 50, mail exchanger = lists.wikimedia.org wikipedia.org MX preference = 10, mail exchanger = mchenry.wikimedia.org lists.wikimedia.org internet address = 91.198.174.5 mchenry.wikimedia.org internet address = 208.80.152.186

Примечание: примерно так же работает nslookup в UNIX.

См. также

• DNS - система доменных имён;
• SMTP - широко используемый протокол передачи почты.

Wikimedia Foundation . 2010 .

Смотреть что такое "Запись MX" в других словарях:

В области авторского права фиксация звуков и/или изображений с помощью технических средств в какой либо материальной форме, позволяющей осуществлять их неоднократное восприятие, воспроизведение или сообщение. См. также: Произведения Финансовый… … Финансовый словарь

ЗАПИСЬ, записи, жен. 1. только ед. Действие по гл. записать (в 1 и 2 знач.) записывать (книжн.). Запись сказок отняла у меня целое лето. Предварительная запись на облигации займа. 2. То, что записано (в 1 знач.; книжн.). Тетрадь с записями. 3.… … Толковый словарь Ушакова

запись - ЗАПИСЬ, арх., истор. 1. Запись, письменная передача чего л. виденного, слышанного (1055 г.); 2. Документ, запись о каком л. юридическом акте (XV в.) (Сл.РЯ XI XVII. 5. 266 267). Одиношная запись. – Мир (прим. авт.). – Не ведаю, как покончить… … Словарь трилогии «Государева вотчина»

запись - Документ, содержащий достигнутые результаты или свидетельства осуществленной деятельности. Примечания 1. Записи могут использоваться, например, для документирования прослеживаемости и свидетельства проведения верификации, предупреждающих действий … Справочник технического переводчика

- (record) Собрание/комплекс взаимосвязанной информации, которая рассматривается как единое целое в файле (file) или базе данных (database) компьютера. Например, файл о заработной плате персонала компании может быть подразделен на отдельные записи… … Словарь бизнес-терминов

ЗАПИСЬ, сохранение звуковых и видеосигналов на носителях, таких как грампластинка или МАГНИТНАЯ ЛЕНТА. В традиционной ЗВУКОЗАПИСИ записываемые звуки преобразуются в электрический ток, управляющий движениями пишущей иглы. Она прорезает первичный… … Научно-технический энциклопедический словарь

Писание, отметка; регистрация, протокол, учет; переписывание, копия; заметка, партитура, фанера, помета, пометка, уравнение, фонограмма, конспект, стенограмма, транскрипция, поновление Словарь русских синонимов. запись сущ., кол во синонимов: 47… … Словарь синонимов

Письменная фиксация операций, сделок, бухгалтерских проводок, изменений в счетах. Райзберг Б.А., Лозовский Л.Ш., Стародубцева Е.Б.. Современный экономический словарь. 2 е изд., испр. М.: ИНФРА М. 479 с.. 1999 … Экономический словарь

ЗАПИСЬ, и, жен. 1. см. записать. 2. То, что записано. Неразборчивая з. Тетрадь с записями. Музыкальные записи. 3. Документ о какой н. сделке, акт (спец.). Дарственная з. Толковый словарь Ожегова. С.И. Ожегов, Н.Ю. Шведова. 1949 1992 … Толковый словарь Ожегова

Запись - в безбумажной информатике, совокупность данных, характеризующая тот или иной объект или явление: например, кадровая анкета работника или комплектовочная ведомость на детали машины, введенная в память компьютера. При обращении к… … Экономико-математический словарь

Запись - по закону РФ Об авт. праве и смежных правах фиксация звуков и (или) изображений с помощью техн. средств в к. л. материальной форме, позволяющей эти звуки и (или) изображения неоднократно воспринимать, воспроизводить (см. Воспроизведение… … Издательский словарь-справочник

Книги

• Запись аудио- и видеосигналов , Э. И. Вологдин, К. Ф. Гласман, Ю. А. Ковалгин, Л. Г. Лишин. Рассмотрены аналоговая магнитная запись аудио- и видеосигналов; основное содержание книги посвящено цифровой записи. Изложены особенности цифрового представления аудио- и видеосигналов,…

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

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

Подтверждение домена для Яндекс Почты

Первым шагом к почте с оболочкой вашего домена и начинкой яндекса является подтверждение домена (в моем случае, когда под сам сайт у меня другой хостинг и другие цели).

Тут ничего сложного: создаем файл в корне сайта с нужным названием и нужным содержанием и все - проверка пройдена, сайт подтвержден.

Настройка MX записей DNS в ISPmanager (для Яндекс.Почты)

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

1) Удалите домен из раздела "E-mail" -> "Почтовые домены" (т.к. ISPmanager скорее всего прописывает там какие-то данные в DNS и если этого не сделать, то некоторые письма не будут доходить до почты на яндексе) .

2) Теперь нужно добавить MX записи в DNS вашего сайта. Сделать это можно в разделе "Главное" -> "Доменные имена" и кликнув 2 раза на домен левой кнопкой и вам откроется список DNS записей домена. Наша задача: удалить старые MX и добавить новые и сделать это можно вот так:

a) Удаляете все записи с типом MX (почтовый сервер) и TXT (текстовая запись) .
б) Добавляете почтовый сервер Яндекса:

Имя: ВАШ.ДОМЕН. Тип: MX (почтовый сервер) Адрес: mx.yandex.ru. Приоритет: 10

Не забывайте про точку после домена, она обязательна.
в) Ставите переадресацию SPF-записи путем добавления еще одной записи:

Имя: ВАШ.ДОМЕН. Тип: TXT (текстовая запись) Адрес: v=spf1 redirect=_spf.yandex.ru

Нужно это для того, что бы "хорошие" письма не улетали в спам.

В итоге у вас должно получиться что-то вроде этого (правда домен тут забит example.test и добавление обеих записей вынесены на картинке одновременно для того, что бы совместить все в одном изображении, а так суть одна и та же ):

После сохранения и пары кликов в панели яндекса, почта будет работать как и должна. И еще один нюанс: DNS обновляется не мгновенно, поэтому советую подождать минут 10-30 перед визитом в панель яндекса.

Кстати, эту информацию о настройке Яндекс Почты в ISPmanager предоставил один из главных разработчиков ISP System с ником ls и за картинку именно ему и спасибо.

Всем удачной работы с почтой и поменьше спама! =)
Вопросы, поправки и т.д. буду рад увидеть в комментариях.

DNS (система доменных имен) – это «телефонная книга» Интернета. В качестве номера телефона в ней выступает IP-адрес, а в качестве наименований контактов — домены. В такую книгу можно внести не только «телефонный номер», но и дополнительную информацию о контакте («е-mail», «место работы» и т.п.).

Информация о домене хранится на DNS-серверах. Чтобы внести её в систему DNS, нужно прописать ресурсные записи . С их помощью серверы делятся сведениями о доменах с другими серверами. Пока не прописаны ресурсные записи для домена, его нет в «телефонной книге» Интернета. Следовательно, работа сайта или почты на нём невозможна. Прежде чем приступать к указанию ресурсных записей, нужно делегировать домен, то есть прописать для него DNS-серверы. Вы можете сделать это по инструкции: . Затем переходите к ресурсным записям. Изменения вступят в силу после обновления DNS-серверов (обычно до 24 часов).

Основные ресурсные записи: записи типа A, CNAME, MX, TXT и SPF. Рассмотрим их подробнее.

Запись A

Запись A (address) — одна из ключевых ресурсных записей Интернета. Она нужна для связи домена с IP-адресом сервера. Пока не прописана А-запись, ваш сайт не будет работать.
Когда вы вводите название сайта в адресную строку браузера, именно по А-записи DNS определяет, с какого сервера нужно открывать ваш сайт.

Примеры записи A:

Имя записи	Тип записи	Значение
site.ru	A	123.123.123.123
shop.site.ru	A	123.123.123.123

Прописать А-запись вы можете по инструкции:

Запись CNAME

CNAME (Canonical name) — запись, которая отвечает за привязку поддоменов (например, www.site.ru) к каноническому имени домена (site.ru) или другому домену.
Основная функция CNAME — дублирование ресурсных записей домена (A, MX, TXT) для различных поддоменов.

Примеры записи CNAME:

Имя записи	Тип записи	Значение
www.site.ru	CNAME	site.ru
webmail.site.ru	CNAME	webmail.hosting.сайт

Если вы пропишете CNAME для поддомена www.site.ru и укажете значение site.ru, сайт будет открываться с того же IP-адреса, что и site.ru . Если вы пропишете CNAME для mail.site.ru и укажете значение webmail.hosting.сайт , то на mail.hosting.сайт будут распространятся те же ресурсные записи, что для webmail.hosting.сайт.

Использование записи CNAME исключает использование других ресурсных записей для данного поддомена, то есть для поддомена webmail.site.ru или www.site.ru нельзя одновременно добавить и запись A и запись CNAME.

Прописать CNAME-запись вы можете по инструкции:

Запись MX

MX (Mail Exchanger) — запись, отвечающая за сервер, через который будет работать почта. Записи MX критически важны для работы почты. Благодаря им отправляющая сторона «понимает», на какой сервер нужно отправлять почту для вашего домена.

Примеры записи MX:

Имя записи	Тип записи	Приоритет	Значение
site.ru	MX	10	mx1.hosting.сайт
site.ru	MX	15	mx2.hosting.сайт

где mx1.hosting..

Обычно указывается два почтовых сервера, чтобы в случае недоступности одного из них почта всё же была отправлена на другой. Приоритет записи определяет, на какой сервер нужно отправлять почту в первую очередь. Чем меньше число, тем выше приоритет. Таким образом, для доменного имени site.ru почтовый сервер mx1.hosting..hosting.. Если приоритет одинаковый, сервер выбирается случайным образом.

Прописать MX-запись вы можете по инструкции:

Запись TXT

TXT (Text string) — запись, с помощью которой задаются необходимые текстовые комментарии для домена. Часто применяется для проверок на право владения доменом при подключении дополнительных сервисов, а также как контейнер для записи SPF и ключа DKIM. Можно прописывать неограниченное количество TXT-записей, если они не конфликтуют друг с другом.

Прописать TXT-запись вы можете по инструкции:

Запись SPF

SPF-запись (Sender Policy Framework) содержит информацию о списке серверов, которые имеют право отправлять письма от имени заданного домена. Позволяет избежать несанкционированного использования. Настройка SPF прописывается в TXT-записи для домена.

Пример записи SPF:

Имя записи	Тип записи	Значение
site.ru	TXT	v=spf1 include:_spf.hosting..123.123.123 a mx ~all

где 123.123.123.123 — IP-адрес нужного вам сервера.

В этом примере:

• v=spf1 — определяет версию используемой записи SPF;
• include:_spf.hosting.сайт — включает в запись SPF значение SPF-записи другого домена. То есть для домена будут действовать все значения записи SPF для домена «_spf.hosting.сайт»;
• ip4: 123.123.123.123 — разрешает приём почты с IP-адреса 123.123.123.123;
• a — разрешает приём почты с сервера, IP-адрес которого стоит в ресурсной A-записи домена. Проще говоря, с сервера, где размещён сайт;
• mx — разрешает приём почты, если отправляющий сервер указан в одной из записей MX для домена;
• ~all — если письмо пришло с сервера, который не входит в вышеперечисленный список, его стоит проанализировать более тщательно. Также иногда используется -all — в этом случае письмо не проходит дополнительных проверок и сразу отвергается.

Прописать SPF-запись вы можете по инструкции:

Записи NS, PTR, SOA являются служебными и, как правило, настраиваются автоматически.

Запись NS

NS-запись (Authoritative name server) указывает на DNS-серверы, которые отвечают за хранение остальных ресурсных записей домена. Количество NS записей должно строго соответствовать количеству всех обслуживающих его серверов. Критически важна для работы службы DNS.

Запись PTR

PTR — обратная DNS-запись, которая связывает IP-адрес сервера с его каноническим именем (доменом). PTR-запись применяется для фильтрации почты.. Если у вас заказан VPS или Dedicated-сервер, прописать PTR-запись можно по инструкции:

Запись SOA

SOA (Start of Authority) — начальная запись зоны, которая указывает, на каком сервере хранится эталонная информация о доменном имени. Критически важна для работы службы DNS. Подробнее о том, что такое SOA-запись и как её проверить, вы можете узнать .

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

Если просуммировать все записи описания ресурсов, которые предлагалось указывать в описании зоны, то посвященных электронной почте 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