Обратный DNS (PTR)

Проверка PTR-записи онлайн: что показывает обратный DNS-запрос

Обратный DNS (rDNS) отвечает на вопрос «какое имя закреплено за этим IP». Ответ хранится в PTR-записи. Для проверки PTR введите IPv4-адрес — или домен: тогда инструмент сначала найдёт его IPv4 по A-записи и проверит уже этот адрес. Так удобно проверить PTR-запись для домена почтового сервера: вводите mail.example.com и сразу видите, что отвечает обратная зона по его IP.

В результате три вещи:

• Hostname (PTR) — имя, которое вернул обратный запрос, или «Не найден», если PTR нет.
• Forward DNS совпадает / не совпадает — инструмент берёт полученное имя, разрешает его в IPv4 и сравнивает с исходным IP. Совпадение — это и есть FCrDNS, о котором ниже.
• Таблица PTR-записей — имя в зоне in-addr.arpa, значение и TTL. TTL подсказывает, сколько ждать, пока исправленная запись разойдётся по кэшам.

Если PTR есть, но прямой DNS не совпадает, чаще всего у имени из PTR нет A-записи или она указывает на другой IP. Если у имени несколько A-записей, сравнивается первая из них, поэтому при балансировке перепроверьте вручную.

Типичные результаты проверки rDNS и что с ними делать

Если инструмент сообщает «Некорректный IP-адрес», а вы вводили домен — у домена нет A-записи, и проверять пока нечего.

Как устроена обратная зона: где «живёт» PTR

PTR-запись хранится не в зоне вашего домена, а в зоне in-addr.arpa, где октеты IP записаны в обратном порядке. Для адреса 203.0.113.25 имя записи — 25.113.0.203.in-addr.arpa. Этим объясняется частая путаница с «PTR generator»: сгенерировать имя записи легко, но создать её в своей DNS-панели нельзя — обратная зона делегирована владельцу блока IP-адресов, то есть хостеру или провайдеру.

Если вы сами владеете подсетью (например, /24 от RIR) и вам делегировали обратную зону, запись в BIND выглядит так:

$ORIGIN 113.0.203.in-addr.arpa.
25    IN  PTR  mail.example.com.

Точка в конце имени обязательна — без неё сервер допишет к имени происхождение зоны. Для IPv6 используется зона ip6.arpa, где адрес разворачивается по полубайтам (32 шестнадцатеричные цифры через точку); наш инструмент проверяет IPv4.

Обратный DNS-запрос из командной строки

Проверить PTR можно и вручную — полезно, когда нужно спросить конкретный DNS-сервер, а не кэш:

dig -x 203.0.113.25 +short
dig -x 203.0.113.25 @1.1.1.1
host 203.0.113.25
nslookup 203.0.113.25

dig -x сам строит имя в in-addr.arpa. Прямую проверку делают второй командой: dig +short A mail.example.com должен вернуть тот же IP. В Windows хватит nslookup — он выводит строку Name с результатом обратного запроса.

Зачем PTR почтовому серверу

Для сайта PTR почти ничего не значит: браузеры и поисковые системы его не проверяют. Для почты — наоборот. Принимающий сервер видит только IP подключившегося отправителя и первым делом делает обратный DNS-запрос.

• Нет PTR — Gmail в требованиях к отправителям прямо указывает, что у отправляющего IP должна быть PTR-запись, а её отсутствие ведёт к отказам или папке «Спам». Многие серверы на Postfix отклоняют такие подключения правилом reject_unknown_reverse_client_hostname.
• PTR не совпадает с прямым DNS — правило reject_unknown_client_hostname в Postfix требует именно FCrDNS. Для массовых рассылок Gmail тоже требует согласованных прямой и обратной записей.
• Шаблонный PTR вида 203-0-113-25.dynamic.provider.net — антиспам-фильтры считают такие имена признаком домашних и динамических адресов и снижают оценку.

Отдельная история — HELO/EHLO. Имя, которым сервер представляется при подключении, стоит сделать тем же, что в PTR. В Postfix это myhostname = mail.example.com в main.cf, в Exim — primary_hostname.

Как выглядит отказ из-за PTR

Проблему с обратной зоной обычно выдаёт текст возврата (bounce). У Gmail это код 550-5.7.25 с пояснением, что у IP отправителя нет PTR-записи. Postfix получателя отвечает 450 4.7.1 Client host rejected: cannot find your reverse hostname. Код 450 временный: ваш сервер будет повторять отправку, и письма копятся в очереди. Увидели такое — проверьте IP отправляющего сервера здесь.

FCrDNS: прямая и обратная записи должны сходиться

Forward-confirmed reverse DNS — это проверка по кругу:

1. IP 203.0.113.25 → PTR → mail.example.com;
2. mail.example.com → A → 203.0.113.25;
3. IP совпал — запись подтверждена.

Подделать PTR владелец IP может как угодно, а вот A-запись в чужом домене — нет. Поэтому только пара «PTR + совпадающая A-запись» доказывает, что IP действительно связан с доменом. Именно эту проверку отражает бейдж «Forward DNS совпадает» в отчёте.

Как настроить PTR у хостера

PTR меняют там, кому принадлежит IP, — в панели хостера или через поддержку провайдера:

Порядок всегда один: сначала создайте A-запись mail.example.com → IP в своей DNS-зоне, потом задайте PTR у хостера, потом проверьте оба направления. Многие панели не дают сохранить PTR, пока прямая запись не указывает на этот IP.

Если почта уходит через Google Workspace, Microsoft 365 или сервис рассылок, PTR их серверов настраивать не нужно — это делают они. Ваша задача — SPF, DKIM и DMARC. PTR нужен, когда письма отправляет ваш собственный сервер: VPS с Postfix, сайт на выделенном сервере, 1С или CRM, которые шлют почту напрямую.

Что проверить после PTR

Если PTR и прямой DNS в порядке, а письма всё равно отклоняются, проверьте, не попал ли адрес в спам-листы, через проверку IP в чёрных списках, и разрешён ли он в SPF домена — это покажет проверка SPF. A-, MX- и TXT-записи домена удобно смотреть в DNS lookup, а разбор типов записей и TTL есть в статье «Проверка DNS-записей».