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

Когда ваш сервер подключается к Gmail или Mail.ru, первое, что делает принимающая сторона, — смотрит на IP-адрес и спрашивает DNS: «Какое имя у этого адреса?» Ответ хранится в PTR-записи. Если ответа нет или он не совпадает с тем, за кого представляется сервер, — письмо рискует не дойти до получателя.

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

Прямой DNS (forward DNS) переводит доменное имя в IP-адрес. Вы набираете mail.example.com, DNS возвращает 93.184.216.34. Это A-запись, и с ней знакомы все, кто хоть раз настраивал домен.

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

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

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

Обратите внимание: прямой DNS контролирует владелец домена. Обратный DNS контролирует владелец IP-блока — как правило, хостинг-провайдер или дата-центр. Это принципиальное отличие, из-за которого настройка PTR требует обращения к провайдеру.

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

PTR (Pointer Record) — тип DNS-записи, который связывает IP-адрес с доменным именем. Технически она хранится в обратной зоне DNS. Для IP 93.184.216.34 PTR-запись будет находиться в зоне 34.216.184.93.in-addr.arpa. Октеты IP-адреса записываются в обратном порядке — это стандарт.

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

Одному IP может соответствовать несколько PTR-записей, но на практике почтовые серверы ожидают ровно одну. Несколько PTR — нетипичная конфигурация, которая иногда вызывает вопросы у антиспам-систем.

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

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

Gmail прямо пишет в документации для массовых отправителей: IP-адрес отправляющего сервера должен иметь PTR-запись. Без неё шансы попасть во входящие снижаются. Mail.ru и Yandex придерживаются аналогичных правил, хотя формулируют мягче.

Отсутствие PTR — один из признаков, по которым провайдеры отличают легитимные почтовые серверы от заражённых машин и ботнетов. Домашний компьютер, превращённый в спам-бот, как правило, отправляет почту с динамического IP без PTR. Настроенный почтовый сервер — со статического IP с корректной PTR-записью.

FCrDNS: двойная проверка, которая решает всё

PTR-запись сама по себе — только половина дела. Настоящая проверка называется FCrDNS (Forward-Confirmed Reverse DNS). Она состоит из двух шагов:

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

Если IP на выходе совпадает с IP на входе — FCrDNS пройдена. Это доказывает, что владелец домена и владелец IP-блока согласны друг с другом: «Да, этот IP — действительно наш почтовый сервер».

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

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

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

Когда FCrDNS не проходит, принимающий сервер видит несоответствие. IP говорит, что он mail.example.com, но mail.example.com указывает на другой IP. Или PTR вообще отсутствует. Это повышает «спамовый балл» письма в фильтрах.

FCrDNS — это рукопожатие между прямым и обратным DNS. Если оно не состоялось, почтовый сервер имеет основания не доверять отправителю.

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

Проблемы с обратным DNS встречаются чаще, чем кажется. Вот ситуации, которые мы видим регулярно.

• PTR не настроена. Сервер арендован, IP получен, почта настроена — а PTR никто не запросил у провайдера. Обратный запрос возвращает пустой ответ. Gmail и другие крупные провайдеры воспринимают это как признак непрофессиональной или временной инфраструктуры.
• PTR указывает на дефолтное имя хостера. Провайдер автоматически прописал что-то вроде vps12345.hosting.provider.net. Формально PTR есть, но FCrDNS не пройдёт, потому что ваш почтовый сервер представляется как mail.yourdomain.com.
• PTR есть, но A-запись не совпадает. Вы переехали на новый IP, обновили A-запись, но забыли попросить хостера обновить PTR. Обратный DNS указывает на правильное имя, но прямой DNS возвращает уже новый IP. FCrDNS провалена.
• PTR настроена на поддомен, а EHLO отдаёт другой. PTR возвращает smtp.example.com, а сервер в EHLO представляется как mail.example.com. Некоторые фильтры рассматривают это как несоответствие, хотя домен второго уровня одинаковый.
• Динамический IP. Домашние и офисные интернет-подключения используют динамические IP-адреса. PTR для них обычно содержит характерный паттерн: pool-12-34-56-78.isp.net. Многие провайдеры сразу блокируют входящие SMTP-соединения с таких адресов.

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

Диагностика обратного DNS — дело нескольких команд. Все утилиты доступны в Linux и macOS из коробки.

dig (рекомендуемый)

