PTR-запись и Reverse DNS: как связать IP с именем отправляющего сервера
PTR-запись — DNS-запись, которая связывает IP-адрес с доменным именем. По ней выполняется обратный DNS-запрос, или Reverse DNS: система получает имя сервера по его IP. Почтовые провайдеры проверяют PTR отправляющего сервера при приёме писем, поэтому некорректная запись может привести к ограничениям доставки.
Как работает Reverse DNS
Обычный DNS-запрос преобразует доменное имя в IP-адрес. Например, A-запись сообщает, что сервер mta-1.example.com доступен по IPv4-адресу 192.0.2.4.
Обратный запрос начинается с IP-адреса и возвращает доменное имя. Для этого используется PTR-запись — Pointer Record. Тип записи и его назначение определены в стандарте RFC 1035.
| Направление запроса | Исходные данные | Результат | Тип записи |
|---|---|---|---|
| Прямой DNS | mta-1.example.com | 192.0.2.4 | A |
| Обратный DNS | 192.0.2.4 | mta-1.example.com | PTR |
Для IPv4 обратные записи размещают в специальной зоне in-addr.arpa. Части адреса записывают в обратном порядке, поэтому запрос для 192.0.2.4 выглядит так:
4.2.0.192.in-addr.arpa. PTR mta-1.example.com.
Для IPv6 используется зона ip6.arpa, а адрес разбивается на отдельные шестнадцатеричные символы и также разворачивается.
Обратный порядок связан с устройством DNS: организация, которая управляет диапазоном IP-адресов, управляет и соответствующей обратной зоной и при необходимости может передать часть этой зоны владельцу или арендатору адресов. Для настройки достаточно помнить, что в in-addr.arpa части IPv4-адреса записываются справа налево.
mta-1.example.com ── A ──> 192.0.2.4
192.0.2.4 ── PTR ──> mta-1.example.com
A-запись связывает домен с IP-адресом, а PTR-запись выполняет обратное сопоставление
Зачем PTR-запись нужна отправителю писем
Когда почтовый сервер принимает соединение, он видит IP-адрес отправляющего сервера. По PTR-записи получатель проверяет, какое имя связано с этим адресом. Затем может выполняться прямой запрос: полученное имя должно через A- или AAAA-запись возвращаться к исходному IP.
Такая согласованная конфигурация называется Forward-confirmed Reverse DNS, или FCrDNS:
192.0.2.4 → mta-1.example.com → 192.0.2.4
Google требует действительные прямые и обратные DNS-записи для IP-адресов, с которых отправляются письма на личные аккаунты Gmail. Если PTR отсутствует или полученное имя не указывает обратно на исходный IP, Gmail может временно ограничить скорость приёма с ошибкой 4.7.23 либо заблокировать сообщение с ошибкой 5.7.25.
PTR выполняет несколько практических задач:
- идентифицирует отправляющий сервер понятным доменным именем;
- служит одним из сигналов при оценке почтовой инфраструктуры и репутации IP;
- снижает риск технических отказов со стороны принимающих серверов;
- упрощает диагностику: по имени можно определить сервер или поток, которому принадлежит IP.
PTR не заменяет SPF, DKIM и DMARC. Обратный DNS связывает IP с именем сервера, но не подтверждает право отправлять письма от адреса в поле From и не проверяет целостность сообщения. Даже корректная PTR-запись не гарантирует попадание во «Входящие».
Как должна выглядеть корректная PTR-запись
Для отправляющего IPv4-адреса 192.0.2.4 можно использовать имя mta-1.example.com.
В прямой зоне домена создаётся A-запись:
mta-1.example.com. A 192.0.2.4
В обратной зоне IP создаётся PTR-запись:
4.2.0.192.in-addr.arpa. PTR mta-1.example.com.
Корректная конфигурация соответствует нескольким правилам:
- PTR существует для каждого отправляющего IP. Если письма уходят с нескольких адресов, обратная запись нужна для каждого из них.
- Имя из PTR разрешается обратно в исходный IP. RFC 1912 рекомендует согласовывать PTR- и A-записи. Это требование также входит в рекомендации Google для отправителей.
- PTR содержит полное доменное имя сервера. Например, для отправляющего сервера можно использовать имя
mta-1.example.com. - Целевое имя ведёт непосредственно на A- или AAAA-запись. RFC 1912 рекомендует не направлять PTR на псевдоним CNAME.
- Запись относится к фактическому IP отправки. Проверять нужно адрес, с которого почтовый сервер устанавливает SMTP-соединение, а не IP сайта или корпоративного почтового ящика.
Для одного IP технически возможно опубликовать несколько PTR-записей, но для почтовой инфраструктуры обычно используют одно основное имя. Разные получатели могут обрабатывать набор значений неодинаково.
Кто настраивает Reverse DNS
PTR нельзя добавить как обычную запись в прямой DNS-зоне домена. Обратной зоной управляет владелец IP-диапазона или организация, которой он её делегировал: хостинг-провайдер, оператор связи, облачная платформа либо сам владелец инфраструктуры.
Порядок настройки обычно такой:
- Выбрать доменное имя отправляющего сервера.
- Создать для него A- или AAAA-запись, которая указывает на IP отправки.
- Передать это имя владельцу IP или указать его в разделе Reverse DNS панели провайдера.
- Проверить PTR и прямое разрешение имени после обновления DNS.
Если используется сервис рассылок с общей инфраструктурой, Reverse DNS настраивает владелец отправляющих IP. Клиенту не нужно создавать PTR для IP, которыми он не управляет.
Распространённая ошибка — добавить запись типа PTR в обычную DNS-зону example.com. Такая запись не меняет Reverse DNS публичного IP, поскольку запрос выполняется к зоне in-addr.arpa или ip6.arpa.
Как проверить PTR-запись
В Linux и macOS обратный запрос можно выполнить командой:
dig -x 192.0.2.4
В успешном ответе будет строка вида:
4.2.0.192.in-addr.arpa. 300 IN PTR mta-1.example.com.
Затем нужно проверить прямое разрешение полученного имени:
dig mta-1.example.com A
Ожидаемый результат:
mta-1.example.com. 300 IN A 192.0.2.4
В Windows можно использовать nslookup:
nslookup 192.0.2.4
nslookup mta-1.example.com
Если первый запрос возвращает NXDOMAIN или пустой ответ, PTR отсутствует. Если PTR возвращает имя, но это имя не разрешается в исходный IP, прямой и обратный DNS не согласованы. Примеры проверки через dig также смотрите в документации Altcraft по настройке from-домена.
PTR-запись при работе с Altcraft
В облачной версии Altcraft отправляющая инфраструктура находится на стороне платформы и предоставляется со всеми необходимыми настройками. Поэтому PTR для отправляющих IP настраивает Altcraft — пользователю не нужно создавать эту запись в DNS-зоне своего from-домена. Со своей стороны клиент настраивает записи домена отправки: SPF, DKIM, DMARC и CNAME трекинга.
При установке Altcraft Platform на собственную инфраструктуру отправляющие IP относятся к инфраструктуре клиента. PTR нужен для каждого IP, с которого транспортный модуль AKMTA устанавливает соединения с почтовыми провайдерами. Обратную запись настраивает владелец IP, хостинг-провайдер или администратор делегированной обратной зоны. Рекомендации Altcraft по взаимодействию с ISP отдельно описывают настройку обратной зоны и её связь с сендер-доменом.
В настройках AKMTA-сендера задаются отправляющие IP и параметры домена отправителя
После настройки стоит отправить тестовые письма разным провайдерам и проверить ошибки доставки. В отчёте о недоставках можно просматривать возвраты и ответы почтовых серверов.
Хотите изучить настройку email-канала и работу с рассылками на практике? Зарегистрируйтесь в Altcraft и познакомьтесь с возможностями платформы.
Заключение
PTR-запись связывает IP-адрес с именем сервера и используется при обратном DNS-запросе. Для почтовой инфраструктуры важно, чтобы имя из PTR через A- или AAAA-запись разрешалось в исходный адрес.
Обратную зону настраивает владелец IP-диапазона или организация, которой она делегирована, а не регистратор основного домена. Перед массовой отправкой нужно проверить PTR для каждого отправляющего адреса, сопоставить результат с прямой DNS-записью и отдельно настроить SPF, DKIM и DMARC.
Читайте по теме
