Почта: Настройка DNS-записей для Яндекс.Почты - Справочный центр Timeweb. Базовые DNS-записи для почтового сервера Почта dns
В настоящий момент использование почты на домене в Яндексе доступно в рамках сервиса Яндекс.Коннект .
4. Найдите домен, для которого планируется внести изменения, кликните на значок шестеренки и выберите "Настройки DNS".
5. Нажмите на "Добавить DNS-запись", выберите "TXT" и укажите запись, полученную в Яндекс.Коннекте. 
Как правило, требуется 10-15 минут, чтобы изменения вступили в силу.
7. После того, как изменения будут применены, нажмите "Запустить проверку" в Яндекс.Коннекте. Дождитесь подтверждения домена (как правило, выполняется очень быстро).
8. Настройте для домена DNS-записи по инструкциям ниже.
MX-запись
SPF-запись
2. Найдите домен, для которого планируется внести изменения, кликните на значок шестеренки и выберите "Настройки DNS".
3. Удалите существующие TXT-записи (предварительно скопируйте значение SPF-записи, если вы планируете отправлять почту также и с указанных в ней серверов).
V=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.yandex.net ~all
где IP1, IP2, IP3 - IP-адреса дополнительных серверов.
6. Сохраните изменения с помощью кнопки "Добавить".
DKIM-подпись
1. Получите TXT-запись с публичным ключом в Яндекс.Коннекте:
- Откройте страницу администрирования Почты .
- Перейдите на вкладку "DKIM-подписи".
- Скопируйте DKIM-подпись для нужного домена.
2. Найдите домен, для которого планируется внести изменения, кликните на значок шестеренки и выберите "Настройки DNS".
3. Удалите имеющиеся MX-записи.
4. Нажмите на "Добавить DNS-запись", выберите "MX" и в открывшемся окне отметьте пункт "Яндекс.Почта":
5. Сохраните изменения с помощью кнопки "Добавить".
6. Подождите, пока изменения в DNS вступят в силу. Этот процесс может занимать до 72 часов.
SPF-запись
2. Найдите домен, для которого планируется внести изменения, кликните на значок шестеренки и выберите "Настройки DNS".
3. Удалите существующие TXT-записи (предварительно скопируйте значение spf-записи, если вы планируете отправлять почту также и с указанных в ней серверов).
4. Нажмите на "Добавить DNS-запись", выберите "TXT" и в открывшемся окне разместите следующее значение:
V=spf1 redirect=_spf.yandex.net
5. Если вы хотите отправлять письма не только с серверов Яндекса, укажите дополнительные серверы в таком формате:
V=spf1 ip4:IP-1 ip4:IP-2 ip4:IP-3 include:_spf.yandex.net ~all
где IP-1, IP-2, IP-3 - IP-адреса дополнительных серверов.
6. Сохраните изменения с помощью кнопки "Добавить".
7. Подождите, пока изменения в DNS вступят в силу. Этот процесс может занимать до 72 часов.
DKIM-подпись
2. Найдите домен, для которого планируется внести изменения, кликните на значок шестеренки и выберите "Настройки DNS".
3. Нажмите на "Добавить DNS-запись" и выберите "TXT".
4. В окне настроек укажите "mail._domainkey" в поле "Хост" и внесите в поле "Значение" параметры DKIM с публичным ключом, полученные в Почте для домена . Например, "v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSEBtaCOteH4EBqJlKpe..."
5. Сохраните изменения с помощью кнопки "Добавить".
6. Подождите, пока изменения в DNS вступят в силу. Этот процесс может занимать до 72 часов.
CNAME-запись
2. Найдите или создайте поддомен mail.ваш_домен и кликните на значок шестеренки.
3. Нажмите на "Добавить DNS-запись" и выберите "CNAME".
4. В окне настроек внесите значение "domain.mail.yandex.net":
5. Сохраните изменения с помощью кнопки "Добавить".
6. Подождите, пока изменения в DNS вступят в силу. Этот процесс может занимать до 72 часов.
- Нет меток
ДНС – это сеть магазинов цифровой и бытовой техники, которая широко представлена на территории России. В магазинах имеется широкий выбор товаров. На официальном сайте DNS имеется возможность выбрать и приобрести любой товар, находясь в комфортной домашней обстановке. Покупку можно забрать в выбранном магазине (к указанному времени покупка будет подготовлена менеджером магазина) или заказать доставку. Для использования всех возможностей ресурса имеется удобный сервис «личный кабинет». Работает служба клиентской поддержки, с которой можно связаться через специальную форму для заказа обратного звонка.
Возможности личного кабинета ДНС
Для получения доступа в личный кабинет необходимо зарегистрироваться на сайте. Для этого потребуется указать адрес электронной почты и придумать пароль. Важно указать действующий ящик, так как для завершения процесса регистрации в обязательном порядке требуется подтверждение указанного адреса. После этого пользователю предлагается указать номер мобильного (этот пункт не является обязательным). На указанный номер будут приходить сообщения об изменении статуса текущего заказа. На этом процесс регистрации заканчивается, можно входить в личный кабинет и пользоваться всеми его возможностями.Сервис работает в круглосуточном режиме. Он позволяет оформлять заказы на товары, представленные на сайте, отслеживать их. Также в личном кабинете можно активировать карту, чтобы стать участником бонусной программы. Для получения карты необходимо предоставить номер мобильного телефона сотруднику в любом из магазинов сети (она выдается бесплатно, действует 5 лет). В любой момент в кабинете можно посмотреть количество бонусных баллов, историю их начисления. Также владельцы личных кабинетов могут увидеть все акции и другие выгодные предложения, новости компании. Актуальная информация приходит на телефон или электронную почту, которые привязаны к аккаунту.
Посредством сервиса можно задать вопрос службе технической поддержки в чате в режиме онлайн. Сохраняется история заказов и платежей. На ее основании сотрудник компании формируют выгодные индивидуальные предложения для зарегистрированных пользователей
3. Удалите имеющиеся MX-записи.
4. Нажмите на "Добавить DNS-запись", выберите "MX" и в открывшемся окне отметьте пункт Mail.ru :
5. Сохраните изменения с помощью кнопки "Добавить".
6. Подождите, пока изменения в DNS вступят в силу. Этот процесс может занимать до 72 часов.
SPF-запись
2. Найдите нужный домен, кликните на на значок шестеренки и выберите "Настройки DNS".
3. Удалите имеющиеся TXT-записи, начинающиеся с v=spf1 (предварительно скопируйте значение spf-записи, если вы планируете отправлять почту также и с указанных в ней серверов).
4. Нажмите на "Добавить DNS-запись", выберите "TXT" и в открывшемся окне разместите следующее значение:
V=spf1 redirect=_spf.mail.ru
5. Если вы хотите отправлять письма не только с серверов Mail.ru, укажите дополнительные серверы в таком формате:
V=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.mail.ru ~all
где IP-1, IP-2, IP-3 - IP-адреса дополнительных серверов.
6. Сохраните изменения с помощью кнопки "Добавить".
7. Подождите, пока изменения в DNS вступят в силу. Этот процесс может занимать до 72 часов.
DKIM-подпись
2. Найдите нужный домен, кликните на на значок шестеренки и выберите "Настройки DNS".
3. Нажмите на "Добавить DNS-запись" и выберите "TXT".
4. В открывшемся окне настроек:
- в поле "Хост" укажите mailru._domainkey
- в поле "Значение" внесите параметры DKIM, полученные в личном кабинете https://biz.mail.ru/ в разделе " ".
Для правильной работы почтового сервера важно иметь правильно настроенную 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 часа после внесения изменений, у вашего партнера почта может не отправляться к вам в течении более длительного времени.
Для меня загадка почему развертывание даже примитивной конфигурации почтового сервера для многих системных администраторов является столь серьезной проблемой. Тем не менее, это так. Мне бы никогда не пришло в голову писать об этом целую статью, но судя по неиссякаемому количеству вопросов, это сделать все же необходимо. Больше всего сложностей вызывают базовые DNS-записи для почтового сервера, о них и поговорим.
Если вам интересна тематика почтовых серверов, рекомендую обратиться к соответствующим тегам на моем блоге — и .
В статье рассмотрены базовые записи, которые либо необходимы, либо крайне желательны для нормального функционирования почтового сервера.
Ну а теперь начнем разбираться что нужно сделать перед созданием записей.
Покупка доменного имени
Начать необходимо с покупки доменного имени. Это не так сложно, как кажется и не так дорого. Новый домен в.ru-зоне может стоить не больше 100-200 рублей.
Как только домен куплен, можно приступать к созданию записей. У всех регистраторов разные админки, но зная теорию, в специфике добавления записей разобраться проще простого.
Примечание: когда вы указываете A-запись, на которую ссылается CNAME при её создании, у некоторых регистраторов может потребоваться прописывать A-запись полностью с точкой (например record.bissquit.com.), а у кого-то достаточно вписать просто часть до домена (просто record без всего, как в прошлом примере).
Хочу сразу предупредить, что распространение только что созданных записей занимает некоторое время, обычно это от 15 минут и до нескольких часов (или в теории даже суток, но мне такое не встречалось).
A
Первым делом создайте основную A-запись, которая будет указывать на внешний адрес вашего почтового сервера. Допустимы любые варианты, но обычно выбирают что-то похожее на mail.domain.tld или mx1.domain.tld . Если вы используете собственный DNS-сервер bind, то A-запись внутри зоны может выглядеть так:
Shell
mail IN A 1.2.3.4
mail IN A 1.2.3.4 |
На эту запись в последствии будет указывать MX.
MX
Эта запись переводится как mail-exchanger и, собственно, она и является основной для почтовых серверов. Таких записей может быть несколько и каждая из них обязательно имеет значение приоритета — чем оно меньше, тем приоритет выше. Для чего это используется? Главным образом для определения очередности обращения к MX-записям, если их несколько.
Часто встречается, что несколько MX-записей для одного и того же домена имеют одинаковый приоритет. В этом случае входящий трафик будет равномерно балансироваться между серверами.
Примечание: строго говоря, наличие связанной MX-записи для вашего отправляющего сервера не так уж и обязательно. Отправить почту вы сможете без проблем и серверы целевого домена её даже получат. Но, вероятно, на принимающих серверах почта мгновенно попадет в спам, поскольку отправляющие домены без MX сразу же помечаются как подозрительные. Возникнуть проблемы могут также и с получением почты, хотя в теории доставка письма в отсутствии записи MX должна выполняться на основную A-запись домена (согласно RFC 5321).
Если углубляться в архитектуру почтовых решений, то очень часто запись MX указывает на mail-relay или сервер антиспама (spamassasin, например, или Exchange Server Edge), а не на конечный почтовый сервер, сохраняющий входящие/исходящие письма. Это вполне разумный подход, когда отдельный сервер выступает в качестве пограничного шлюза, а другой — с критически важными данными для бизнеса — своеобразным бэкэндом. Я скажу больше — это даже best practice.
Сколько MX надо для счастья
Сообразительному читателю может прийти в голову очень интересная мысль: «А что лучше — две записи MX или одна запись MX, но ссылающаяся на две одинаковые A-записи?». Визуально это выглядит вот так:
В случае b. получается своеобразный Round Robin. Но, если отбросить нюансы, вариант a. аналогичен! Ведь одинаковый приоритет MX-записей обеспечивает такую же функцию.
Тем не менее, и в этом случае у многих возникают сомнения. Главным образом они обуславливаются мнением, что в случае b., если отправляющий сервер в первой попытке отправки попадет на неработающий сервер, то он отложит отправку и попробует в следующий раз, спустя таймаут. Но это в корне неверно — он попробует отправить на второй сервер из выдачи RR сразу же. Это демонстрирует наглядный эксперимент.
Когда на запросы отвечают оба сервера из варианта b., мы видим следующую запись в smtp-сессии при попытке отправки на них письма (Queued mail for delivery — письмо принято к доставке):
Shell
Feb 14 13:57:37 mail postfix/smtp: ACF0D140073: to= |
Если же по каким-то причинам один из серверов отключился и отправляющая сторона попала в первую попытку на него, сразу же пойдет вторая попытка отправить почту на второй сервер из выдачи (после Connection timed out в первый раз идет удачная вторая попытка):
Shell
Feb 14 14:02:16 mail postfix/smtp: connect to mail.domain.tld:25: Connection timed out
Feb 14 14:02:17 mail postfix/smtp: 35E8F140073: to=
Feb 14 14:02:16 mail postfix/smtp: connect to mail.domain.tld:25: Connection timed out Feb 14 14:02:17 mail postfix/smtp: 35E8F140073: to= |
Примечание: если кого-то заинтересует дилемма выбора «правильной» иерархии MX, советую обратиться к топику DNS — MX, A, TLL и почтовый сервер на форумах Technet. Пример с логами отправки взят именно оттуда, я же являюсь и его автором.
А теперь вернемся от теории к практике и посмотрим как же обстоят дела у крупных публичных почтовых сервисов:
Shell
# dig -t MX mail.ru +short 10 mxs.mail.ru. # dig -t A mxs.mail.ru +short 94.100.180.104 94.100.180.31 # # # dig -t MX yandex.ru +short 10 mx.yandex.ru. # dig -t A mx.yandex.ru +short 213.180.204.89 77.88.21.89 213.180.193.89 87.250.250.89 93.158.134.89
# dig -t MX mail.ru +short # dig -t A mxs.mail.ru +short # dig -t MX yandex.ru +short 10 mx.yandex.ru. # dig -t A mx.yandex.ru +short |
Mail и Yandex используют для своих сервисов именно вариант с RR для A-записей, а вот Google — нет:
Shell
# dig -t MX gmail.com +short 5 gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com.
# dig -t MX gmail.com +short 5 gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. |
Поэтому именно вам решать какой вариант выбрать.
PTR
С PTR нет такого пространства для творчества, как в случае с MX и от этого только легче. PTR-запись принадлежит обратной зоне и призвана сопоставить ip-адрес с DNS-именем (то есть, адрес должен разрешаться в имя).
В самом идеальном случае должно происходить «круговое» разрешение записей. Что это такое, легко понять на примере: из MX получаем A-запись, из A-записи получаем ip-адрес, от этого адреса берем PTR-запись, которая в идеале должна разрешиться в A-запись, на которую указывала MX изначально. И так по кругу:
Но в реальности это явно избыточный перфекционизм. К тому же, что вы будете делать, если ваш сервер будет обслуживать несколько доменов одновременно (а ведь это очень частая ситуация)?
Примечание: гипотетически вы можете создать несколько PTR для одного ip-адреса, ведь RFC прямо это не запрещает. Тем не менее, софт на клиентской стороне обычно не умеет корректно обрабатывать такую ситуацию и просто выдернет первую попавшуюся запись из выдачи. Эта запись может оказаться совсем не той, которая вам нужна. Помимо этого, большинство провайдеров просто откажут вам на просьбу создать несколько PTR. Поэтому используйте одну запись для одного адреса и позаботьтесь о том, чтобы почтовый сервер в приветствии HELO выдавал имя, в которое разрешается адрес сервера, вот и все.
Ради интереса давайте проверим тех же публичных провайдеров:
Shell
# dig -t MX mail.ru +short 10 mxs.mail.ru. # dig -t A mxs.mail.ru +short 94.100.180.104 94.100.180.31 # dig -x 94.100.180.104 +short mxs.mail.ru.
Ну и, разумеется, их адреса будут иметь PTR абсолютно не связанную с именем, например, bk.ru. Таким образом, по сути жесткое соответствие не обязательно и вы можете использовать PTR с любым вашим доменным именем. Главное, чтобы запись существовала, ведь очень много серверов проверяют наличие PTR и, если её нет, резко повышают спам-рейтинг ваших сообщений.