# Обратный запрос по IP
$ dig -x 74.125.45.100 +short
mail-yw1-f100.google.com.

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

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

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

host

# Самый короткий вариант
$ host 74.125.45.100
100.45.125.74.in-addr.arpa domain name pointer mail-yw1-f100.google.com.

# Только PTR
$ host -t PTR 74.125.45.100

Команда 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 другой или ответ пустой → проблема

Эту проверку стоит делать после любых изменений инфраструктуры: миграция сервера, смена IP, переход к другому хостеру. FCrDNS не сломается сама — но ломается каждый раз, когда меняется IP или PTR без синхронизации обоих направлений.

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

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

1. Определите IP вашего почтового сервера. Это IP, с которого уходят письма. Если вы используете выделенный SMTP-сервер, он указан в настройках. Если ESP — PTR уже настроена провайдером рассылки, и вам делать ничего не нужно.
2. Обратитесь к хостинг-провайдеру. У большинства хостеров (Hetzner, OVH, DigitalOcean, Selectel, Timeweb) есть панель для настройки PTR. Обычно она находится в разделе управления IP-адресами или сетью. Если панели нет — создайте тикет в поддержку.
3. Укажите hostname вашего почтового сервера. Например, mail.yourcompany.com. Это имя должно совпадать с тем, что сервер передаёт в EHLO.
4. Убедитесь, что A-запись указывает обратно на тот же IP. Зайдите в панель DNS вашего домена и проверьте, что mail.yourcompany.com резолвится в тот же IP, для которого настроена PTR. Без этого FCrDNS не пройдёт.
5. Подождите распространения. PTR-записи обновляются обычно за минуты, но кэширование DNS может задержать видимость до нескольких часов. Проверяйте через dig -x с указанием внешнего DNS-сервера.

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

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

Ваша задача — корректно настроить SPF, DKIM и DMARC для своего домена. PTR в этом случае подтверждает легитимность инфраструктуры ESP, а SPF и DKIM подтверждают, что ESP авторизован отправлять почту от вашего имени.

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

PTR для IPv6

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

# Обратный запрос для IPv6
$ dig -x 2607:f8b0:4004:800::200e +short
mail-yw1-f14.google.com.

Если ваш сервер отправляет почту по IPv6, PTR нужна и для IPv6-адреса тоже. Gmail отклоняет входящие SMTP-соединения по IPv6 без корректной PTR. Это описано в их документации для отправителей.

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

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

Можно пройти SPF и DKIM, но провалить PTR-проверку. Письмо при этом скорее всего будет доставлено (SPF и DKIM весят больше), но получит дополнительные негативные баллы в спам-фильтре. Со временем это сказывается на репутации IP.

Обратная ситуация: PTR настроена, FCrDNS проходит, но SPF и DKIM отсутствуют. В 2026 году этого недостаточно. Gmail и Yahoo требуют DMARC с как минимум одним пройденным механизмом (SPF или DKIM) для всех массовых отправителей. PTR — необходимое, но не достаточное условие.

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

• PTR содержит generic hostname. Имена вида 12-34-56-78.static.provider.net формально проходят rDNS-проверку, но спам-фильтры присваивают им повышенный балл. Используйте имя вашего домена.
• Несколько PTR для одного IP. RFC допускает это, но почтовые фильтры ожидают ровно одну запись. Лишние PTR создают неоднозначность.
• PTR настроена, но EHLO отдаёт localhost. Дефолтная конфигурация Postfix иногда использует localhost в EHLO. Принимающий сервер видит несоответствие между PTR и EHLO — это плохой сигнал. Проверьте myhostname в конфигурации Postfix.
• Забыли про IPv6. Сервер слушает и на IPv4, и на IPv6. PTR настроена только для IPv4. Часть соединений устанавливается по IPv6 и проваливает проверку.
• Сменили сервер, не обновили PTR. При миграции на новый IP нужно: создать PTR у нового хостера, обновить A-запись в DNS домена, убедиться, что EHLO настроен правильно. Только после этого переключать отправку.

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

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

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)

Если в скобках после имени хоста стоит то же самое имя — обратный DNS прошёл. Если вместо имени указан только IP или стоит слово unknown — PTR отсутствует или не резолвится.

Также полезна строка Authentication-Results:. В ней можно увидеть результаты SPF, DKIM, DMARC, а иногда и явную пометку о rDNS.