Запись Mail exchanger (MX). Электронная почта и DNS. Основы службы Email: Что такое MX запись

Одним из основополагающих принципов построения любой почтовой системы в современной сети – наличие и правильная настройка MX записей в DNS. К сожалению, далеко не все почтовые администраторы досконально понимают что такое MX запись и какова ее роль в организации почтовой системы домена.

Основы DNS

Аббревиатура MX расшифровывается как “mail exchanger” (почтовый обменник). MX запись это один из видов DNS записей, поэтому для того, чтобы понять что такое MX запись необходимо понимать основы архитектуры и функционирования службы DNS (Domain Name System).

Наиболее важная функция службы DNS – преобразование имен доменов в IP адреса. Например, если вы в адресной строке вашего браузера набираете www.microsoft.com, то служба DNS позволяет определить IP адрес сервера с которым необходимо установить соединение. В этом примере имя домена — microsoft.com.

А что же произойдет, если вы пытаетесь отправить почтовое сообщение на адрес [email protected]?

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

1. Определение авторитетного сервера имен (NS или name server)для домена microsoft.com
2. Запрос к серверу имен домена microsoft.com на получение всех MX записей
3. Разрешение имен серверов MX записей в их IP адреса

Если вы хотите вручную определить MX записи для домена microsoft.com, то эта процедура будет выглядеть так:
C:\>nslookup
Default Server: UnKnown
Address: 10.0.1.9

> set type=mx
> microsoft.com
Server: UnKnown
Address: 10.10.21.19

Non-authoritative answer:
microsoft.com MX preference = 10, mail exchanger = mail.messaging.microsoft.com

mail.messaging.microsoft.com internet address = 216.32.181.178
Итак, мы узнали – что IP адрес «почтового обменника» для домена for microsoft.com -216.32.181.178.

MX Preferences

Еще одним нюансом функционирования почтовой службы – возможность задания приоритета почтового сервера, эта технология называется «MX preference». Чтобы понять, что такое MX preference, познакомимся с DNS и MX-записями домена google.com.
> google.com
Server: UnKnown
Address: 10.10.21.19

Non-authoritative answer:
google.com MX preference = 10, mail exchanger = aspmx.l.google.com
google.com MX preference = 20, mail exchanger = alt1.aspmx.l.google.com
google.com MX preference = 30, mail exchanger = alt2.aspmx.l.google.com
google.com MX preference = 40, mail exchanger = alt3.aspmx.l.google.com
google.com MX preference = 50, mail exchanger = alt4.aspmx.l.google.com

aspmx.l.google.com internet address = 74.125.39.27
alt1.aspmx.l.google.com internet address = 209.85.173.27
alt2.aspmx.l.google.com internet address = 74.125.127.27
alt3.aspmx.l.google.com internet address = 209.85.225.26
alt4.aspmx.l.google.com internet address = 74.125.65.26
Как вы видите, для домена google.com существует 5 различных MX записей (пять почтовых серверов) с различным значением параметра preference. Параметр preference позволяет задать приоритет каждой MX записи, т.е. определяет в какой последовательности на эти сервера будут осуществляться попытки доставить письмо. Меньшее значение соответствует боле высокому приоритету, т.е. именно на этот почтовый сервер будут отправлять письма в первую очередь.

Несколько MX записей нужны для:

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

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

На что же должны указывать MX записи?

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

Если ваша организация содержит и поддерживает почтовую систему самостоятельно (получает почту напрямую), тогда MX запись вашего домена должна указывать на внешний IP адрес вашего сетевого экрана (если используется технология трансляции адресов / портов NAT/PAT) или же внешний адрес вашего почтового сервера (например, это может быть сервер с ролью Edge Transport, или же почтовый MTA на базе Linux).

Если в вашей компании для фильтрации почты используете некий внешний «облачный» сервис, тогда MX записи вашего домена должны указывать на IP адрес, указанный провайдером этого сервиса.

Это два наиболее распространенных примера, встречающихся на данный момент, однако существует ряд других сценариев: геораспределенные сети, гибридные облачно-физические сети и т.д.

