PTR-запись и обратный DNS: почему отсутствие rDNS губит доставку писем

Большинство отправителей писем никогда не трогают PTR-записи. Это дело берёт на себя их ESP (Mailchimp, SendPulse, GetResponse). Но как только вы перейдёте на выделенный IP, настроите собственный relay или запустите облачный VM с Postfix, PTR становится вашей проблемой — и в 90% случаев она уже есть.

Самое главное

Если на вашем отправляющем IP нет PTR-записи или она не соответствует forward-DNS (не проходит FCrDNS), Gmail будет тихо замораживать вашу доставку, а Outlook откажет на уровне SMTP с кодом 5xx. Исправьте PTR ещё до того, как будете настраивать SPF.

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

PTR — это сокращение от Pointer (указатель). Если A-запись отображает имя хоста на IP-адрес, то PTR-запись делает обратное — отображает IP на имя хоста. PTR-записи живут в специальной DNS-зоне in-addr.arpa (для IPv4) или ip6.arpa (для IPv6). Ключевой момент: PTR контролирует владелец IP-адреса, а не владелец домена.

Для IP-адреса 192.0.2.25 PTR-запись находится в 25.2.0.192.in-addr.arpa и обычно резолвится на что-то вроде mail.example.com. Можно запросить её напрямую:

$ dig -x 192.0.2.25 +short
mail.example.com.

Forward-confirmed reverse DNS (FCrDNS)

Одной PTR-записи недостаточно. Почтовые провайдеры требуют forward-confirmed reverse DNS — круг должен замкнуться. Процесс выглядит так:

Обратный поиск (reverse lookup) IP-адреса. Получаем имя хоста (например, mail.example.com).
Прямой поиск (forward lookup) этого имени хоста. Получаем IP-адрес или несколько адресов.
Проверяем, что исходный IP есть в полученном наборе.

Если один из шагов не пройдёт, FCrDNS не работает. Вот пример успешной FCrDNS:

$ dig -x 192.0.2.25 +short
mail.example.com.
$ dig mail.example.com +short
192.0.2.25

А вот пример неудачной:

$ dig -x 192.0.2.25 +short
ec2-192-0-2-25.compute-1.amazonaws.com.
$ dig ec2-192-0-2-25.compute-1.amazonaws.com +short
192.0.2.25   # технически FCrDNS проходит, но выглядит как чистый облачный хост

Второй пример замыкается корректно, поэтому формально FCrDNS работает. Проблема в содержании имени хоста. Почтовые провайдеры используют паттерны дженерик-облачных имён как сильный спам-сигнал. PTR типа ec2-203-0-113-45.compute-1.amazonaws.com вам не поможет.

Почему Gmail, Outlook и Yahoo требуют PTR

Все крупные почтовые провайдеры в своей документации указывают PTR как обязательный для bulk-отправителей. На практике:

Gmail. В правилах 2024 года для bulk-отправителей PTR указана обязательной требованием. Письма с IPs без PTR всё ещё попадают на почтовый сервер, но сразу отправляются в Спам.
Outlook / Microsoft 365. Самый строгий из крупных провайдеров. Отсутствие PTR приводит к отказу на уровне SMTP с кодом 5xx ещё до достижения фильтра контента. В bounce-письме явно упоминается PTR.
Yahoo. Те же правила 2024 года, что и Gmail. Несоответствие PTR рассматривается как отсутствие PTR.
Mail.ru и Яндекс. Оба агрессивно понижают ранг письма с облачных паттернов PTR. Яндекс имеет документированный список generic-суффиксов имён хостов, которые автоматически отправляют письма в Спам.

Два распространённых режима отказа PTR

1. PTR вообще отсутствует

Типичная ситуация на VPS. Вы провизионировали инстанс, назначили IP, запустили Postfix — всё выглядит хорошо. Но исходящая почта отказывается для Outlook-получателей и попадает в Спам в Gmail. Команда dig -xна вашем IP возвращает NXDOMAIN или вообще ничего.

2. Несоответствие или дженерик PTR

Ваша PTR-запись указывает mail.example.com, но A-запись для mail.example.com указывает на другой IP-адрес. Круг не замыкается, FCrDNS не проходит, системы аутентификации флагируют несоответствие. Или ваша PTR так и не была изменена с дефолтного значения провайдера типа static.203.0.113.in-addr.arpa.

Настройка rDNS по провайдерам

Hetzner

