Обратный DNS (rDNS, Reverse DNS) — механизм, который позволяет по IP-адресу узнать связанное доменное имя. Это противоположность обычного DNS (имя → IP). PTR-запись — основной тип записи в обратном DNS.
Зачем нужен rDNS
- Почтовые серверы — большинство MTA (Postfix, Exim) проверяют PTR. Без PTR письма отклоняются или падают в спам
- Сетевая диагностика — traceroute показывает имена хостов вместо IP
- Логи сервера — вместо IP отображается понятное имя
- Доверие провайдеров — некоторые сервисы блокируют IP без PTR
Разница между A и PTR
| Запись | Направление | Пример |
|---|---|---|
| A-запись | Имя → IP | mail.example.com → 192.168.1.1 |
| PTR-запись | IP → Имя | 192.168.1.1 → mail.example.com |
Настройка PTR на VPS ZevsHost
- Войдите в Личный кабинет → VPS → выберите сервер
- Раздел «Сеть» → «Обратный DNS»
- Введите полное доменное имя (FQDN):
mail.example.com - Сохраните — PTR обновится в течение нескольких минут
Проверка PTR-записи
# Прямая проверка PTR
nslookup 192.168.1.1
# Через dig
dig -x 192.168.1.1
# Ожидаемый ответ:
# 1.1.168.192.in-addr.arpa. 3600 IN PTR mail.example.com.PTR для почтовых серверов — чеклист
- PTR настроен для IP почтового сервера
- PTR совпадает с HELO-именем Postfix/Exim
- A-запись для имени из PTR существует и указывает на тот же IP (forward-confirmed rDNS)
- SPF и DKIM настроены дополнительно
Частые ошибки PTR
| Сообщение или симптом | Причина | Решение |
|---|---|---|
| 550 5.7.1 Client host rejected: cannot find your reverse hostname | Для IP отправляющего сервера вообще не настроена PTR-запись | Настроить PTR через панель VPS или запросить у провайдера, если IP не в вашем прямом управлении |
| 450 4.7.1 Client host rejected: Reverse DNS mismatch | PTR настроен, но резолвится в имя, у которого нет A-записи, указывающей обратно на этот же IP (нет FCrDNS) | Добавить A-запись для имени из PTR, указывающую точно на IP почтового сервера |
| PTR показывает имя хостинг-провайдера вместо вашего домена | IP получен в аренду у провайдера, а PTR по умолчанию указывает на генерическое имя вида vps123.provider.net | Изменить PTR на нужное значение через панель управления VPS/dedicated-сервером |
| dig -x возвращает NXDOMAIN сразу после настройки | Изменение PTR ещё не распространилось — обратные зоны (in-addr.arpa) обновляются на стороне провайдера, а не мгновенно | Подождать 15–60 минут и повторить проверку, распространение PTR обычно быстрее, чем у обычных записей |
PTR для IPv6
Для IPv6 обратная зона называется ip6.arpa, а не in-addr.arpa, и запись состоит из полного адреса, развёрнутого по полубайтам в обратном порядке.
# Проверка PTR для IPv6-адреса
dig -x 2001:db8::1
# Ожидаемый ответ (частично):
# 1.0.0...8.b.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR mail.example.com.Если почтовый сервер отправляет письма и по IPv4, и по IPv6 — PTR нужно настроить для обоих адресов отдельно. Наличие корректного PTR только для IPv4 не спасает от отказов, если тот же сервер способен отправлять почту по IPv6-соединению.
Когда PTR не поможет
- IP находится в публичных блоках, ранее замеченных в рассылке спама — репутация IP важнее наличия PTR, и часть фильтров всё равно отклонит почту
- SPF-запись домена не включает IP отправляющего сервера — PTR не заменяет SPF, оба механизма проверяются независимо
- DKIM не настроен вовсе — крупные почтовые провайдеры (Gmail, Outlook) в 2024–2025 годах требуют DKIM для массовой рассылки независимо от PTR
- PTR настроен, но HELO-имя сервера не совпадает с ним — часть строгих MTA проверяет именно это совпадение, а не факт наличия PTR как такового
PTR — лишь часть репутации отправителя. Полный набор записей для почты собран в статье настройка MX и SPF для домена.
TTL PTR-записи и его практическое значение
PTR-запись, как и любая DNS-запись, имеет TTL — обычно провайдеры выставляют его в диапазоне 3600–86400 секунд. Для почтовых серверов это означает, что после изменения PTR часть принимающих серверов будет видеть старое значение вплоть до истечения TTL, даже если сама запись в зоне уже обновлена. Это отличается от смены A-записи сайта: ошибка в PTR не просто ломает визуальное отображение, а может привести к массовому отклонению писем на протяжении всего периода устаревшего кеша.
Перед миграцией почтового сервера на новый IP имеет смысл заранее снизить TTL PTR-записи до 300–600 секунд, если это позволяет провайдер, чтобы сократить окно, в течение которого письма могут отклоняться из-за рассинхронизации.
Частые вопросы
Если почтовый сервер отправляет и по IPv4, и по IPv6, нужно ли настраивать PTR отдельно для каждого адреса?
Да, PTR привязан к конкретному IP-адресу, а не к серверу в целом, поэтому запись для IPv4 никак не распространяется на IPv6. Если сервер способен отправлять почту по обоим протоколам, а обратная запись настроена только для IPv4, часть писем всё равно будет отклоняться принимающими серверами при попытке доставки через IPv6-соединение.
Сколько времени занимает фактическое вступление в силу изменённой PTR-записи?
Формально запись в обратной зоне обычно обновляется на стороне провайдера довольно быстро, но принимающие почтовые серверы какое-то время продолжают видеть старое значение, пока не истечёт TTL у закэшированного ответа. Поэтому сразу после смены PTR часть писем может ещё проверяться по прежнему значению, и это не повод считать настройку неудачной.
Поможет ли корректный PTR, если IP-адрес ранее засветился в рассылке спама?
Не полностью — PTR лишь один из элементов репутации отправителя, и крупные почтовые фильтры в первую очередь смотрят на историю самого IP-адреса. Если адрес уже находится в чёрных списках из-за прошлого владельца, корректная обратная запись снизит часть отказов, но не отменит проверку репутации, и часть писем всё равно будет попадать в спам или отклоняться.
Обязательно ли PTR-имя сервера должно совпадать с доменом сайта?
Нет, для сайта это не требуется вовсе — PTR критичен именно для почтового сервера и должен совпадать с HELO-именем, которое Postfix или Exim называет себя при подключении к другому серверу. Это имя может отличаться от домена сайта: главное, чтобы оно совпадало с HELO и у него была соответствующая A-запись, указывающая обратно на тот же IP.