Вот и все! В данной статье мы вкратце познакомились с понятием 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

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

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

Что нам понадобиться? Выделенный IP адрес (допустим 11.22.33.44), который вы должны получить у своего провайдера. Доменное имя (например example.com), его можно зарегистрировать у любого регистратора или их партнера. При регистрации у партнера уточняйте, предоставляет ли он доступ к управлению DNS зоной, иначе придется потратить дополнительное время, нервы и деньги на перенос домена к регистратору.

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

Итак, домен у нас есть. Какие записи содержит его DNS зона? Во первых это SOA запись - описание зоны. Мы не будем подробно разбирать все записи, это выходит за рамки нашей статьи, но иметь общее представление о них необходимо. Также должны быть две NS записи, указывающие на сервера имен (DNS сервера) обслуживающие данный домен, это будут сервера регистратора или хостинг провайдера.

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

Чаще всего встречается этот вариант, но при необходимости вы всегда сможете создать A запись сами. Данная запись имеет вид

Example.com. IN A 22.11.33.44

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

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

Example.com. IN MX 10 mail.example.com.

Также можно написать просто:

Example.com. IN MX 10 mail

К такому имени (без точки на конце) example.com будет добавлено автоматически. Цифра 10 определяет приоритет сервера, чем она меньше, тем выше приоритет. Кстати, DNS зона уже может содержать MX запись вида:

Example.com. IN MX 0 example.com.

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

Теперь создадим A запись для mail.example.com

Mail.example.com. IN A 11.22.33.44

Теперь вся почта для домена example.com будет направляться хосту mail имеющему адрес 11.22.33.44, т.е. вашему почтовому серверу, в то-же время сайт example.com продолжит работать на сервере провайдера по адресу 22.11.33.44.
Может возникнуть вопрос, а почему нельзя сразу указать в MX записи IP адрес почтового сервера? В принципе можно, некоторые так и делают, но это не соответствует спецификациям DNS.

Также можно сделать алиасы для почтового сервера типа pop.example.ru и smtp.example.ru . Зачем это надо? Это позволит клиенту не зависеть от особенностей вашей инфраструктуры, один раз прописав настройки. Допустим, что ваша компания разрослась и выделила для обслуживания внешних клиентов отдельный почтовый сервер mail1 , все что вам понадобиться, это изменить две DNS записи, клиенты и не заметят того, что работают с новым сервером. Для создания алиасов используются записи типа CNAME:

Pop IN CNAME mail.example.com.
smtp IN CNAME mail.example.com.

На этом настройку прямой DNS зоны можно считать законченной, остается самое интересное - обратная зона. Обратная зона управляется провайдером, выдавшим вам IP адрес и самостоятельно управлять ей вы не можете (если только вы не владелец блока IP адресов). Но добавить как минимум одну запись в обратную зону необходимо. Как мы писали в прошлой статье, многие почтовые сервера проверяют PTR записи (записи обратной зоны) для отправляющего сервера и при их отсутствии или несовпадении с доменом отправителя такое письмо будет отклонено. Поэтому попросите провайдера добавить для вас запись вида:

44.33.22.11.in-addr.arpa. IN PTR mail.example.com.

Немного странный вид, не правда ли? Разберем структуру PTR записи более подробно. Для обратного преобразования имен используется специальный домен верхнего уровня in-addr.arpa. Это сделано для того, чтобы использовать для прямого и обратного преобразования имен одни и те же программные механизмы. Дело в том, что мнемонические имена пишутся слева направо, а IP адреса справа налево. Так mail.example.com. означает что хост mail находится в домене example, который находится в домене верхнего уровня com., 11.22.33.44 означает что хост 44 находится в подсети 33, которая входит в подсеть 22, принадлежащую сети 11. Для сохранения единого порядка PTR записи содержат IP адрес "задом наперед" дополненный доменом верхнего уровня in-addr.arpa.

Проверить MX и PTR записи также можно командой nslookup используя дополнительный параметр -type=MX или -type=PTR

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

mx2.сайт. приоритет 10
mx3.сайт. приоритет 10
mx4.сайт. приоритет 100

