mail exchanger что это

Что такое MX-запись домена

Еще не зарегистрированы?

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

MX-запись домена — что это

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

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

Например, для почтового домена example.com и почтового сервера mail.example.com запись будет выглядеть так: example.com. IN MX 10 mail.example.com, где

mail.example.com — A-имя почтового сервера.

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

Принцип работы MX записей:

Как создать MX-запись домена

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

Что нужно сделать для добавления новой записи вашего домена:

Табл. 1 Информация, которую нужно внести для создания MX-записи

Как настроить MX-запись домена

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

Как выполнить проверку MX-записи домена

Для проверки такой записи можно использовать различные инструменты (приведены в Табл. 2).

Табл. 2 какие инструменты можно использовать для проверки MX-записи

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

Источник

Mail exchanger что это

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

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

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

[name] [ttl] IN MX [prference] [host]

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

Прежде чем перейти к подробному обсуждению назначения и практики применения 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, будем называть почтовыми шлюзами.

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

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

Нас с точки зрения 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, он, в свою очередь, не может отправить почту на vega-gw.vega.ru. Себе он отправлять почту тоже не будет, поэтому отправит на relay.relarn.ru, а тот снова на ns.relarn.ru, и так по кругу.

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

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

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

Перенаправление почты осуществляется за счет добавления 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: DNS

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

Для простоты и сокращения количества букв мы рассмотрим простейшую (и наиболее распространенную) ситуацию:

1 доменное имя (example.com).
1 почтовый домен (*@example.com).
1 почтовый сервер (mail.example.com).
1 IP-адрес (127.127.127.127).

Касательно почты, в DNS нас интересует четыре типа записей.

Второй — обязательный, без него почта в 99% случаев не будет ходить вообще. Без остальных, в принципе, можно обойтись, но шансы, что ваше письмо будет отвергнуто как спам возрастают в разы — тот же mail.ru отбрасывает практически всю почту, чьи IP-адреса не имеют PTR, либо PTR относится к dial-up провайдерам. И это правильно.

A-запись

A (Address) — запись, указывающая IP-адрес нужного нам доменного имени. Для корректной работы почты требуется A-запись сервера почты (mail.example.com). Выглядеть, в нашем случае, она будет так:

mail IN A 127.127.127.127

Где:
mail — домен.
IN A — тип записи.
127.127.127.127 — IP нашего почтового сервера.

MX-записи.

MX (Mail eXchange) — основная DNS-запись для электопочты. Она указывает, какими серверами обрабатывается почта для нашего домена.

У нас есть один почтовый домен — example.com. И один почтовый сервер — mail.example.com. Соответственно, запись будет выглядеть так:

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

Где:
example.com — домен, для которого обробатывается почта.
IN MX — тип записи.
10 — приоритет записи (Подробнее — ниже).
mail.example.com — A-имя почтового сервера.

MX-запись должна указывать именно на A-запись почтового сервера. Ставить MX указателем на IP или CNAME — не правильно.

Приоритет MX-записи нужен тогда, когда существует больше одного почтового сервера для одного домена (например у Google Mail их шесть). Он указывает, к какому серверу идет обращение в первую очередь, во вторую и так далее (если первый (второй, десятый) сервер недоступен или перегружен или по другим причинам не может принять письмо). Логика простая — приоритетнее тот, цифра которого меньше. Порядок цифр — не ограничен, хоть 10-20-30, хоть 1000-2000-3000.

Если у домена нет ни одной MX-записи, либо ни один из MX-серверов не доступен, сервер отправителя попытается доставить почту на IP, указанный в A-записи домена. Это назвается А-доставкой, но в принципе не кошерно и не используется многими серверами — нужно указывать MX, даже если он всего один.

PTR-запись.

PTR (PoinTeR) — так называемая «обратная запись». Она позволяет обратное разрешение (reverse resolving) IP-адреса в FQDN-хост.

Наш IP в виде reverse будет выглядеть так: 127.127.127.127.in-addr.arpa. В данном примере видно плохо, но адрес инвертируется в обратной зоне. Т.е. IP 192.168.0.1 будет выглядеть как 1.0.168.192.in-addr.arpa.

Для корректного распознования хоста, запись IP-адреса, с которого отправляется должна соответсовать hostname почтового сервера, отправляемому в HELO\EHLO.

