В обычной DNS все выглядит довольно понятно. Есть доменное имя, например example.ru, и его нужно связать с IP-адресом сервера. Для IPv4 создается A-запись, после чего DNS может сообщить, на какой адрес направлять запросы к этому имени.
Но иногда требуется сделать обратное: взять уже известный IP-адрес и определить связанное с ним доменное имя. Для этого используется PTR-запись.
Чаще всего владелец сайта сталкивается с ней при настройке собственного почтового сервера на VPS или выделенной машине. И здесь начинается путаница. Пользователь открывает привычный редактор DNS своего домена, видит A, AAAA, MX, TXT и CNAME, но не понимает, куда добавить PTR. Иногда такого пункта в панели вообще нет.
Это нормально. Обратная DNS устроена иначе, и управляет ей обычно не владелец домена, а тот, кому принадлежит или кем управляется соответствующий диапазон IP-адресов.
Как работает PTR запись
Сначала разберемся с направлением поиска.
Предположим, у нас есть сервер с IP-адресом 192.0.2.25 и именем mail.example.ru.
Обычная A-запись позволяет получить IP по имени:
mail.example.ru → 192.0.2.25
PTR позволяет выполнить обратный поиск:
192.0.2.25 → mail.example.ru
Поэтому PTR часто называют обратной DNS-записью, а сам механизм — reverse DNS или сокращенно rDNS.
На первый взгляд может показаться, что это просто A-запись наоборот. Для понимания принципа такое сравнение подходит, но технически записи находятся в разных DNS-зонах и управляться могут совершенно разными организациями.
Почему IP в обратной DNS записывается наоборот
Для обратного поиска IPv4 используется специальное пространство in-addr.arpa.
Октеты IPv4-адреса в таком имени располагаются в обратном порядке. Например, для адреса 192.0.2.25 обратный DNS-запрос будет относиться к имени:
25.2.0.192.in-addr.arpa
В этой зоне PTR может указывать на доменное имя сервера.
Пользователю обычно не приходится вручную работать с такой записью. Панель VPS может предложить обычное поле для настройки reverse DNS, куда достаточно ввести hostname. Все остальное выполняет инфраструктура провайдера.
PTR и A запись должны согласовываться
Для почтового сервера особенно полезна согласованная схема.
Допустим, PTR для 192.0.2.25 возвращает:
mail.example.ru
Тогда прямой DNS-запрос к mail.example.ru должен вести обратно на тот же IP:
mail.example.ru → 192.0.2.25
Получается замкнутая и понятная цепочка:
192.0.2.25 → mail.example.ru → 192.0.2.25
Для отправляющего почтового сервера такая согласованность особенно важна. Крупные почтовые системы проверяют прямую и обратную DNS при оценке инфраструктуры отправителя.
Почему PTR нельзя просто добавить рядом с A и MX
Это, пожалуй, главный практический вопрос.
Вы зарегистрировали example.ru и можете управлять его DNS-зоной. Значит можно самостоятельно создать A, MX или TXT. Почему нельзя таким же способом назначить PTR своему серверу?
Потому что обычная DNS-зона example.ru находится под вашим контролем, а обратная зона IP-адреса связана с адресным пространством.
Если IP предоставил хостинг-провайдер, именно он или вышестоящий владелец соответствующего адресного диапазона контролирует обратную DNS для этого адреса.
Вы не можете самостоятельно объявить, что случайный чужой IP принадлежит mail.example.ru, просто добавив запись в DNS своего домена.
Где настраивать PTR для VPS
Удобнее всего, когда хостер позволяет управлять обратной DNS прямо в панели.
Вы выбираете IP своего VPS, находите настройку PTR, Reverse DNS или rDNS и указываете нужное полное доменное имя, например mail.example.ru.
Если такой настройки нет, стоит посмотреть документацию провайдера или обратиться в техническую поддержку. Некоторые компании меняют PTR по запросу клиента.
Перед этим имеет смысл создать обычную A-запись для выбранного имени и направить ее на IP сервера.
Получается понятный порядок:
- выбираем hostname сервера, например mail.example.ru;
- создаем A-запись mail.example.ru на IP VPS;
- настраиваем PTR этого IP на mail.example.ru через провайдера;
- проверяем прямой и обратный DNS.
Конкретный интерфейс зависит от хостинга. Где-то reverse DNS меняется самостоятельно за несколько секунд, где-то настройка находится в разделе IP-адресов, а где-то потребуется обращение в поддержку.
Что делать с виртуальным хостингом
Владельцу обычного сайта на виртуальном хостинге PTR чаще всего вообще не нужно настраивать.
На одном IP могут находиться десятки или сотни сайтов, а сетевой инфраструктурой управляет хостер. Пользователь не получает контроль над обратной DNS общего IP только потому, что разместил на нем свой домен.
Если почтовые ящики работают через инфраструктуру самого хостинга, настройкой почтовых серверов и их IP занимается провайдер.
То же относится к специализированному почтовому сервису. Вы настраиваете предоставленные им MX, SPF, DKIM и другие необходимые записи своего домена, а обратной DNS серверов отправки занимается сам поставщик услуги.
PTR становится вашей практической задачей прежде всего тогда, когда вы самостоятельно управляете сервером и отправляете с его IP почту напрямую.
Зачем PTR нужна почтовому серверу
Электронная почта является главной причиной, по которой обычный владелец VPS вообще узнает о существовании PTR.
Когда ваш SMTP-сервер устанавливает соединение с сервером получателя, принимающая сторона видит IP отправителя. Этот адрес можно проверить через обратную DNS.
Отсутствующая или некорректная PTR является плохим техническим сигналом для почтовой инфраструктуры.
Например, Gmail требует от отправителей наличия корректных прямых и обратных DNS-записей. Для публичного IP отправляющего SMTP-сервера PTR должна возвращать hostname, а этот hostname через A или AAAA должен разрешаться в тот же публичный IP.
Это уже не просто рекомендация из старых руководств системных администраторов. Некорректная конфигурация может стать одной из причин ограничения или отклонения отправляемых сообщений.
PTR не является защитой от спама
Здесь важно не сделать обратный ошибочный вывод.
Если настроить идеальную PTR, письма не начнут автоматически попадать во входящие.
Обратная DNS подтверждает определенную техническую согласованность инфраструктуры. Она не доказывает, что сообщение полезное, что получатель хотел его получить или что отправитель обладает хорошей репутацией.
Для нормальной доставки современной почты важен целый набор факторов.
Используются SPF и DKIM, для соответствующих сценариев DMARC, защищенное соединение TLS, корректное оформление сообщений, репутация IP и домена. Почтовые системы учитывают жалобы пользователей и характер отправки.
Поэтому схема:
настроил PTR → больше никогда не попаду в спам
не работает.
Можно иметь корректную обратную DNS и испортить репутацию массовой нежелательной рассылкой. Можно получить VPS с IP, который уже использовался недобросовестным отправителем. Можно забыть про SPF и DKIM.
PTR является важной частью конфигурации собственного почтового сервера, но не заменяет остальные механизмы.
PTR не заменяет SPF, DKIM и DMARC
Эти технологии решают разные задачи.
PTR связывает IP-адрес с доменным именем в обратной DNS.
SPF позволяет публиковать информацию об источниках, которым разрешено отправлять почту от имени домена.
DKIM добавляет к сообщениям криптографическую подпись, которую получатель может проверить с помощью опубликованного в DNS ключа.
DMARC позволяет связать проверки с доменом в поле From и задать политику обработки сообщений, не соответствующих требованиям.
Поэтому вопрос что лучше, PTR или DKIM не имеет особого смысла. Это не конкурирующие способы настройки почты.
Почему новый VPS все равно может плохо отправлять почту
Представим, что вы арендовали VPS, установили почтовый сервер, настроили PTR, A, SPF и DKIM. Технически все выглядит аккуратно, но часть сообщений продолжает попадать в спам.
Причина может находиться не в PTR.
IP-адреса VPS используются повторно. После отказа одного клиента адрес со временем может получить другой. Если предыдущий пользователь активно рассылал спам, у IP могла сформироваться плохая репутация.
Именно поэтому при самостоятельном размещении почты полезно проверять не только DNS, но и репутацию полученного адреса.
Важна и история нового отправителя. Резкое появление большого объема сообщений с нового домена и нового IP может восприниматься иначе, чем стабильная обычная переписка.
Для небольшого бизнеса это одна из причин хорошо подумать, нужен ли вообще собственный почтовый сервер. Готовый корпоративный почтовый сервис снимает значительную часть инфраструктурных задач.
Как правильно настроить и проверить PTR
Начать лучше с имени сервера.
Для почтовой машины можно использовать отдельный hostname вроде mail.example.ru. Это обычное доменное имя, поэтому сначала оно настраивается в прямой DNS-зоне.
Создаем A-запись:
mail.example.ru → 192.0.2.25
Если сервер отправляет почту через IPv6, необходимо учитывать и соответствующую IPv6-конфигурацию.
После этого в панели хостера или через поддержку задаем reverse DNS для IP:
192.0.2.25 → mail.example.ru
Когда изменения применились, проверяем оба направления.
Как проверить обратную DNS
Для простой проверки можно использовать команду nslookup.
Например:
nslookup 192.0.2.25
Если PTR настроена, в результате должно появиться связанное с адресом имя.
В системах, где доступен dig, можно выполнить обратный запрос:
dig -x 192.0.2.25
После этого обязательно проверяем прямое направление:
nslookup mail.example.ru
или:
dig mail.example.ru A
Нужно убедиться, что имя, возвращаемое PTR, действительно ведет обратно на IP отправляющего сервера.
Существуют и веб-сервисы для DNS lookup, поэтому устанавливать дополнительные программы только ради одной проверки необязательно.
Почему изменение может быть видно не сразу
Как и другие данные DNS, результаты обратного поиска могут кешироваться.
Если PTR только что изменили, отдельные резолверы некоторое время способны возвращать старое значение. Поэтому отсутствие мгновенного результата еще не доказывает ошибку.
При этом бесконечно ждать обновления тоже не стоит. Если после разумного времени авторитетная обратная DNS продолжает возвращать неправильное имя, нужно проверять настройку у владельца IP.
Особенно внимательно это стоит делать перед запуском собственного SMTP-сервера. Лучше сначала привести DNS в порядок, проверить конфигурацию и только потом начинать реальную отправку.
Что делать, если PTR изменить нельзя
Иногда провайдер не дает клиенту возможности установить собственную обратную DNS для выданного IP.
Если VPS нужен только для сайта, это может вообще не иметь значения.
Если сервер планируется использовать для прямой отправки почты, ситуация уже важнее. Спросите поддержку, может ли она изменить PTR вручную.
Если такой возможности нет, стоит рассмотреть другой способ отправки почты. Например, сайт и приложения могут работать на текущем VPS, а исходящие сообщения отправляться через внешний SMTP-сервис.
Переносить весь сайт к другому хостеру только из-за почты в таком случае необязательно.
Когда владельцу сайта вообще нужно думать о PTR
Для большинства обычных сайтов ответ простой: почти никогда.
Если вы купили виртуальный хостинг, создали сайт и используете почтовые ящики хостера или отдельный корпоративный почтовый сервис, инфраструктурой отправки управляет поставщик.
Не нужно искать PTR в панели домена и создавать ее на всякий случай.
Не нужна она и для того, чтобы обычный сайт начал открываться по доменному имени. За это отвечают прямые DNS-записи, например A и AAAA.
О PTR стоит вспомнить в нескольких ситуациях:
- вы самостоятельно поднимаете почтовый сервер на VPS;
- сервер отправляет почту напрямую со своего публичного IP;
- почтовый сервис сообщает об ошибке reverse DNS;
- письма отклоняются с указанием на отсутствие PTR или несоответствие прямой и обратной DNS;
- вы настраиваете серверную инфраструктуру, для которой корректное обратное разрешение имен имеет практическое значение.
PTR относится к IP, а не к сайту как таковому
Это главное, что стоит запомнить.
A-запись отвечает на вопрос, какой IP связан с определенным именем. Управлять ею обычно можно там, где обслуживается DNS-зона домена.
PTR отвечает на обратный вопрос, какое имя связано с IP. Поэтому контроль находится на стороне адресного пространства.
Именно из-за этого инструкция добавьте PTR в DNS домена часто только запутывает новичка.
Если IP выдан хостинг-провайдером, искать настройку нужно прежде всего у него.
Для собственного почтового сервера одной записи недостаточно
Правильная PTR является хорошим началом, но на ней настройка почты не заканчивается.
Нужно проверить прямую DNS для hostname, настроить почтовую аутентификацию, TLS и сам SMTP-сервер. Следует учитывать репутацию IP, правила крупных получателей и характер отправляемой почты.
Поэтому самостоятельный почтовый сервер на VPS стоит выбирать не ради экономии на одном ящике. Он дает контроль, но одновременно делает владельца ответственным за всю инфраструктуру отправки.
Для обычной корпоративной почты готовый сервис часто оказывается проще.
А если собственный сервер действительно нужен, PTR лучше настроить еще до начала отправки. Создайте понятный hostname, направьте его A или AAAA-запись на сервер, задайте обратную DNS у владельца IP и проверьте соответствие в обе стороны.
Тогда сервер не будет выглядеть для принимающей почтовой системы как безымянный IP, а PTR займет свое правильное место среди остальных настроек DNS и почтовой инфраструктуры.