Обращаем внимание, что MX-запись должна включать в себя точку в конце.

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

Если необходимо настроить приём почты сторонним почтовым сервером, например, почтовой системой yandex, нужно сделать следующее чтобы направить почту на сервер mx.yandex.net:

1. Зайти в панель управления , выбрать пункт «Домены». Нажать на необходимый домен, например, example.ru и убрать галку напротив «Принимать почту».
2. В «Настройке параметров DNS » для домена example.ru нужно добавить MX-запись. Необходимо выбрать тип «MX», написать строку «mx.yandex.net.» (точка на конце обязательна) и выставить приоритет 10. Затем нажать на «Добавить в записи».
3. 
   

Настройка записей MX для приёма почты на собственный почтовый сервер

Если есть собственный почтовый сервер (например в офисе компании), который должен принимать входящую почту:

1. Необходимо зайти в панель управления , выбрать пункт меню «Домены».
   Для нужного необходимо добавить поддомен. Например, для домена example.ru в столбце «Поддомены» можно добавить mx.example.ru (необходимо нажать на ссылку «Добавить» и дописать mx в поле перед example.ru. После этого нажать на кнопку «Добавить»).
2. Выбрать добавленный поддомен mx.example.ru, нажав на него, затем перейти на «Настройку параметров DNS »
   Здесь необходимо добавить А-запись, в качестве значения указать IP-адрес почтового сервера.
3. После этого требуется снова нажать на домен example.ru и убрать галку напротив «Принимать почту»
   (При этом может появиться ошибка, указывающая на то, что существуют почтовые ящики, использующие установленные домена. Для устранения ошибки необходимо зайти в пункт меню «Почта» и удалить все почтовые ящики, привязанные к домену, кроме служебных и технических).