PTR-запись в нашем случае, соответственно:

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

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

TXT-запись и SPF.

TXT (TeXT) — текстовая запись DNS. Нам она интересна только тем, что может (и в современном мире — должна) содержать в себе SPF.

SPF (Sender Policy Framework) — запись, позволяющая вам указать, какие сервера имеют право отправлять почту от имени вашего домена (представившись вашим сервером, либо с обратным адресом в вашем домене).

Если этой записи нет, и кто-то пытается отправить письмо (как правило, спам) с обратным адресом в вашем домене — оно будет отклонено большинством серверов. Или не будет, и вы получите большие проблемы со своим дата-центром или провайдером и репутацию спамера 🙂

SPF-запись выглядит так:

v=spf1 — версия протокола.
(+\-)a — разрешение или запрет отправки почты с IP, соответствующего A-записи домена.
(+\-)mx — разрешение или запрет отправки почты с IP, соответствующего MX-записи домена.
ip4:IP — явное указание IP, с которого можно принимать почту от имени домена.
(

\-all) — отвергать или принимать почту от IP, не перечисленных в списке и не указанных явно.

В нашем случае TXT SPF запись будет такой:

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

Буду рад комментариям, готов ответить на вопросы.
В следующих статьях я напишу об SMTP, Greylisting-е и RBL.
А еще вы можете вступить в блог и тоже о чем-то рассказать.

Источник

Почему в больших компаниях любят Microsoft Exchange

В знакомой компании по просьбам сотрудников перевели почту с Яндекса на Exchange. Оказалось, не все понимают причин смены почты. В этой заметке описываю, чем удобна связка Microsoft Exchange и Microsoft Outlook для сотрудников компаний.

В заметке рассматриваю связку Microsoft Exchange и Microsoft Outlook, так как этот клиент является одним из самых популярных и в полной мере раскрывает возможности почтового сервера.

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

Disclaimer: заметка написана с позиции просвещения пользователя. Вопрос о переходе на Outlook, особенно с учетом его стоимости, каждая компания должна принимать исхода из своей конкретной ситуации.

Если использовать в качестве почтового клиента Outlook, который по умолчанию входит в Office, то становятся доступны:

Серверная адресная книга

Помощник по планированию

Работа с вложенными папками без ошибок

Работа с вложенными папками без ошибок

Другое: отзыв письма из клиента, работа с почтовыми правилами

Что-то из описанного может работать и в других серверах-клиентах, но конкретная реализация зависит от конкретной связки программ. Связку же Outlook и Exchange можно рассматривать как эталон.

Выделил этот пункт из-за его важности. Знаю, что проблема актуальна, так как инструкция по синхронизации Outlook с календарями Яндекса и Google является одной из самых популярных заметок в моем блоге.

Outlook без дополнительных усилий не умеет работать с календарём и контактами сервисов вроде Яндекс и Google. Зато с Exchange он работает отлично.

Переговорные комнаты можно занимать непосредственно из интерфейса создания приглашения на совещание в Outlook или web-интерфейсе. Нет необходимости параллельно с приглашением участников вносить бронирования в отдельный сервис или другой календарь.

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

В случае Exchange нет проблем взаимодействия с Outlook. Веб-интерфейс Exchange повторяет Outlook как визуально, так и работает с ним по единым форматам.

С другими связками могут быть проблемы. Если из интерфейса Яндекс или Google почты отправить приглашение на совещание, то другие почтовые клиенты (не только Outlook) в большинстве случаев не распознают в полученном письме приглашения. Приходится вручную добавлять событие в календарь.

Обратная ситуация тоже справедлива. Приглашения из Outlook не всегда корректно распознаются сторонними веб-клиентами.

В Яндекс.Почте между ящиками внутри одного домена письмо идёт около минуты. И в аналогичном же кейсе, придётся сидеть с коллегой и ждать пока придёт письмо.

По разным оценкам от 60% до 80% сотрудников компаний в мире в качестве корпоративной почты используют Exchange. Эта доля стабильно высока.

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

Источник

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

Основы DNS

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

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

А что же произойдет, если вы пытаетесь отправить почтовое сообщение на адрес somebody@microsoft.com?

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

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

> set type=mx

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

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 записи, попробуем понять на что же должны указывать эти записи.

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

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

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

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

Источник