Записки IT специалиста
Как правильно настроить DNS-записи для мультидоменного почтового сервера
- Автор: Уваров А.С.
- 29.03.2023
Системы электронной почты крайне чувствительны к правильной настройке DNS и этот момент часто вызывает затруднения у начинающих администраторов. Еще больше вопросов возникает если почтовая система обслуживает сразу несколько доменов. Чтобы каждый раз не отвечать одно и тоже, а также чтобы окончательно расставить все на свои места мы решили написать эту небольшую статью. Надеемся, что после ее прочтения у вас не возникнет трудности с настройкой DNS-записей для мультидоменной системы электронной почты.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Что такое мультидоменная система электронной почты? Это почтовый сервер (или группа серверов), которые осуществляют прием и отправку почты сразу для нескольких доменов, которые могут быть как связаны, так и не связаны между собой. Например, вы можете на своем сервере разместить почту соседней организации, домен которой вам не пренадлежит, все что потребуется от ваших соседей — это правильно настроить DNS.
Где нужно делать эти настройки? На сервере имен, обслуживающем DNS-зону, это могут быть сервера регистратора, хостера, публичные или собственные. Будем считать, что вы знаете где это делается и как и не будем заострять на этом внимание.
Если вы не знаете где размещена зона, то выполните команду:
где example.com — интересующий домен, в выводе вы получите сервера имен обслуживающие зону и по ним уже сможете определить, где и у кого она расположена.
В нашем примере мы будем рассматривать следующую схему:
В которой присутствую следующие домены:
- example.com — основной домен
- example.org — дополнительный домен
- example.net — дополнительный домен
Все эти домены обслуживает единственный почтовый сервер:
- mail.example.com — полностью определенное имя домена (FQDN) почтового сервера
- 198.51.100.25 — IP адрес почтового сервера
Несколько слов про основной домен, им считается тот домен, в котором расположен почтовый сервер. Понятие это сугубо условное, и вы можете разместить почтовый сервер в том домене, который вам больше нравится, либо который уже «исторически сложился» как основной для вашего предприятия. На работу почтовой системы это никак не повлияет, но настройки DNS-зоны для основного домена будут отличаться от настроек зон дополнительных доменов.
Настройка DNS-зоны основного домена
Далее мы будем касаться только записей, напрямую касающихся электронной почты. Первым делом создадим A-запись для сервера электронной почты, если вы не сделали этого ранее:
Обратите внимание, что мы указали относительное имя, поэтому оно автоматически будет дополнено суффиксом из названия доменной зоны, т.е. запись будет указывать на:
Абсолютное DNS-имя всегда оканчивается на точку, в противном случае оно будет считаться относительным. Распространенная ошибка:
Такая запись на самом деле будет указывать на узел:
Поэтому не занимайтесь лишней писаниной и везде, где можно указывать относительные имена используйте их, а абсолютные всегда завершайте точкой.
Итак, мы добавили A-запись, что нам это дает? Данная запись поможет любому желающему узнать IP-адрес нашего почтового сервера mail.example.com.
Следующим шагом добавим MX-запись, которая указывает какие именно сервера в данном домене отвечают за получение почты. Обратите внимание, что MX-запись относится именно к получению почты и не имеет никакого отношения к ее отправке. MX-записей может быть несколько, они отличаются приоритетом, чем больше число — тем ниже приоритет.
Важно понимать, что MX-запись прописывается для всего домена (это обозначается символом @ в поле узла) и для указания сервера мы должны использовать доменное имя, а не IP-адрес, в данном случае мы также указали относительное имя.
В принципе этого уже достаточно, чтобы почта заработала. Но в современных реалиях для нормальной доставки почты нам понадобятся еще кое-какие записи. Это SPF, DKIM и DMARK. В нашем случае это будет следующий набор записей:
Мы не будем подробно разбирать содержание этих записей, если коротко, то:
- SPF — позволяет указать узлы, которые имеют право отправлять почту от имени нашего домена, в данном случае это A-запись, MX-запись, остальные скорее всего такого права не имеют.
- DKIM — открытый ключ позволяющий проверить подлинность электронно-цифровой подписи письма
- DMARC — набор политик, определяющий правила проверки по SPF и DKIM и позволяющий получать отчеты о таких проверках со стороны получателя.
Более подробно все эти записи рассмотрены в нашей статье:
В целом вроде бы все, но есть одна тонкость, связанная с SPF, так как сервер у нас для всех доменов один, то нормальной практикой будет использовать для всех доменов один и тот-же набор SPF записей, через include или redirect, но как быть, если в основном домене появляется собственный отправитель, которого в других доменах быть не должно? Чтобы избежать таких ситуаций добавим еще одну SPF-запись, которая не будет использоваться в текущем домене, но на которую мы сможем ссылаться из доменов дополнительных:
Теперь, если у нас, допустим появился новый узел, отправляющий почту box.example.com, то просто делаем так:
На этом настройка DNS-зоны основного домена закончена. Если коротко, то вы должны добавить A-запись для узла почтового сервера, MX-запись, указывающую на почтовый сервер и SPF, DKIM и DMARC записи.
Настройка PTR-записи
Дочитав до конца предыдущего раздела, внимательный читатель мог воскликнуть: позвольте, как так закончена, а PTR? Так вот, PTR не имеет никакого отношения к настройке DNS-зоны основного домена. Скажем больше, технически эта запись никак не влияет на процессы отправки и получения почты, т.е. говоря проще — вообще не нужна, все будет прекрасно работать и без нее.
Но почему тогда все говорят о ее важности и необходимости? Все просто, существует соглашение, что добросовестный отправитель имеет рабочую PTR-запись, это один из механизмов защиты от спама. Это связано с тем, что обратную запись может прописать только владелец обратной зоны, т.е. владелец диапазона IP-адресов. Для этого его должен попросить об этой услуге действительный арендатор выделенного адреса. Спамер может поднять почтовый сервер на взломанном сервере, но прописать PTR для него будет проблематично, собственно, на этом и основана эта защита.
Так как мы добросовестные отправители, то обращаемся к провайдеру или хостеру, в зависимости от того, кто выделил нам белый IP-адрес и просим его прописать в обратной зоне запись для нашего почтового сервера.
Обратите внимание, PTR-запись создается не для домена, а для конкретного узла-отправителя, которым в нашем случае является сервер mail.example.com и неважно сколько еще и каких доменов он обслуживает.
В общем виде PTR-запись должна выглядеть примерно так:
Но, еще раз заостряем на это внимание, данную запись вносит ваш провайдер или хостер, не пытайтесь добавить ее самостоятельно в вашу DNS-зону, это не приведет к успеху (и является одной из самых частых ошибок).
Настройка DNS-зоны дополнительных доменов
Итак, у вас может быть сколько угодно дополнительных доменов, но настройка их DNS-зон будет идентичной. Собственного почтового сервера в этих зонах нет, поэтому мы сразу перейдем к созданию MX-записи, которая укажет какой именно узел принимает почту для этого домена:
Так как сервер находится в другом домене, то указываем абсолютное имя и не забываем завершить его точкой.
Если вы используете веб-доступ к почте и хотите, чтобы пользователи использовали адрес в собственном домене, например, mail.example.net, то добавьте еще одну запись псевдонима:
DKIM и DMARC записи в каждом дополнительном домене будут собственные:
А вот SPF имеет свои особенности, если отправитель в данном домене один, только этот почтовый сервер, то мы можем сослаться на SPF-записи основного домена, это будет наиболее правильно, так как позволит централизованно управлять SPF-записями:
Но как быть, если нужно добавить собственных отправителей? Тогда вместо перенаправления используем включение:
В этом случае к собственным записям будут добавлены записи из основной доменной зоны.
Больше никаких дополнительных записей в дополнительных зонах делать не нужно. Краткий итог: вы должны создать MX-запись, которая будет указывать на доменное имя реального почтового сервера, при желании CNAMЕ для используемых сервисов, наподобие веб-почты. DKIM и DMARK указываем собственные, а SPF подключаем от основного домена.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Что такое PTR (Reverse DNS) записи и зачем они нужны?
Что такое PTR (Reverse DNS) записи и зачем они нужны?
PTR записи или англ. Pointer – указатель, служат как обратное отображения IP-адресов в именах хостов.
Пример: PTR запись (или Reverse DNS) переводит доменное имя ns.cloudhost.lv в IP- адрес 91.220.43.5. И она же разрешает адресу 91.220.43.5 вернуться к ns.cloudhost.lv. Некоторые хостеры указывают PTR записи и для своих страничек к примеру:
В основном эти записи используется в качестве спам-фильтров. Спамеры часто подделывают доменные имена для отправки электронной почты, что в целом не будет иметь правильной PTR записи, созданной из DNS. Наличие обратного Reverse DNS – одно из основных требований многих спам-фильтров. Его отсутствие может привести к блокировке писем. Также при веб-анализе и анализе интернет-трафика используется обратный поиск Reverse DNS, чтобы узнать, какие провайдеры у ваших посетителей.
Для PTR записей нет конкретных технических требований. Тем не менее, с увеличением объёма нежелательных электронных писем (спама) они стали необходимы для некоторых схем безопасности.
Имеенно поэтому большенство провайдеров для PTR записей применяют следующее правила:
- Для каждого IP-адреса существует одна PTR запись.
- Для серверa с несколькими IP-адресами будут прописаны несколько PTR записей, по одной на каждый IP-адрес.
- Для любого почтового сервера должна быть установлена MX-запись и A-запись – это правило является одним из самых важных.
- Для каждой PTR записи должна быть А-запись, а вот но наоборот не обязательно.
Другими словами, надо уметь принимать IP-адрес, смотреть его PTR-запись, находить А-запись для этого хоста и возвращать IP-адрес.
Как создать Mutiple PTR records для mail server?
На сервере имеем десяток сайтов, каждый домен делегирован на DNS Яндекса и использует PDD.
+ На сервере имеем exim, обрабатывающий все письма с данных сайтов.
Т.к. можно прописать только одну PTR-запись, было решено обыграть это через DNS Яндекса.
Наткнулся на рекомендации:
Вариант 1.
IN MX 10 mail.mydistrict.k12.in.us
mail.mydistrict.k12.in.us. IN A 165.138.129.50
and for the ptr
50.129.138.165.in-addr.arpa. IN PTR mail.mydistrict.k12.in.us.
Then setup conical (cname) records for the pop3.mydistrict.k12.in.us and exchange.mydistrict.k12.in.us and not use A records for these.
Вариант 2.
www.example.com and www.yourdomain.example both resolve to 192.0.2.1.
The PTR for 192.0.2.1 is myhost1.yourdomain.example.
myhost1.yourdomain.example resolves to 192.0.2.1.
Как я понял в последнем варианте, создаем вымышленный поддомен для PTR и добавляем записи в DNS для каждого домена. Вопрос: правильно ли это и какой тип записи выбрать, CNAME или A?
Какие ограничения и риски при назначении нескольких доменных имен (PTR) для одного IP
Для моего обмена мне нужно создать запись PTR для многих доменов и назначить ее одному IP.
mail.x.com присвоить 51.51.51.51
mail.y.com назначить на 51,51,51,51
mail.z.com назначить на 51.51.51.51
Я прошу об этом интернет-провайдера, но я прошу и должен подтвердить, что существуют какие-либо технические ограничения и риски, связанные с назначением нескольких доменных имен для одного IP.
2 ответа 2
Ваш вопрос неверный. Запись PTR обычно используется для преобразования IP-адреса обратно в доменное имя. Важно, чтобы на серверах была запись PTR, но запись PTR может указывать только на один (суб) домен.
Скорее всего, вас интересуют записи MX, A и / или CNAME, каждая из которых может иметь отношение к настройке DNS для электронной почты, причем MX является единственным обязательным.
Нет проблем с указанием множества доменов на IP-адрес с использованием записей A (или косвенно с использованием записей CNAME или MX — которые не являются IP-адресами).
В действительности, чтобы получать почту 51.51.51.51, вам нужно следующее:
Запись «A» для почты.X.com указывает на 51.51.51.51. (При желании вы можете иметь запись «A» для каждой почты. (Любую).com запись, но это не обязательно)
Запись «MX» для каждого X.com, которая указывает на любую почту.X.com или почта. (Любая).com
Риски, связанные с назначением нескольких доменов одному IP-адресу для почты, минимальны, но вам необходимо знать о репутации почтового сервера, и если множество доменов могут ретранслировать электронную почту через этот сервер, если один из них запускается отправляя спам, сервер может попасть в черный список, что затруднит отправку всех остальных пользователей почтового сервера.
@davidgo объяснил вам все технически правильно, но, боюсь, вы не поняли.
Давайте начнем с этого:
Я прошу об этом интернет-провайдера, но я прошу и должен подтвердить, что существуют какие-либо технические ограничения и риски, связанные с назначением нескольких доменных имен для одного IP.
Техническое ограничение — Нет.
Риск — да.
Примите ситуацию, когда вы управляете автомобилем, а полицейский останавливает вас и просит у вас водительские права. Что бы вы ожидали, если бы вы дали полицейскому 3 водительских удостоверения с фотографией на каждом из них, но у каждого из них разные фамилии?