DNS

Электронный адрес (e-mail) дает серверу полную информацию о том, кому предназначено данное сообщение и как его надо доставить. Предположим, что серверу надо доставить письмо по адресу user@example.com. Здесь "example.com" - имя почтового домена, а "user" - имя пользователя внутри этого домена. Прежде всего нужно определить какой сервер (или сервера) отвечает за почту адресованную в домен "example.com", затем соединиться с ним по протоколу SMTP и передать письмо, а дальше уже будет его задача доставить письмо пользователю. Для того, чтобы найти ответственный сервер используется DNS (Domain Name System - Система Доменных Имен). DNS-сервер хранит для имен доменов наборы записей различных типов и по запросу возвращает записи запрошенных типов для заданного домена. С точки зрения электронной почты нас интересуют записи типа MX и записи типа A.

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

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

Так, например, в нашем случае могли быть получены следующие MX записи:

В данном случае сервер должен сначала попытаться отдать почту хосту "mx1.example.com", а в случае неудачи хостам "mx2.example.com" и "mx3.example.com" (в любом порядке).

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

В нашем случае мы могли бы получить для хоста "mx1.example.com" следующие A записи:

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

Такая организация записей позволяет реализовывать:

Кластер серверов. Крупные почтовые порталы для нормальной работы могут параллельно использовать несколько серверов (кластер). Это повышает надежность системы - в случае отказа одного сервера, остальные продолжают работать. Также это распределяет нагрузку между серверами, что увеличивает быстродействие системы.
Такая структура может быть организована при помощи нескольких MX записей (с одинаковыми приоритетами), либо при помощи нескольких A записей. Поскольку почтовые сервера обычно обрабатывают записи в том порядке в котором их вернул DNS-сервер важно чтобы он возвращал их в случайном порядке, тогда нагрузка будет распределяться равномерно.

Резервирование серверов. В такой структуре есть главный сервер, который реально хранит почту и резервные сервера, которые могут ее временно принять, если главный сервер не отвечает. Для того, чтобы это реализовать заводится несколько MX записей с разными приоритетами. Главный сервер имеет самое меньшее значение приоритета (с ним будут соединяться в первую очередь), а резервные сервера имеют большее значение приоритета (с ними будут соединяться, если главный сервер не отвечает).
В нашем примере "mx1.example.com" мог бы быть главным сервером, а "mx2.example.com" и "mx3.example.com" могли бы быть резервными серверами.

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

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