В Cloud Console или панели Robot откройте сервер, затем список IP, и нажмите на иконку редактирования рядом с каждым IP. Введите полное имя хоста (FQDN, без точки в конце, без протокола). Hetzner опубликует PTR за несколько минут. Повторите для IPv6.

OVH

OVH управляет IP отдельно от серверов. Перейдите в Bare Metal Cloud → IP, найдите адрес, нажмите на иконку ⚙ и выберите Modify the reverse. Важно: OVH требует, чтобы прямая A-запись существовала и совпадала, прежде чем принимать PTR. Создайте A-запись сначала.

AWS — EC2 и SES

Для EC2 откройте запрос в поддержку из консоли AWS: Service → EC2 → Feature Request → Reverse DNS. Укажите Elastic IP и имя хоста. AWS требует MX или SPF-запись, затрагивающую это имя хоста, чтобы проверить контроль. Обычно одобрение занимает до 48 часов.

Для SES вы не настраиваете PTR самостоятельно. SES управляет rDNS для своего шаренного пула. На выделенных IP PTR по умолчанию устанавливается на SES-домен; вы можете запросить у AWS support пользовательский MAIL FROM домен и пользовательскую PTR.

DigitalOcean

DigitalOcean автоматически устанавливает PTR на основе имени Droplet. Поэтому, если вы хотите mail.example.com в качестве PTR, переименуйте Droplet ровно на это. Звучит странно, но это документировано. IPv6 PTRs работают по тому же правилу.

Правило большого пальца

Ваша PTR должна выглядеть как настоящее имя mail-сервера под доменом, который вы контролируете. mail.example.com, smtp-out.example.com, mta1.example.com. Никогда не используйте чистый облачный паттерн провайдера. И A-запись для этого имени хоста должна указывать ровно на тот же IP.

Как проверить вашу PTR

dig -x 192.0.2.25 +short из терминала. Должна вернуть ваше выбранное имя хоста.
dig A mail.example.com +short. Должна включать тот же IP.
Отправьте тестовое письмо на check-auth@verifier.port25.com. Ответ содержит отдельную секцию FCrDNS.
MXToolbox SuperTool с опцией Reverse Lookup.
Или запустите бесплатный тест доставки — вкладка DNS за секунды покажет, есть ли отсутствие или несоответствие PTR.

Получите бесплатную проверку прямо сейчас

Бесплатный инструмент Inbox Check проверит вашу PTR, SPF, DKIM и DMARC за несколько секунд. Также покажет размещение письма по 9 провайдерам, включая Mail.ru и Яндекс.

→ Запустить бесплатный тест

Общий и выделенный IP — кто владеет PTR

На общем IP в ESP (SendGrid shared, Mailchimp, Postmark shared) PTR контролирует ESP, потому что ESP владеет IP-адресом. PTR будет выглядеть как o1.sendgrid.net или похоже. Вы не можете изменить её, и это правильно — PTR провайдера — часть его репутации.

На выделенном IP ESP обычно устанавливает PTR от вашего имени на домен ESP, и некоторые предлагают пользовательскую PTR, если вы предоставите имя хоста на своём домене. Это имеет смысл: PTR, совпадающая с вашим доменом, усиливает фирменный сигнал и помогает при проверке alignment в строгих провайдерах.

На вашем собственном IP (VPS, облачный VM, выделённый сервер) PTR ваша, и вы сами можете всё сломать. Именно в этом случае правила из этой статьи важнее всего.

Частые вопросы

Могу ли я установить PTR у провайдера DNS (Cloudflare, Route 53)?

Нет. PTR находится в обратной зоне, которой владеет тот, кто выделил IP, а не в прямой зоне вашего доменного провайдера. PTR настраивается у провайдера IP (хостер, облако), а не у DNS-провайдера.

Нужна ли PTR для IPv6 тоже?

Да. Если вы отправляете через IPv6 — а Gmail активно предпочитает IPv6, когда он доступен — вам нужна IPv6 PTR, которая также проходит FCrDNS. Отсутствие IPv6 PTR — один из самых частых регрессов доставки в 2026.

Моя PTR правильная, но письма всё ещё в Спаме. Что ещё?

PTR — необходимое, но не достаточное условие. После исправления PTR работайте с SPF, DKIM, DMARC alignment, чистотой списка и контентом. PTR — это просто открытие двери.

Может ли быть несколько PTR-записей на один IP?

Технически да, но не делайте этого. RFC и практика показывают, что на один IP должна быть одна PTR. Множественные PTR путают anti-abuse системы и некоторые рассматривают это как ошибку конфигурации.

PTR-запись и обратный DNS: скрытый убийца доставки