Как настроить почтовый сервер для обхода спам-фильтров: руководство по DNS, SPF, DKIM

Для правильной работы почтового сервера важно иметь правильно настроенную 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.

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 для почтового сервера

Многие современные методы борьбы со спамом активно используют службу DNS для выявления нежелательных сообщений электронной почты. Поэтому правильная настройка DNS-зоны для собственного сервера корпоративной почты позволит администратору избежать множества проблем с приёмом электронной почты от удалённых почтовых серверов и с отправкой электронной почты со своего почтового сервера.

Рассмотрим настройку DNS-зоны на примере наиболее распространённого DNS-сервера BIND для правильной работы почтового хостинга корпоративной почты. Итак, в доменной зоне должны в обязательном порядке быть указаны следующие записи:

Запись типа NS— Name Server, сервер имён

В записях типа NS указываются имена DNS-серверов, которые будут поддерживать доменную зону. По требованиям регистраторов доменных имён в целях доступности и отказоустойчивости их должно быть не менее двух и они должны быть расположены в различных подсетях класса C. Имя должно заканчиваться точкой иначе DNS-сервер интерпретирует имя как поддомен текущей зоны.

Запись типа MX — Mail eXcanger, сервер обмена электронной почтой

Основная запись в доменной зоне, указывающая на имена почтовых серверов этого домена, без которой невозможны приём и отправка (косвенно) почты. Невозможность отправки почты указана как косвенная потому, что подавляющее большинство почтовых серверов перед приёмом сообщения в целях защиты от спама обязательно проверит наличие в DNS-зоне MX-записей и их соответствие IP-адресу отправителя. В случае отсутствия такой записи и/или её несоответствия удалённым почтовым сервером с вероятностью чуть менее 100% в приёме электронной почты будет отказано. Указание MX-записи отличается от синтаксиса рассмотренной ранее A-записи тем, что MX поддерживает приоритеты. Приоритет MX-записи — целое число от нуля включительно, указывающее несколько возможных почтовых серверов для этого домена, и определяющее порядок их перебора почтовым сервером отправителя в случаях недоступности некоторых из них. Обратите внимание, адресом почтового сервера в MX-записи не может быть IP-адрес, только доменное имя.

В примере выше наибольшим приоритетом (0) в приёме почты обладает хост mx1.tendence.ru Именно к нему в первую очередь будут обращаться для отправки сообщений на ваш корпоративный почтовый сервер все другие почтовые серверЫ. Если по каким-то причинам в соединение с этим почтовым сервером будет отказано, отправитель перейдёт к попытке оправки почты на почтовый сервер с следующим приоритетом — 5, mx2.tendence.ru и так далее. Таким образом, MX-записи дают возможность гибкой настройки балансировки нагрузки (можно указать несколько записей с один и тем же приоритетом) и отказоустойчивости хостинга почты.

Запись типа A — Address, IP-адрес, соответствующий доменному имени

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

mail A 192.168.0.1

Запись типа PTR — PoinTeR, указатель в обратной зоне DNS

Исключительно важная запись, значение rDNS-записи в работе хостинга почты невозможно переоценить! Удалённые почтовые серверы проверяют наличие и содержимое этой записи при попытке отправить им почту и их системы антиспама придают очень веское значение результатам проверки. Рекомендуется давать им осмысленное имя, которое соответствует имени, данному почтовому серверу к MX и A-записях. Почтовые серверы Mail.Ru, например, вообще не принимают электронную почту от почтовых серверов с неправильными с их точки зрения PRT/rDNS-записями. Так, почта от хоста 4-3-2-1.dsl-pool.prodiver.ru будет отклонена из-за исчезающей вероятности наличия у серьёзного корпоративного почтового сервера такого имени. Как правило запись в эту зону вносится вашим хостером или провайдером, если вы не обладаете собственной автономной системой (AS).

1 PTR mx1.tendence.ru.

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

Запись типа TXT/SPF — TeXT, текстовая запись/Sender Policy Framework, структура политики отправителя

