Если у вас есть собственный почтовый сервер или вы намерены создавать почтовую рассылку с собственного домена, вам жизненно важно обезопасить себя от того, чтобы адресаты не сочли ваши письма так называемым спамом.
Дело в том, что многие почтовые службы ради снижения объема нежелательной и вредоносной электронной корреспонденции (то есть этого самого спама) осуществляют проверку 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 и получайте удовольствие от работы над своими проектами, ведь вы всегда можете рассчитывать на максимально комфортные и выгодные условия сотрудничества с нами!
В наших прошлых материалах мы уже рассматривали настройку 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 зону, в которой должны присутствовать A, MX и PTR-записи. Если с первыми двумя всё более-менее понятно, то настройка PTR-записи (обратной зоны, когда необходимо проверить имя сервера зная его IP-адрес) не редко вызывает сложности в понимании, где она должна быть прописана и кто за неё отвечает. Без PTR-записи часть почтовых серверов откажется принимать почту с вашего сервера, отправив вам в ответ примерно такую ругань:
550-There is no reverse (PTR) record found for your host or A record does not 550 correspond PTR record (in reply to RCPT TO command) 550-Reverse DNS lookup failed. If you think this is wrong, get in touch with 550 postmaster. (in reply to RCPT TO command) 550 5.7.1 Relaying denied. IP name forged (PTR and A records mismatch) for ###.###.###.### (in reply to MAIL FROM command)
Так в чем, собственно, заключается сложность? Во-первых - недопонимание как устроена и работает DNS, а во-вторых - банальное нежелание некоторых провайдеров выполнять свои прямые обязанности или некомпетентности "технических специалистов", типа сами дураки. К сожалению встречается и такое. Но давайте, попробуем разобраться.
Рассмотрим распространенную ситуацию. По каким-то причинам вам перестало хватать возможностей почтового сервера, предоставляемого хостингом, там где находится ваш сайт (или просто вы зарегистрировали домен и хотите настроить свой почтовый сервер). У своего провайдера вы получили статический ip-адрес (или даже небольшую подсеть) и на хостинге прописали А и MX записи с указанием на ваш почтовик (тот самый, выделенный вам провайдером ip-адрес).
А вот дальше бывают непонятки кто же должен разместить у себя PTR-запись о вашем почтовом сервере - хостер (тот в чьём ведении находятся DNS-сервера, ответственные за ваш домен) или провайдер (тот, кто выдал вам статический ip-адрес). Для определения имени узла по его ip-адресу предусмотрена особая доменная зона in-addr.arpa .
Так вот, кто выдал вам статический ip-адрес, тот и прописывает на своем DNS-сервере PTR-записи для вашего почтового сервера в зоне in-addr.arpa. Для этого необходимо послать запрос тому, кто выдал вам статический ip-адрес с просьбой зарегистрировать PTR запись для вашего домена.
Примечание: если адреса домена и почтового сервера не совпадают, то PTR-запись должна создаваться именно для MX-записи.
DNS-запись in-addr.arpa для почтового сервера mail.mydomain.ru с адресом 123.45.67.89 выглядит так:
123.45.67.89.in-addr.arpa. IN PTR mail.mydomain.ru.
Проверить наличие PTR записи на сервере DNS можно с помощью команды nslookup или аналогичного онлайн-сервиса (к примеру http://www.nslookup.su). В командной строке вызываем nslookup и пишем:
> set type=PTR <-- установили тип ресурсной записи > 93.158.134.89 <-- интересующий ip-адрес ----- полученный ответ ----- Не заслуживающий доверия ответ: 89.134.158.93.in-addr.arpa name = mx.yandex.ru 134.158.93.in-addr.arpa nameserver = ns1.yandex.net 134.158.93.in-addr.arpa nameserver = ns2.yandex.net ns1.yandex.net internet address = 213.180.193.1 ns2.yandex.net internet address = 93.158.134.1 >
В поле `name` видим имя одного из почтовых серверов яндекса. При правильной настройке обратной зоны, данное поле должно отобразить имя вашего почтового сервера по соответствующему ip-адресу.
Существует много типов 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 при этом записывается в обратном порядке).
