Базовые DNS-записи для почтового сервера

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

Базовые DNS-записи для почтового сервера

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

Ну а теперь начнем разбираться что нужно сделать перед созданием записей.

Покупка доменного имени

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

Как только домен куплен, можно приступать к созданию записей. У всех регистраторов разные админки, но зная теорию, в специфике добавления записей разобраться проще простого.

Примечание: когда вы указываете A-запись, на которую ссылается CNAME при её создании, у некоторых регистраторов может потребоваться прописывать A-запись полностью с точкой (например record.bissquit.com.), а у кого-то достаточно вписать просто часть до домена (просто record без всего, как в прошлом примере).

Хочу сразу предупредить, что распространение только что созданных записей занимает некоторое время, обычно это от 15 минут и до нескольких часов (или в теории даже суток, но мне такое не встречалось).

A

Первым делом создайте основную A-запись, которая будет указывать на внешний адрес вашего почтового сервера. Допустимы любые варианты, но обычно выбирают что-то похожее на mail.domain.tld или mx1.domain.tld. Если вы используете собственный DNS-сервер bind, то A-запись внутри зоны может выглядеть так:

На эту запись в последствии будет указывать 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 — письмо принято к доставке):

Если же по каким-то причинам один из серверов отключился и отправляющая сторона попала в первую попытку на него, сразу же пойдет вторая попытка отправить почту на второй сервер из выдачи (после Connection timed out в первый раз идет удачная вторая попытка):

Примечание: если кого-то заинтересует дилемма выбора «правильной» иерархии MX, советую обратиться к топику DNS — MX, A, TLL и почтовый сервер на форумах Technet. Пример с логами отправки взят именно оттуда.

А теперь вернемся от теории к практике и посмотрим как же обстоят дела у крупных публичных почтовых сервисов:

Mail и Yandex используют для своих сервисов именно вариант с RR для A-записей, а вот Google — нет:

Поэтому именно вам решать какой вариант выбрать.

PTR

С PTR нет такого пространства для творчества, как в случае с MX и от этого только легче. PTR-запись принадлежит обратной зоне и призвана сопоставить ip-адрес с DNS-именем (то есть, адрес должен разрешаться в имя).

В самом идеальном случае должно происходить «круговое» разрешение записей. Что это такое, легко понять на примере: из MX получаем A-запись, из A-записи получаем ip-адрес, от этого адреса берем PTR-запись, которая в идеале должна разрешиться в A-запись, на которую указывала MX изначально. И так по кругу:

Но в реальности это явно избыточный перфекционизм. К тому же, что вы будете делать, если ваш сервер будет обслуживать несколько доменов одновременно (а ведь это очень частая ситуация)?Примечание: гипотетически вы можете создать несколько PTR для одного ip-адреса, ведь RFC прямо это не запрещает. Тем не менее, софт на клиентской стороне обычно не умеет корректно обрабатывать такую ситуацию и просто выдернет первую попавшуюся запись из выдачи. Эта запись может оказаться совсем не той, которая вам нужна. Помимо этого, большинство провайдеров просто откажут вам на просьбу создать несколько PTR. Поэтому используйте одну запись для одного адреса и позаботьтесь о том, чтобы почтовый сервер в приветствии HELO выдавал имя, в которое разрешается адрес сервера, вот и все.

Ради интереса давайте проверим тех же публичных провайдеров:

Но! ведь этот же сервер обслуживает и другие домены mail.ru, например list.ru, bk.ru:

Ну и, разумеется, их адреса будут иметь PTR абсолютно не связанную с именем, например, bk.ru. Таким образом, по сути жесткое соответствие не обязательно и вы можете использовать PTR с любым вашим доменным именем. Главное, чтобы запись существовала, ведь очень много серверов проверяют наличие PTR и, если её нет, резко повышают спам-рейтинг ваших сообщений.

И, самое главное, PTR-запись создается на стороне владельца ip-адреса. То есть, если адреса вам предоставляет интернет-провайдер, запрашивать создание записи вы должны именно у него (в админке или через менеджера).

TXT

TXT — обычная текстовая запись. Она применяется достаточно широко — от подтверждения владения доменом и до использования самыми разными механизмами фильтрации нежелательных/вредоносных сообщений (DKIM, DMARC).

В контексте изучения базовых записей DNS, TXT нас интересует прежде всего с точки зрения использования SPF (Sender Policy Framework).

Примечание: как и PTR, SPF тоже не является обязательной, но её наличие резко повышает шансы пройти антиспам-фильтры получателя. Скажем так: как минимум любую из двух записей вы иметь просто обязаны.

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

Ваша запись может иметь следующий вид:

Ничего сложного. Не так ли? На стороне почтового сервера ничего делать не нужно, в этом ещё один плюс SPF.

Никогда не игнорируйте возможность создания записи, даже если имеете дело с тестовой инфраструктурой. Например вот что может вам ответить принимающий сервер, если засомневается в вашей «чистоте» как отправителя:

Это кусок лога SMTP-сессии с сервером Mail.ru. Абсолютно неинформативная ошибка и ответ — 451 Try again later — могут легко ввести в ступор, а безрезультатная гуглежка заставит сильно приуныть. Тем не менее, после создания SPF все стало хорошо и статус вновь отправляемых сообщений изменился на Queued mail for delivery.