Замечательное средство защиты от подделки адреса отправителя, принятое в качестве стандарта RFC с 2006 года. Является эффективным, быстрым и использующим крайне мало ресурсов как со стороны отправителя, так и получателя средством. Остаётся только сожалеть, что за прошедшие годы не все почтовые домены внедрили у себя SPF-записи, если бы это произошло, спама в электронной почте стало бы на порядок меньше. Значительно снижает вероятность ложного определения сообщения с вашего сервера корпоративной электронной почты как спам. Заключается в явном указании списка IP-адресов/серверов, которые имеют право на отправку электронной почты от имени домена.

TXT «v=spf1 +mx -all»

Запись такого вида указывает используемую версию SPF — 1 (а другой пока и нет, сделано для совместимости с будущими версиями протокола), разрешает приём почты домена со всех адресов, указанных как MX-записи и запрещает приём почты со всех других почтовых серверов. Такой настройки будет достаточно в подавляющем большинстве случаев настройки корпоративной почты для предотвращения подделки адресов и снижения шансов маркировки ваших сообщений как спама.

Запись типа TXT/DKIM — TeXT, текстовая запись/Domain Keys Identified Mail, электронная почта, идентифицированная доменными ключами

Криптографическая технология, принятая в качестве стандарта с 2007 года. Как и SPF призвана предотвратить подделку адресов отправителя, уникальным образом идентифицировать его, а также подтвердить, что в процессе доставки сообщение электронной почты не было изменено. Требует поддержки почтового сервера для подписания каждого сообщения доменным ключом. Для проверки используется открытый ключ, указанный в зоне DNS:

Имя selector означает конкретный ключ (их может быть несколько), используемый для подписания сообщения, параметр v — версия DKIM, p — собственно ключ. Политика o=- указывает, что неподписанные/неправильно подписанные сообщения должны отклоняться. Настоятельно рекомендуется для применения — повсеместное внедрение этой технологии позволило бы навсегда решить проблему спама. Подключение DKIM к корпоративной почте позволит сообщениям сотрудников не быть ложно опознанными как спам у получателей. Более подробную информацию по подключению DKIM к вашему почтовому серверу ищите в документации к нему.

При перепубликации статьи установка активной индексируемой гиперссылки на источник — сайт TENDENCE.RU обязательна!Думаю, многим будет интересно наконец-то узнать, как работает почта. В нескольких статьях я попытаюсь максимально простым языком расписать все основные вопросы, связанные с работой электронной почты вообще и нужными настройками — в частности. Для простоты и сокращения количества букв мы рассмотрим простейшую (и наиболее распространенную) ситуацию: 1 доменное имя (example.com). 1 почтовый домен (*@example.com). 1 почтовый сервер (mail.example.com). 1 IP-адрес (127.127.127.127). Касательно почты, в DNS нас интересует четыре типа записей.

• A
• MX
• PTR
• TXT

Второй — обязательный, без него почта в 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-запись для электопочты. Она указывает, какими серверами обрабатывается почта для нашего домена. У нас есть один почтовый домен — .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 почтового сервера, отправляемому в HELOEHLO. 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 ip4:1.1.1.1 +a +mx -all (пример). Где:v=spf1 — версия протокола.(+-)a — разрешение или запрет отправки почты с IP, соответствующего A-записи домена.(+-)mx — разрешение или запрет отправки почты с IP, соответствующего MX-записи домена.ip4:IP — явное указание IP, с которого можно принимать почту от имени домена. (~-all) — отвергать или принимать почту от IP, не перечисленных в списке и не указанных явно. В нашем случае TXT SPF запись будет такой:example.com. IN TXT "v=spf1 +mx +a -all" Таким образом, мы разрешили прием почты от имени домена с IP, соотвествующих A или MX записям и запретили прием от других адресов — никто не сможет наспамить прикинувшись нами или обмануть наших пользователей, отправив фишинговую ссылку от имени тех. поддержки.Используемые источники:

• https://interface31.ru/tech_it/2010/10/pochtovyj-server-dlya-nachinayushhix-nastraivaem-dns-zonu.html
• https://www.tendence.ru/articles/dns-dlya-korporativnoi-pochty
• https://habr.com/post/59417/