4. В «Настройке параметров DNS » для домена example.ru осталось добавить MX-запись (из выпадающего списка необходимо выбрать «MX», затем ввести приоритет, например, 10 и «mx.example.ru.» (точка на конце обязательна). Затем нажать «Добавить в записи».
5. После первого внесения каких-либо изменений в настройки домена он приобретает статус и автоматически утрачивает префикс www и стандартные А и MX записи.
   Чтобы сайт example.ru после внесённых изменений отзывался так же по www.example.ru, необходимо добавить поддомен www.example.ru и, после создания, привязать его к сайту, к которому уже привязан домен example.ru.

Материал из Insales Wiki

Общая информация

Некоторые интернет-сервисы, предоставляющие услуги электронной почты, позволяют использовать почтовый адрес на домене пользователя, то есть адрес вида mymail@mydomain . Разумеется, это можно также реализовать, используя свой собственный почтовый сервер.

Если для магазина зарегистрирован свой домен, целесообразно использовать эту возможность. Настройка собственного почтового сервера описана здесь не будет, остановимся только на наиболее известных сервисах, предоставляющих услуги электронной почты в интернете. Кроме настроек сервиса у поставщика почтовых услуг, требуется ещё поменять некоторые настройки DNS у регистратора доменных имён.

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

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

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

Настройка почты в своём домене на Яндексе

В одном домене можно создать до 100 почтовых аккаунтов - этого хватит для небольшой фирмы. Владельцы таких почтовых ящиков смогут пользоваться бесконечным пространством для писем. Работать с почтой можно как через веб-интерфейс на странице http://mail.yandex.ru/for/mydomain , так и через почтовые клиенты - The Bat, Thunderbird и другие с помощью протоколов POP3/IMAP и SMTP.

Нужно настроить для домена CNAME-запись с поддомена mail на адрес domain.mail.yandex.net. Требуется указать такие настройки:

• Имя поддомена – mail
• Тип записи – CNAME
• Данные – domain.mail.yandex.net.

Чтобы настройки вступили в силу потребуется некоторое время (от нескольких часов до двух дней).

Настройка почтовых программ

Пользоваться Яндекс.Почтой для домена можно не только через веб-интерфейс, но через различные почтовые клиенты (например, Outlook Express, The Bat, Thunderbird и другие)

Работа почтовых клиентов настраивается точно так же как для обычной Яндекс.Почты , за исключением того, что в качестве имени (логина) пользователя необходимо указывать полный e-mail (например, [email protected]).

Обращаем Ваше внимание на то, что для работы с почтой по протоколу IMAP должна быть включена его поддержка на странице «Настройки» в разделе «Почтовые клиенты».

Настройка почты GMail в своём домене

Сервис Google Apps позволяет использовать почту GMail на Вашем домене, при этом, Вы сможете использовать интерфейс GMail для доступа к ней. Также работают протоколы POP3, SMTP, IMAP. GMail предоставляет более 2 ГБ дисковой квоты для каждого аккаунта, и 7 ГБ суммарно (бесплатный базовый сервис - до пяти аккаунтов), в каждом аккаунте можно создавать до 50 почтовых записей. В GMail имеется спам-фильтр. Вы можете быть уверены, что вашу почту не просматривают; никакие органы не смогут получить копии ваших писем. Доступ к почте осуществляется посредством протокола HTTPS. Сервис бесплатен. Всё, что Вам понадобится - это доменное имя.

Создание аккаунта на Google Apps

Если у Вас ещё нет аккаунта, то перейдите по этой ссылке Регистрация в Google Apps . и нажмите на "Начать здесь".

Заполните необходимые поля для регистрации

Введите имя пользователя (Ваш адрес будет выглядеть как [email protected], где user - имя пользователя), пароль и код с картинки

Аккаунт создан.

Активация страниц входа и подтверждение права на домен

Вот как можно включить страницу входа для почтовых аккаунтов Вашего домена и подтвердить, что Вы являетесь владельцем домена, связанного с Вашим аккаунтом Служб Google . Войдите в панель управления через аккаунт администратора https://www.google.com/a/cpanel/example.ru/Dashboard . (здесь example.ru - имя Вашего домена)

Выберите удобный Вам способ подтверждения прав.

Следуйте приведенным инструкциям для загрузки файла HTML на ваш веб-сайт или другим способам.

Выполнив все действия нажмите "Подтвердить".

Создание пользовательских аккаунтов

1. Войдите в панель управления через аккаунт администратора https://www.google.ru/a/example.ru (если ещё не вошли).
2. В разделе "Пользователи и группы" верхнего меню нажмите "Создать новый аккаунт пользователя"

3.Введите имя, фамилию и имя пользователя.

4.Можно выбрать пароль на свое усмотрение, нажав "Изменить пароль".

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

Внимание! Если Вы регистрировали домен через InSales, то для того, чтобы прописать MX и CNAME-записи обратитесь в нашу техподдержку!

Настройка WEB-интерфейса для доступа к почте

Настроим доступ к почтовому интерфейсу на адрес http://mail.example.ru . Порядок простой, входим в почту через предлагаемую стандартную форму Google: https://www.google.ru/a/example.ru , жмём в верхнем правом углу ссылку "Управление доменом". Попадаем в панель управления доменом и выбираем там в главном меню "Настройки службы" - "Электронная почта". Ну а дальше - задаём URL в поле "Вэб-адрес Ваши пользователи могут просмотреть почту на странице". Применяем и, если у Вашего домена есть CNAME запись mail.mydom.com для ghs.google.com, то почта будет открываться в браузере по адресу http://mail.example.ru .

Настройка почтовых клиентов

Можно получать и отправлять почту при помощи почтовых клиентов TheBat, Thunderbird и других. В них, в большинстве случаев, для получения почты используется протокол POP3, а для отправки SMTP.

Для работы POP3 необходимо включить в настройках почтового аккаунта Google POP3 . Для этого:

1. Войдите в свой аккаунт Gmail.
2. Нажмите на ссылку "Настройки" в верхней части любой страницы Gmail.
3. Нажмите на ссылку "Пересылка и POP" в оранжевом поле "Настройка почты".

Затем, в настройках (профиле) программы-клиента необходимо настроить порты и протоколы:

Логин: [email protected] (полный адрес)

Отмена внесённых изменений

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