Обратный DNS и email: PTR-запись и FCrDNS

Когда ваш сервер подключается к Gmail или Mail.ru, принимающая сторона видит только IP-адрес и спрашивает у DNS, какое имя за ним стоит. Ответ хранится в PTR-записи. Нет ответа или имя не сходится с тем, как сервер представился, и письмо начинает путь с минуса, а у Gmail может и вовсе получить отказ.

Прямой и обратный DNS: в чём разница

Прямой DNS (forward DNS) переводит имя в IP-адрес. Запрашиваете mail.example.com, получаете 198.51.100.25. Это A-запись, с ней сталкивался каждый, кто хоть раз настраивал домен.

Обратный DNS (reverse DNS, rDNS) идёт в другую сторону, от IP-адреса к имени. Вопрос уходит не в зону вашего домена, а в служебную: in-addr.arpa для IPv4 и ip6.arpa для IPv6. Ответ на него и есть PTR-запись.

# Прямой DNS: имя → IP
$ dig A mail.example.com +short
198.51.100.25

# Обратный DNS: IP → имя
$ dig -x 198.51.100.25 +short
mail.example.com.

Прямую зону держит владелец домена. Обратную держит владелец блока IP-адресов, обычно хостинг-провайдер или дата-центр. Поэтому PTR не заводится там же, где MX и SPF, и за ней приходится идти к провайдеру.

Что такое PTR-запись

PTR (pointer record, запись-указатель) описана ещё в RFC 1035: она хранит доменное имя, на которое указывает адрес из обратной зоны. Для IP 198.51.100.25 запись лежит по имени 25.100.51.198.in-addr.arpa, октеты идут задом наперёд.

# PTR-запись в обратной зоне
25.100.51.198.in-addr.arpa.   IN   PTR   mail.example.com.

В IPv6 адрес раскладывают на отдельные шестнадцатеричные цифры, нибблы, переворачивают и дописывают в конце ip6.arpa. Запись выходит длинной, но устроена так же.

Несколько PTR на один адрес DNS не запрещает. Проверка iprev из RFC 8601 в таком случае перебирает имена (не больше заданного числа) и ищет то, что ведёт обратно на исходный IP. Почтовому серверу всё же проще жить с одним именем: его же он называет в EHLO, его же вы потом ищете в заголовках.

Зачем PTR нужна для отправки email

Отправляющий сервер открывает SMTP-соединение и представляется командой EHLO (или HELO), называя своё имя. Принимающий видит IP, с которого пришло соединение, и может запросить для него PTR сразу, ещё до команды MAIL FROM, то есть раньше, чем дело дойдёт до SPF, DKIM и DMARC.

Крупные почтовые сервисы пишут об этом прямо. Google в правилах для отправителей требует от всех, а не только от массовых рассылок, чтобы у отправляющих IP были корректные прямая и обратная записи, и отдельно оговаривает, что имя из PTR должно разрешаться обратно в тот же адрес. Yahoo ставит прямую и обратную DNS-записи в список обязательных требований для всех. Mail.ru просит осмысленную PTR, а не сгенерированную автоматически: правильным у них считается mail.domain.com, неправильным 231.2.53.243.domain.isp.com.

Зачем фильтрам эта проверка? Заражённый домашний компьютер шлёт спам с адреса провайдера, у которого PTR либо нет, либо стоит шаблонное имя вроде pool-12-34-56-78.isp.net. У сервера, который настраивал администратор, имя осмысленное и ведёт на свой домен. Ещё в 1996 году RFC 1912 предупреждал, что многие службы в интернете не станут разговаривать с хостом, который неправильно зарегистрирован в DNS.

FCrDNS: проверка в обе стороны

Одной PTR мало. Получатель обычно проверяет FCrDNS (forward-confirmed reverse DNS) в два шага.

1. Обратный запрос: для IP 198.51.100.25 PTR возвращает mail.example.com.
2. Прямой запрос: A-запись mail.example.com возвращает 198.51.100.25.

Совпал IP на выходе с исходным, значит проверка пройдена и владелец адреса с владельцем домена говорят об одном и том же сервере. В заголовке Authentication-Results этот тест называется iprev, его результаты (pass, fail, temperror, permerror) определены в RFC 8601.

# Шаг 1: обратный запрос (PTR)
$ dig -x 198.51.100.25 +short
mail.example.com.

# Шаг 2: прямой запрос (A)
$ dig A mail.example.com +short
198.51.100.25

# IP совпал → FCrDNS пройдена

Провал выглядит так. Адрес называет себя mail.example.com, а mail.example.com указывает на другой IP. Или PTR нет совсем, и тогда iprev вернёт permerror. В RFC 8601 сказано, что сервер часто просто отклоняет соединение, которое не прошло этот тест; другие записывают результат и учитывают его в оценке письма.

