Reverse DNS (PTR): как настроить rDNS и пройти FCrDNS для почты

Reverse DNS (обратная зона) отвечает на вопрос: «Какое доменное имя соответствует этому IP-адресу?». На практике это запись PTR в обратной DNS-зоне. Чаще всего она всплывает при настройке почтового сервера, разборе проблем с доставляемостью (mail deliverability) и проверках антиспам-систем.

Ниже — практическая инструкция: как работает PTR/rDNS, почему важна проверка FCrDNS, как согласовать HELO/EHLO с обратной записью и чем отличается «PTR есть» от «сделано правильно».

Что такое PTR, reverse DNS и rDNS

Обычный DNS сопоставляет имя → IP: домен mail.example.com указывает на A/AAAA. Reverse DNS делает наоборот: IP → имя. Это и есть запись PTR в специальной обратной зоне.

Термины, которые встречаются в документации и проверках:

• reverse DNS — общий термин «обратный DNS»;
• rDNS — распространённое сокращение reverse DNS;
• PTR — тип DNS-записи, который хранит «IP → имя»;
• ip PTR — разговорное обозначение PTR, привязанного к конкретному IP;
• rDNS check — проверка наличия и корректности PTR/FCrDNS;
• FCrDNS (Forward-confirmed reverse DNS) — проверка, что обратная запись подтверждается прямой.

Как устроена обратная зона: in-addr.arpa и ip6.arpa

Для IPv4 обратная зона — домен in-addr.arpa. IP разворачивается «справа налево». Например, для 203.0.113.25 обратное имя будет таким:

25.113.0.203.in-addr.arpa

Для IPv6 используется зона ip6.arpa, и адрес разворачивается по nibble (по одному hex-символу на метку), поэтому выглядит длинно. Практический вывод простой: IPv6 PTR тоже нужен, но настраивается обычно через провайдера IP так же, как и IPv4.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Зачем PTR нужен почте и что ломается без него

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

Типовые сценарии:

• сервер принимает соединение, но снижает репутацию (письма чаще попадают в спам);
• сервер отклоняет письмо на этапе SMTP с сообщением вроде «No reverse DNS»;
• сервер сравнивает HELO/EHLO и PTR и ругается на несоответствие;
• аудиты показывают «FCrDNS fail».

PTR — не «волшебная кнопка доставляемости», но обязательный базовый сигнал гигиены. Если PTR отсутствует или настроен криво, остальные меры (DKIM/DMARC, прогрев, репутация) будут работать хуже.

Что такое FCrDNS и почему «PTR есть» недостаточно

FCrDNS (Forward-confirmed reverse DNS) — это проверка согласованности в обе стороны:

1. Берём IP отправителя и смотрим его PTR (reverse DNS).
2. Берём имя из PTR и смотрим его A/AAAA (forward DNS).
3. Проверяем, что среди полученных IP есть исходный IP.

Если любой шаг не сходится — FCrDNS не проходит.

Пример корректной схемы

• IP: 203.0.113.25
• PTR: mail.example.com
• A для mail.example.com: 203.0.113.25

Типичный пример некорректной схемы

• PTR: server-25.somehost.net (имя провайдера)
• HELO: mail.example.com
• A для server-25.somehost.net ведёт на другой IP

В этом случае rDNS формально есть, но FCrDNS не проходит, и часть антиспам-систем будет считать это плохим сигналом.

PTR и HELO/EHLO: как связаны и как сделать правильно

Когда ваш SMTP-сервер устанавливает соединение, он представляется строкой HELO или EHLO. Принимающая сторона может сравнить:

• IP соединения → PTR (reverse DNS);
• домен в HELO/EHLO → A/AAAA (forward DNS);
• и затем увязать это через FCrDNS.

Практическая схема, которая минимизирует вопросы:

• выберите одно стабильное имя для MTA, например mail.example.com;
• сделайте A/AAAA этого имени на реальный исходящий IP;
• попросите провайдера IP выставить PTR на это же имя;
• настройте MTA, чтобы он использовал это имя в HELO/EHLO.

Если вы поднимаете почту на сервере, который живёт в облаке, удобнее всего делать это на VDS со стабильным IP: тогда PTR предсказуемо управляется и не ломается при смене адреса.

Кто управляет PTR и почему его нельзя «просто добавить в DNS-зоне домена»

Частая ошибка — пытаться добавить PTR в зоне своего домена у обычного DNS-провайдера. PTR живёт не в зоне example.com, а в обратной зоне, которую делегирует владелец IP-подсети.

Обычно это:

• хостинг-провайдер или дата-центр (для выделенного/арендованного IP);
• ISP (для домашних/офисных подключений);
• облачный провайдер (для облачных IP).

То есть на практике настройка reverse DNS выглядит как «указать желаемое PTR-имя в панели провайдера» или «написать в поддержку». Если у вас несколько IP, PTR задаётся отдельно для каждого (каждый ip PTR — отдельная запись).

Какой PTR-нейм выбрать: правила, которые реально помогают

Ограничений по RFC немного, но антиспам-практика выработала понятные требования:

• PTR должен указывать на полное доменное имя (FQDN), а не на голый домен. Хорошо: mail.example.com, хуже: example.com.
• Имя из PTR должно разрешаться (иметь A/AAAA) и указывать обратно на тот же IP (для FCrDNS).
• Имя не должно выглядеть случайным мусором. Если есть выбор между mail.example.com и vps-203-0-113-25.example.com, обычно лучше первое.
• Если с одного IP отправляет несколько доменов, PTR всё равно будет один. Это нормально: PTR — идентификатор хоста/MTA, а не всех доменов отправки.

Про «владение» именем: PTR может указывать на ваш домен (например, mail.example.com), но сам домен должен быть под вашим контролем. Если домен ещё не зарегистрирован — сначала нужна регистрация доменов, иначе вы не сможете корректно настроить прямые записи A/AAAA.

rDNS check: как проверить PTR и FCrDNS с консоли

Ниже — базовые команды для самопроверки (Linux/macOS; в Windows можно через WSL). Подставьте свой IP и имя.

Проверка PTR (reverse DNS) через dig

dig -x 203.0.113.25 +short

Ожидаемый ответ — доменное имя, например:

mail.example.com.

Проверка прямого разрешения имени (forward DNS)

dig A mail.example.com +short

dig AAAA mail.example.com +short

В ответе должен быть ваш IP (для IPv4 в A, для IPv6 в AAAA).

Проверка FCrDNS «вручную»

Алгоритм простой: сначала делаете dig -x, затем dig A/dig AAAA для имени из PTR и проверяете, что исходный IP присутствует в ответе. Если совпало — FCrDNS проходит.

Проверка HELO/EHLO со стороны клиента

Убедиться, чем именно представляется ваш сервер, можно через ручное SMTP-подключение. Важно: здесь вы проверяете строку EHLO, а не TLS/аутентификацию.

openssl s_client -starttls smtp -connect mail.example.com:25 -crlf

Дальше в сессии отправьте команду (вводится руками):

EHLO test.example.com

В ответе сервер обычно печатает свои возможности. Параллельно проверьте настройки MTA: например, в Postfix ключевые параметры — myhostname и корректное системное имя хоста. Если HELO не совпадает с PTR, это не всегда фатально, но повышает риск фильтрации.

Частые ошибки при настройке PTR/rDNS и как их исправлять

Ошибка 1: PTR указывает на имя, которого не существует

PTR выставили, но A/AAAA забыли. Итог: FCrDNS fail. Решение — создать A/AAAA для имени из PTR и направить её на тот же IP.

Ошибка 2: A/AAAA указывает на другой IP

Часто бывает после миграций: имя переехало, а PTR остался старый (или наоборот). Решение — синхронизировать: либо обновить PTR на новое имя, либо вернуть A/AAAA имени из PTR на реальный исходящий IP.

Ошибка 3: PTR указывает на общий «провайдерский» hostname

Иногда это допустимо (особенно если провайдер не даёт менять PTR), но для почтовой репутации лучше иметь имя вашей инфраструктуры. Решение — завести поддомен под почту и попросить провайдера выставить PTR на него.

Ошибка 4: попытка «сделать PTR у себя в зоне»

Нельзя настроить reverse DNS для чужой IP-сети без делегации обратной зоны. Решение — менять PTR у владельца IP-адреса.

Ошибка 5: HELO говорит одно, PTR другое, а FCrDNS не проходит

Такой набор выглядит подозрительно. Решение — привести к единой схеме: HELO = PTR = A/AAAA (в идеале).

Практический чеклист: «минимально правильно» для исходящей почты

1. Есть выделенный (или хотя бы стабильный) исходящий IP.
2. Для IP настроен PTR на mail.example.com.
3. Для mail.example.com настроены A/AAAA на этот же IP.
4. FCrDNS проходит (проверено через dig -x и dig A/dig AAAA).
5. SMTP-сервер использует в HELO/EHLO имя mail.example.com.

Это не гарантирует «идеальную доставляемость», но убирает одну из самых частых причин жёстких отказов и делает поведение принимающих серверов более предсказуемым.

Что делать, если PTR не дают менять или IP динамический

Если IP динамический (домашний интернет/мобильные сети) или провайдер не меняет PTR, отправка почты напрямую почти всегда будет проблемной: такие диапазоны часто имеют массовые PTR и нередко попадают под блок-политики крупных почтовиков.

Практичный подход — обеспечить отправку через инфраструктуру со стабильным IP и управляемым PTR. Дальше уже имеет смысл наводить «почтовую гигиену» (SPF/DKIM/DMARC, TLS, лимиты, репутация) без постоянных провалов на фундаменте.

Итоги: почему PTR — маленькая настройка с большим эффектом

Reverse DNS и запись PTR — одна из тех инфраструктурных деталей, которые напрямую влияют на результат: на mail deliverability, доверие при входящих проверках и количество сюрпризов при миграциях.

Если упростить до одного правила: сделайте так, чтобы IP → PTR → A/AAAA → тот же IP, и чтобы ваш SMTP-сервер говорил в HELO то же имя. Это и есть практический смысл FCrDNS.

Если хотите глубже разобраться, как правильно делегировать DNS и не ломать зону при переносах, полезны материалы: делегирование NS для поддомена и перенос домена с учётом DNS и EPP.