В наших прошлых материалах мы уже рассматривали настройку DNS-зоны для правильной работы почтового сервера, а также роль отдельных DNS-записей. Однако, как показывает практика, не все администраторы правильно понимают механизм работы систем электронной почты с DNS-записями. Поэтому мы решили посвятить этому вопросу отдельную статью, в которой разберем его более глубоко и расскажем о сравнительно новой технологии SPF.
Основная проблема современных почтовых систем - спам. Существует много разных методик борьбы с ним, но основная - анализ отправителя, учитывая что вся необходимая информация в письме имеется.
Проведем аналогию с обычной почтой. На почтовом конверте или бандероли всегда содержатся адрес отправителя, адрес получатели и штампы тех почтовых отделений в которых побывало это почтовое отправление. Точно также электронное письмо в своих заголовках содержит сведения об отправителе, получателе и отметки тех почтовых серверов, которые принимали участие в обработке почты.
Допустим вы получили на почте крайне подозрительного вида посылку, якобы от любимого дедушки Константина Макаровича, но почему то штемпель отправителя указывает не на почтовое отделение села Макаровки, а на хутор Гадюкино совсем в другом конце страны. Будете вы открывать такую посылку, рискуя обнаружить вместо банки варенья из райских яблочек споры сибирской язвы, или отправите ее назад, от греха подальше?
Точно также и в системах электронной почты. Если вам пришло письмо от дедушки [email protected] , но сервер отправитель почему-то mail.spam.com , то это повод не принимать такое письмо, так как оно с большой долей вероятности является спамом.
Каким образом мы осуществили данную проверку? Очень просто, посмотрели на штемпель почтового отделения отправителя и сравнили его с обратным адресом. Например на конверте написано, что отправитель находится в городе Москва, однако на штемпеле отделения-отправителя стоит индекс 683000, который указывает на Петропавловск-Камчатский. Следовательно такое письмо мы принимать не будем, так как оно не прошло проверку отправителя.
Аналогично обстоит дело и с электронным письмом, только вместо индекса отделения-отправителя используется PTR-запись . Так получив письмо от дедушки, мы сделаем PTR-запрос и выясним, что сервер отправитель у нас mail.spam.com , в то время как согласно переданной при соединении информации должен быть mail.example.com . Все понятно, письмо падает в спам.
Однако если в заголовке будет указано, что сервер отправитель у нас mail.spam.com , то такое письмо успешно пройдет проверку по PTR-записи , не смотря на то, что домен сервера отправителя не совпадает с почтовым доменом письма.
Почему так происходит? Потому что проверка по PTR-записи позволяет определить лишь то, что сервер-отправитель действительно тот, за кого себя выдает. Но никоим образом не определяет подлинность самого отправителя. Т.е. обращаясь к примеру обычной почты мы проверяем лишь то, что обратный адрес и индекс отделения отправителя совпадают, если место отправления Москва, а индекс указывает на Петропавловк-Камчатский, то проверку по PTR такое письмо не прошло, а если место отправления и индекс совпадают, то все нормально и теперь уже ваша задача думать, что делает ваш любимый дедушка в Петропавловске-Камчатском.
Непонимание этого момента приводит к тому, что PTR-запись оказывается настроена неправильно и, как результат, большая часть отправляемой почты не доходит до адресата. Особенно важно это понимать при настройке серверов обслуживающих несколько доменов. В этом случае PTR-запись должна указывать на имя почтового хоста (которое он передает в рамках SMTP-сессии), даже если он расположен в другом домене.
Разберем простой пример.
Сервер mail.example.com отправляет письмо для обслуживаемого им домена eхample.org . Сервер-получатель делает запрос PTR-записи и убеждается, что по адресу 123.123.123.123 действительно находится mail.example.com , следовательно такое письмо будет принято, хотя домен отправителя письма и домен сервера-отправителя не совпадают.
А теперь иная ситуация.
Администратор неправильно настроил DNS-зону, указав неправильный хост в PTR-записи . Cервер-получатель, проверив PTR-запись отклонит наше письмо, так как сервер отправитель не совпадает с результатом обратного DNS-запроса.
Отсутствие PTR-записи практически всегда ведет к отклонению письма, потому как существует негласное соглашение о том, что добросовестный отправитель имеет правильно настроенную обратную зону.
Вернемся к нашему дедушке. Допустим он сообщил вам, что летом собирается выезжать из села Макаровки в соседнее село Ивановка, к некой Марфе Васильевне и намерен оттуда посылать вам корреспонденцию. В таком случае вы без опаски будете принимать письма от дедушки как из Макаровки, так и из Ивановки, но откажетесь от якобы дедушкина письма из Петропавловска-Камчатского.
Подобная технология в системах электронной почты реализуется с помощью технологии SPF . Если коротко, то данная технология позволяет создать специальную DNS-запись, которая будет указывать, кто именно имеет право отправлять почту от имени вашего домена. В самом простом варианте запись будет иметь вид:
Example.com. IN TXT "v=spf1 +a +mx -all"
Что она означает? То, что для домена example.сom почту могут отправлять узлы указанные в А-записи (+а) и MX-записях (+mx), всю остальную почту следует отклонять (-all).
Однако не все так радужно. Во первых, поддержка SPF все еще не является стандартом де-факто и отсутвие SPF-записи у домена отправителя не повод отклонять письмо. Вторая проблема - сервера пересылки или случаи когда почту отправляют сервера не указанные в А или MX записях, а то и вообще находящиеся в других доменах. Это может быть обусловлено как архитектурой IT-системы предприятия, так и использованием для отправки чужих серверов, когда вы привязываете свой домен к провайдерскому или публичному сервису. В последнем случае нужно быть особо осторожным и крайне желательно проконсультироваться с поддержкой сервиса.
Рассмотрим еще одну ситуацию.
Ваша компания, кроме своего основного почтового сервера mail.example.com , использует услуги сторонних сервисов, которые могут отправлять почту клиентам компании от ее имени. Это может быть сервис экспресс-почты, который от вашего имени будет уведомлять клиентов о статусе доставки и т.п.
В нашем примере такая почта будет отправляться от имени [email protected] с сервера mail.web-service.com , так как данный сервер не указан в MX-записях домена example.com , то, согласно указанному нами в SPF-записи правилу, такое письмо будет получателем отклонено.
Причем поведение сервера-получателя будет однозначным, так как мы сами вполне однозначно указали, что почту от иных отправителей принимать не следует. Поэтому если вы не уверены, что вся почта будет идти исключительно с ваших серверов, то следует указать более мягкое правило:
Example.org. IN TXT "v=spf1 +a +mx ~all"
В отличие от -all (fail), ~all (soft fail) обозначает, что отправители, кроме указанных явно, не имеют права отправлять почту, но не содержит требования отклонять такие письма. Чаще всего такая почта принимается, помечаясь как нежелательная .
Можно также использовать нейтральный префикс:
Example.org. IN TXT "v=spf1 +a +mx ?all"
В этом случае правило сообщает о том, что отправлять почту от имени нашего домена имеют право хосты указанные в A- и MX- записях, насчет остальных узлов никакой информации нет. Прием почты с явно не разрешенных узлов производится на усмотрение сервера-получателя, чаще всего такая почта будет принята без каких либо пометок.
Как быть в нашем случае? Самым правильным решением будет добавить в SPF-запись еще одно правило:
Example.org. IN TXT "v=spf1 +a +mx +mx:web-service.com -all"
Example.org. IN TXT "v=spf1 +a +mx +a:mail.web-service.com -all"
в первом случае мы разрешим прием почты также от всех серверов, перечисленных в MX-записях домена web-service.com , во втором случае только для сервера mail.web-service.com .
В завершение рассмотрим случай, когда почта для вашего домена обслуживается сервером находящимся в другом домене. Например mail.example.com отправляет также почту для домена example.org . В этой ситуации будет правильно использовать для домена example.org те же самые правила, что и для example.com . Для этого используйте специальный вид записи:
Example.org. IN TXT "v=spf1 redirect=example.com"
Это позволит при необходимости изменять записи только один раз, для основного домена и избавляет администраторов иных обслуживаемых доменов от необходимости отслеживать и вносить изменения в DNS-записи.
Теги:
Существует много типов DNS записей и для новичков может быть слишком сложно понять, какая функция у этой DNS-записи или как ее настроить. В этом уроке вы узнаете, что такое PTR запись и как проверить настроена ли она для IP-адреса.
Что такое PTR запись
PTR запись – это как обратная версия A записи. A запись связывает доменное имя с IP адресом, а PTR запись связывает IP адрес с именем хоста. Однако эти две записи являются независимыми друг от друга..21.128.xx , тогда как 23.23.128.xx может быть связан с совершенно другим именем хоста.
Зачем необходима PTR запись
Она полезна для исходящих почтовых серверов. Эта запись повышает надежность отправляющего сервера и позволяет получить обратный ответ для проверки имени хоста через IP-адрес. Это отличный способ защиты от всех видов спамеров, которые используют мошеннические доменные имена для рассылки спама. Вот почему некоторые крупные провайдеры услуг почты, такие как yahoo.com, gmail.com делают обратный поиск в DNS, прежде чем принимать входящие письма.
Перед тем, как вы начнете это руководство, вам понадобится следующее:
- Доступ к консоли вашего компьютера (необязательно)
Способ 1 - Проверка PTR с помощью nslookup или dig
Windows, Unix и схожие операционные системы (Linux, MacOS) имеют встроенные инструменты для проверки DNS записей. Если вы являетесь пользователем Windows, следуйте данным этапам:
- Войдите в меню Пуск Windows, впишите cmd и нажмите ENTER .
- Должно появиться чёрное окно (командная строка windows).
- Впишите следующую команду для получения имени хоста IP адреса (смените IP_ADDESS на нужный вам IP):
- К примеру, если вы хотите проверить PTR запись для 54.243.154.xx, вы увидите похожий результат:
Как видно из результата, PTR запись – ec2-54-243-154-49.hostinger.com .
Для пользователей Linux или Mac процесс схож:
- На MacOS, войдите в терминал с помощью (F4 ). Большинство дистрибутивов Linux позволяют открыть терминал сочетанием клавиш Ctrl+Alt+T .
- Используйте эту команду для проверки PTR записи (смените IP_ADDRESS на нужный вам IP):
- К примеру, вот результат проверки PTR записи для IP адреса 54.243.154.xx:
Из раздела ANSWER SECTION можно узнать значение PTR записи – ec2-54-243-154-49.hostinger.com
Способ 2 - Использование онлайн инструментов
Еще один способ для получения информации об имени хоста IP-адреса, это использовать инструмент для обратного поиска MxToolBox . Все что нужно, это вписать в поле IP адрес и нажать кнопку Reverse Lookup (Обратный поиск) .
Заключение
К сожалению, если поиск показывает, что запись не настроена для IP-адреса, в большинстве случаев вам придется обратиться к вашему хостинг-провайдеру или интернет-провайдеру с просьбой создать ее. Однако теперь вы знаете, что такое PTR запись и как проверить есть ли у нее IP-адрес. Это полезно если вы столкнулись с ошибками DNS и возвратами при попытке отправить электронную почту, поскольку это поможет вам устранить проблему.
Все почтовые серверы, осуществляющие подключения к почтовым серверам должны иметь валидные и осмысленные обратные DNS записи.
Корректно настроенные rDNS адреса нужны, чтобы отправлять сообщения с вашего собственного сервера. Практически все почтовые серверы отвергнут приём сообщения ещё на стадии начала сессии, если у IP-адреса вашего сервера отсутствует запись в обратной зоне DNS. Причина отказа удалённым почтовым сервером может быть такой:
550-"IP address has no PTR (address to name) record in the DNS, or when the PTR record does not have a matching A (name to address) record. Pls check and correct your DNS record." 550-There"s no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye. 550 Your IP has no PTR Record
Число 550 во всех трёх случаях является стандартным кодом почтового SMTP сервера, сообщающего о критической ошибке, которая препятствует дальнейшей работе в рамках данной почтовой сессии. Вообще все ошибки серии 500 являются критическими и продолжение передачи почты после их появления невозможно. Текст же поясняет причину отказа более подробно и сообщает, что администратор почтового сервера-получателя настроил его на проверку наличия у почтового сервера-отправителя записи в обратной зоне DNS (rDNS) и в случае её отсутствия сервер-получатель обязан отказывать отправителю в соединении (SMTP-ошибки серии 5XX).
Настройка rDNS
Правами на настройку обратной зоны DNS (reverse DNS) обладает лишь владелец соответствующего блока IP-адресов, которой эта зона соответствует. Как правило этим владельцем оказывается провайдер, владеющий собственной автономной системой.
Оператору блока IP-адресов для регистрации обратной зоны DNS необходимо зарегистрировать в своём личном кабинете на сайте RIPE объект типа «domain», указать адрес DNS-серверов, которые будут поддерживать зону rDNS и настроить поддержку зоны вида 3.2.1.in-addr.arpa на них. За ресурсы в обратной зоне отвечает указатель (pointer) - запись типа PTR. К ней-то и идут запросы о разрешении IP-адреса и имя хоста (см. ниже описание принципа построения PTR записи).
Если же вы не являетесь обладателем автономной системы, то настройка rDNS для IP-адреса или адресов почтового сервера решается запросом в службу поддержки провайдера или хостера.
В обоих случаях имя IP-адресу почтового сервера, а особенно корпоративного почтового сервера, следует давать осмысленно.
Примеры хороших имён для сервера почты:
Mail.domain.ru mta.domain.ru mx.domain.ru
Примеры плохих имён:
Host-192-168-0-1.domain.ru customer192-168-0-1.domain.ru vpn-dailup-xdsl-clients.domain.ru
Такие имена с высокой вероятностью попадут под фильтр как назначенные клиентским компьютерам, на которых не может быть установлен почтовый сервер, следовательно с них вероятно рассылается спам.
С успехом использовать запросы к обратным зонам DNS можно и нужно сразу после запуска почтового сервера. Для этого необходимо произвести лишь небольшую настройку ПО. В разных почтовых серверах настройка проверки rDNS делается по-разному:
В Postfix необходимо включить опцию
Reject_unknown_client
Verify = reverse_host_lookup
Проверка обратной зоны DNS
: http://remote.12dt.com
Введите свой IP адрес, если отображается ваш домен - настройка правильная
PTR
PTR-запись (от англ. pointer – указатель) связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в обратной форме вернёт имя данного хоста.
В целях уменьшения объёма нежелательной почты серверы-получатели электронной почты проверяют наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
in-addr.arpa - специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитативного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC/24) отвечает отдельный сервер.
Например, если IP вашего почтового сервера 78.56.158.23. То в NS записи сервера или настройки хостера необходимо добавить следующую DNS запись (IP при этом записывается в обратном порядке).
Если у вас есть собственный почтовый сервер или вы намерены создавать почтовую рассылку с собственного домена, вам жизненно важно обезопасить себя от того, чтобы адресаты не сочли ваши письма так называемым спамом.
Дело в том, что многие почтовые службы ради снижения объема нежелательной и вредоносной электронной корреспонденции (то есть этого самого спама) осуществляют проверку PTR-записи у отправителя. И для того, чтобы ваши письма не считались спамом, а ваше доменное имя не вошло в категорию нежелательных отправителей, первым делом вам необходимо настроить PTR-запись для почтового сервера.
Название записи этого типа происходит от латинского слова pointer, что в переводе означает “указатель”. По сути, эта она связывает IP-адрес с вашим доменным именем, то есть PTRзапись в этом очень похожа на A-запись для DNS-сервера. Если первая связывает домен с IP-адресом месторасположения сайта, то вторая – наоборот, связывает IP-адрес с доменом.
Как производится проверка PTR-записи онлайн
Когда письмо из рассылки приходит на почтовый сервер, тот проверяет его прежде, чем определить полученную корреспонденцию в папку “Входящие” или “Спам”. Первый этап – это проверка PTR-записи для IP, откуда пришло письмо. Если запись существует и совпадает с данными домена отправителя, то это может стать одним из решающих факторов одобрения корреспонденции и ее направления в папку “Входящие”.
Если же PTR-запись не совпадает или вообще отсутствует, то велика вероятность попадания письма в “Спам”. Впрочем, при отсутствии этой записи сервер будет проверять корреспонденцию по ряду других критериев, но проверка при этом будет очень строгой.
Как проверить PTR-запись для почтового сервера?
Проверка PTR-записи онлайн предполагает выполнение запроса в домене in-addr.arpa, а в ответ приходит обратная запись PTR. К примеру, если адрес вашего хоста – 111.222.333.444, то транслируется она в обратном порядке и выглядит, как 444.333.222.111.in-addr.arpa.
В целом же существуют несколько способов проверки своей PTR-записи. Давайте же рассмотрим самые простые из них.
Первый вариант – это проверка онлайн при помощи специальных whois-сервисов. Как проверить Ptr-запись для почтового сервера таким образом? Зачастую, достаточно просто ввести IP в проверочную строку. Например, вы можете использовать для этого сервис от RigWEB и в течение нескольких секунд получить всю необходимую информацию, в том числе и искомую запись.
Второй вариант – проверить PTR-запись при помощи командной строки. Для Windows это выполняется следующим образом:
- Нажмите “Пуск” и выберите “Выполнить”.
- Наберите cmd.
- В открывшейся командной строке введите nslookup -type=PTR IP, где IP – ваш IP адрес.
- Посмотрите полученный отчет – в нем вы найдете нужную вам PTR-запись.
Для семейства Unix-систем схема действий немного иная: откройте терминал или консоль и введите команду dig -x IP, где IP – ваш IP-адрес. В результате выполнения команды вам будет показан отчет, где можно увидеть в том числе и PTR-запись.
Кроме того, вы можете запустить проверку PTR записи онлайн.
При проверке было выявлено отсутствие PTR-записи? Тогда ее обязательно нужно прописать.
Как добавить PTR запись для почтового сервера
Если вы не знаете, как прописать PTR-запись для почтового сервера, то вас наверняка успокоит то, что сделать это очень просто. Для этого вам всего лишь нужно связаться с обладателем IP-адреса, к которому привязан ваш сайт. Просто отправьте своему провайдеру просьбу добавить PTR запись, так как она вам нужна для вашего IP-адреса. Для виртуального же хостинга обычно ничего не нужно прописывать, так как эта запись чаще всего уже есть.
Вы арендуете виртуальный выделенный сервер и хотите узнать, как прописать PTR-запись для VDS? В этом случае вам нужно зайти в административную панель, перейти в раздел хостинг-услуг, а там уже выбрать пункт “Изменить обратную DNS-запись”, после чего – подтвердить свой выбор.
Как видите, ничего сложного. Другое дело, что многое в этой ситуации зависит от хостинг-провайдера, а точнее – от скорости реагирования его техподдержки. Поэтому стоит с самого начала очень скрупулезно подходить к выбору хостера. И если вы хотите пользоваться профессиональным хостингом с максимально удобными и выгодными условиями, то вам стоит обратить внимание на услуги, предоставляемые компанией RigWEB.
Воспользовавшись нашим хостингом, вас не будет волновать, как создать PTR-запись, ведь мы заботимся о комфорте наших клиентов и стараемся предоставить максимально качественный сервис. В зависимости от выбранного вами тарифного плана, мы готовы предоставить вам комплекс услуг, в число которых входит и настройка PTR-записи, если вам это необходимо. От обычного переноса сайта на наш виртуальный хостинг до полной настройки VDS-сервера в кратчайшие сроки – мы с радостью поможем вам с решением любых задач.
Кроме того, мы гарантируем вам:
- Стабильную работу и UpTime 99.9%
Благодаря использованию качественного оборудования, размещенного в оснащенном по последнему слову техники дата-центре под круглосуточным контролем опытных специалистов, мы предоставляем максимально возможный в современных условиях UpTime серверов и стабильную работу ваших сайтов.
- Оперативную и квалифицированную техподдержку
Любые вопросы, связанные с работой нашего хостинга, вы можете задавать нашим специалистам. Техподдержка RigWEB работает в режиме 24/7/365 и отвечает в течение 30 минут с момента отправки тикета, поэтому вы можете быть уверены в оперативном решении вашей проблемы. Так что если вы не знаете, как сделать PTR-запись, пользуясь нашим хостингом – можете смело задавать этот вопрос нашим специалистам.
- Справедливые тарифы и прозрачное ценообразование
Никаких скрытых платежей! Вы всегда будете знать, за что платите деньги, и взамен получите 100% оплаченных вами ресурсов наших серверов.
Пользуйтесь профессиональным хостингом от RigWEB и получайте удовольствие от работы над своими проектами, ведь вы всегда можете рассчитывать на максимально комфортные и выгодные условия сотрудничества с нами!