С именем из EHLO история отдельная. RFC 5321 разрешает серверу сверить его с IP клиента, но запрещает отказывать в приёме письма только из-за расхождения. Учитывать его как один из сигналов при этом никто не мешает, так что имя в EHLO лучше держать равным PTR.

Когда PTR и FCrDNS ломаются: типичные сценарии

Сломать обратный DNS проще, чем кажется. Часто хватает одного переезда.

• PTR не настроена. Сервер арендован, почта настроена, а PTR у провайдера никто не запросил. Обратный запрос приходит пустым, и письмо уже не выполняет требований Gmail и Yahoo.
• Имя по умолчанию от хостера. Провайдер сам прописал что-то вроде vps12345.hosting.provider.net. Формально запись есть, но с mail.yourdomain.com, которым сервер представляется в EHLO, она не совпадает. Yahoo к тому же просит, чтобы обратная запись так или иначе отражала ваш домен.
• PTR есть, но A-запись не совпадает. Вы переехали на новый IP, обновили A-запись и забыли попросить хостера поправить PTR. Обратный DNS по-прежнему называет правильное имя, но прямой ведёт уже на новый адрес, и FCrDNS не сходится.
• PTR на одном поддомене, EHLO на другом. PTR возвращает smtp.example.com, а сервер в EHLO представляется как mail.example.com. Домен второго уровня один, но часть фильтров засчитает это как несоответствие.
• Динамический IP. Домашние и офисные подключения получают адреса из пула, и PTR у них шаблонная: цифры IP прямо в имени плюс слова вроде dynamic, dhcp, dsl, pool или client. Mail.ru прямо запрещает соединения со своими MX с динамических адресов и адресов домашних сетей.

Как проверить PTR: dig, host, nslookup

Хватит пары команд. dig и host входят в набор утилит BIND, в Debian и Ubuntu их ставит пакет dnsutils. nslookup есть и в Windows.

dig

# Обратный запрос по IP
$ dig -x 198.51.100.25 +short
mail.example.com.

# Полный вывод с TTL и секцией authority
$ dig -x 198.51.100.25

# Через конкретный резолвер
$ dig -x 198.51.100.25 @8.8.8.8 +short

Флаг -x включает обратный запрос. Переворачивать октеты и дописывать in-addr.arpa руками не нужно, dig сделает это сам.

host и nslookup

$ host 198.51.100.25
25.100.51.198.in-addr.arpa domain name pointer mail.example.com.

# Windows и любая система без dig
> nslookup 198.51.100.25

host сам понимает, что ему дали IP, и делает обратный запрос. Вывод в одну строку, в скриптах это удобно.

Полная проверка FCrDNS за три команды

# 1. Узнаём PTR для IP вашего почтового сервера
$ dig -x 198.51.100.25 +short
mail.yourcompany.com.

# 2. Проверяем A-запись для полученного имени
$ dig A mail.yourcompany.com +short
198.51.100.25

# 3. IP совпадает с исходным → FCrDNS пройдена
#    Если IP другой или ответ пустой → проблема

Повторяйте проверку FCrDNS после любых перемен в инфраструктуре: переезд сервера, новый IP, смена хостера. Сама по себе FCrDNS не ломается. Ломается она тогда, когда IP или PTR поменяли, а вторую сторону оставили как была.

Как настроить PTR-запись

В панели DNS вашего домена (Cloudflare, Namecheap, REG.RU) PTR для своего сервера не создать, потому что обратная зона принадлежит владельцу IP-блока. Порядок такой.

1. Определите IP почтового сервера. Нужен тот адрес, с которого реально уходят письма. Если шлёте через ESP, PTR на его адресах уже настроил он.
2. Найдите настройку у хостинг-провайдера. У многих хостеров в разделе IP-адресов или сети есть поле Reverse DNS (rDNS). Поля нет, пишите в поддержку.
3. Впишите имя почтового сервера. Например, mail.yourcompany.com. Это имя сервер должен называть и в EHLO.
4. Проверьте, что A-запись ведёт на тот же IP. В DNS домена mail.yourcompany.com должен разрешаться в адрес, для которого заведена PTR, иначе FCrDNS не сойдётся.
5. Дождитесь обновления. Провайдер обычно применяет запись быстро, но резолверы могут держать старый ответ в кэше, пока не истечёт его TTL. Проверяйте dig -x через внешний резолвер.

PTR при использовании ESP или облачного SMTP

Если вы отправляете через сервис рассылок (Mailgun, Amazon SES, Postmark, Sendsay, Unisender), PTR на его IP-адресах настраивает он. От вас нужны SPF, DKIM и DMARC для своего домена. PTR в этой схеме подтверждает инфраструктуру ESP, а SPF и DKIM подтверждают, что ESP вправе слать почту от вашего имени.

Свой SMTP-сервер (Postfix, Exim, Microsoft Exchange на своём железе или VPS) совсем другое дело. Тут PTR целиком на вас, и без неё письма с сервера выглядят подозрительно ещё до того, как получатель увидит текст.

PTR для IPv6

Принцип тот же, запись длиннее: IPv6-адрес раскладывают по нибблам в обратном порядке и помещают в зону ip6.arpa.

# Обратный запрос для IPv6
$ dig -x 2001:db8::25 +short
mail.example.com.

Если сервер шлёт почту по IPv6, PTR нужна и IPv6-адресу. Gmail отвечает на такие письма ошибкой 550-5.7.1: Message does not meet IPv6 sending guidelines regarding PTR records and authentication. Google советует тем, кто шлёт через ESP, уточнить у него, есть ли PTR у IPv6-адресов.

PTR в контексте SPF, DKIM и DMARC

SPF, DKIM и DMARC проверяют отправителя на уровне домена, PTR проверяет IP-адрес на уровне инфраструктуры. Слои разные и друг друга не заменяют.

Пройти SPF и DKIM с пустой PTR можно, и у получателя без жёстких ограничений такое письмо может дойти. Только у Gmail и Yahoo обратная запись входит в обязательные требования, а сервер на Postfix с ограничением reject_unknown_reverse_client_hostname откажет такому клиенту раньше, чем дойдёт до подписи.

Обратный случай тоже не спасает. PTR на месте, FCrDNS проходит, а SPF и DKIM нет. Google и Yahoo требуют от всех отправителей хотя бы SPF или DKIM, а от массовых ещё и DMARC.

Чек-лист: частые ошибки с PTR

• Шаблонное имя в PTR. Имена вида 12-34-56-78.static.provider.net формально проходят rDNS-проверку, но Yahoo и Mail.ru прямо просят не использовать сгенерированные имена. Берите имя из своего домена.
• Несколько PTR для одного IP. DNS это допускает, iprev переберёт имена. Но имя в EHLO одно, и с каким из вариантов его сравнит конкретный фильтр, заранее не скажешь.
• EHLO отдаёт localhost или имя от хостера. Postfix берёт имя для EHLO из параметра myhostname, а тот по умолчанию равен имени машины. На свежем VPS это нередко localhost или что-то вроде vps12345, и с PTR оно не совпадёт.
• Забыли про IPv6. Сервер работает и по IPv4, и по IPv6, а PTR завели только для IPv4. Соединения по IPv6 проверку не проходят, и Gmail их отклоняет.
• Сменили сервер, не обновили PTR. При переезде на новый IP заведите PTR у нового хостера, обновите A-запись, проверьте имя в EHLO и только потом переключайте отправку.

Как увидеть результат проверки PTR в заголовках письма

Откройте доставленное письмо и посмотрите заголовки (в Gmail: три точки → «Показать оригинал»). Нужна строка Received:, которую добавил принимающий сервер.

Received: from mail.yourcompany.com (mail.yourcompany.com. [198.51.100.25])
        by mx.google.com with ESMTPS id ...
        for <user@gmail.com>;
        Tue, 20 May 2026 10:15:32 -0700 (PDT)

После from стоит имя, которое ваш сервер назвал в EHLO. В скобках принимающий сервер пишет то, что нашёл сам: имя по PTR и IP. Имена совпали, значит обратная запись на месте. Если в скобках только IP или слово unknown, как пишет Postfix, то PTR нет или она не разрешается.

Строка Authentication-Results: собирает результаты SPF, DKIM и DMARC. Серверы, которые проверяют FCrDNS, добавляют туда и iprev=pass или iprev=fail.

PTR и SMTP-проверка адресов

Валидатор, проверяя адрес, находит MX-записи домена получателя, подключается к его почтовому серверу и спрашивает, есть ли такой ящик. PTR сервера получателя на результат не влияет. Зато PTR того, кто проверяет, влияет напрямую, ведь для принимающего сервера валидатор такой же клиент, как любой отправитель.

В Postfix для этого есть два ограничения. reject_unknown_reverse_client_hostname отказывает клиенту без PTR, а более строгое reject_unknown_client_hostname требует ещё и сходящейся FCrDNS. По умолчанию Postfix отвечает на них кодом 450, и вместо ответа о ящике проверяющий получает временный отказ, а адрес остаётся непроверенным.

Поэтому в uChecker у каждого IP-адреса, с которого идёт SMTP-проверка, своё имя для EHLO, и оно должно совпадать с обратной записью этого адреса. Общее имя на все адреса сломало бы FCrDNS у всех, кроме одного.