PTR-запись: почему без неё письма не доходят

MAATRIX

Вы настроили Postfix, прописали SPF, DKIM и DMARC, отправили тестовое письмо — и оно улетело в спам или вообще не дошло. Причина часто не в контенте письма и не в подписях DNS, а в записи, о которой почти никто не вспоминает: PTR. Разберёмся, что это такое, почему принимающие сервера так на неё смотрят и что конкретно делать, чтобы всё заработало.

Прямая и обратная DNS-запись: в чём разница

Обычная DNS-запись, с которой все работают ежедневно, называется прямой (forward) — это A-запись, которая отвечает на вопрос «какой IP-адрес у домена mail.example.com?». Вы вводите домен — получаете IP. Именно эту запись вы настраиваете в панели управления доменом или у регистратора, добавляя A-запись, указывающую на IP вашего сервера.

PTR-запись (Pointer Record) работает в обратную сторону. Она отвечает на вопрос «какое доменное имя связано с IP-адресом 203.0.113.45?». Вы вводите IP — получаете домен. Технически это запись типа PTR в специальной зоне in-addr.arpa (для IPv4) или ip6.arpa (для IPv6), а не в зоне вашего домена.

Ключевой момент, который часто упускают: эти две записи логически независимы друг от друга. Наличие правильной A-записи (домен → IP) никак не гарантирует наличие правильной PTR-записи (IP → домен). Это две разные записи, в двух разных зонах DNS, и настраиваются они разными способами и, как правило, разными людьми. Вы можете идеально настроить SPF, DKIM, DMARC и A-запись для mail.example.com — и всё равно получать отказы, если для IP-адреса сервера не настроен корректный обратный PTR.

Проверить наличие и корректность обеих записей нужно отдельно — это не разные грани одной настройки, а две отдельные задачи.

Почему PTR-запись критична именно для почты

Когда ваш почтовый сервер устанавливает соединение с принимающим сервером (Gmail, Yandex, Mail.ru, корпоративный Exchange и так далее), он представляется по протоколу SMTP командой HELO/EHLO, называя своё доменное имя. Принимающий сервер в ответ часто выполняет обратный DNS-запрос по IP-адресу, с которого пришло соединение, чтобы узнать, какое имя официально закреплено за этим IP через PTR.

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

• PTR-запись вообще существует. Если для IP нет никакой PTR-записи — это уже подозрительно.
• PTR-запись резолвится в разумное доменное имя, а не остаётся «голым» IP или generic-именем провайдера вида vps-123-45-67-89.example-hosting.net.
• Домен из PTR совпадает (или разумно соответствует) с тем именем, которое сервер заявил в HELO/EHLO. Это называется forward-confirmed reverse DNS (FCrDNS): PTR указывает на домен, а прямая A-запись этого домена возвращает исходный IP — круг замыкается.

Почему это так важно именно для спам-фильтрации? Легитимные почтовые сервера обычно принадлежат организациям, которые арендуют выделенный IP и настраивают его должным образом — включая PTR. Скомпрометированные машины, боты в составе ботнетов и массовые спам-рассылки, наоборот, чаще всего работают с динамических или пуловых IP-адресов, где обратная запись либо отсутствует, либо генерируется автоматически провайдером и никак не связана с доменом, от имени которого рассылается спам.

Поэтому отсутствие PTR или явное несоответствие PTR и HELO — сильный сигнал подозрительности. Крупные провайдеры (в статье про переход с Gmail на свой почтовый сервер разбирали похожие моменты доставляемости) применяют это как один из первых фильтров ещё до анализа содержимого письма и репутации IP. Некоторые сервера просто отклоняют соединение на этапе HELO, если PTR не резолвится — письмо не дойдёт даже до спам-фильтра, оно не будет принято вовсе.

Важно понимать: PTR — это не единственное условие доставляемости. SPF, DKIM и DMARC (см. настройку SPF, DKIM и DMARC на VPS) остаются обязательными и решают другие задачи — подтверждение права отправлять письма от имени домена и защиту от подделки. PTR решает свою, отдельную задачу: подтверждение того, что IP-адрес сам по себе выглядит как легитимный почтовый сервер, а не как случайная машина из пула хостинга.

Кто на самом деле контролирует PTR-запись

Здесь кроется главное практическое отличие от привычной работы с DNS. Обычные записи вашего домена (A, MX, TXT для SPF/DKIM/DMARC) вы настраиваете сами — через панель управления доменом у регистратора или в DNS-зоне, которую администрируете (например, через PowerDNS или Bind9). Это ваша зона, ваш домен, полный контроль.

PTR-запись устроена иначе. Зона in-addr.arpa для конкретного блока IP-адресов контролируется не владельцем домена, а владельцем IP-адреса — то есть, как правило, вашим хостинг- или VPS-провайдером. Вы арендуете IP, но саму делегацию обратной зоны для этого блока держит провайдер (или вышестоящий регистратор адресного пространства, RIR — RIPE, ARIN и так далее — в зависимости от того, как организована инфраструктура).

Практическое следствие: вы не можете зайти в свою панель управления доменом и прописать PTR для арендованного IP так же, как прописываете A-запись. Нужно обращаться именно к тому, кто выдал вам IP-адрес — то есть к VPS/хостинг-провайдеру.

Как это выглядит на практике:

1. Заходите в панель управления VPS у вашего провайдера — у многих есть отдельный раздел «Reverse DNS» или «PTR-записи» прямо в интерфейсе, где можно указать нужное доменное имя для арендованного IP самостоятельно, без обращения в поддержку.
2. Если такого раздела нет, открываете тикет в поддержку с формулировкой примерно такой: «Прошу настроить PTR-запись (reverse DNS) для IP-адреса 203.0.113.45, указывающую на mail.example.com». Уточните оба значения точно — IP и домен, — чтобы не было путаницы.
3. Убедитесь, что домен, который вы просите указать в PTR, уже имеет корректную A-запись, возвращающую именно этот IP. Некоторые провайдеры проверяют это перед тем, как выставить PTR, — если A-записи ещё нет, настройте её заранее (см. настройку домена и DNS с нуля на Ubuntu 24.04 или на Debian 12, если сервер на другой ОС).
4. Дождитесь применения — обычно это происходит в течение нескольких минут до пары часов, но у части провайдеров может занимать до суток, если запрос обрабатывается вручную.

Если вы разворачиваете почтовый сервер на нескольких IP (например, отдельный IP под исходящую рассылку и отдельный под основной трафик — см. сколько ресурсов нужно VPS для почтовой рассылки), PTR нужно настраивать отдельно для каждого IP, с которого реально уходит почта.

Как проверить текущее состояние PTR-записи

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

Базовая проверка через утилиту dig (или nslookup, если dig недоступен):

dig -x 203.0.113.45 +short

Замените IP на свой. Флаг -x как раз указывает dig выполнить обратный запрос. Ожидаемый вывод — доменное имя вашего почтового сервера с точкой на конце:

mail.example.com.

Если вывод пустой — PTR-запись ещё не настроена или не применилась. Если вывод показывает generic-имя провайдера вида 203-0-113-45.hosting-provider.net — значит провайдер выставил PTR по умолчанию, а ваш запрос ещё не применился либо не был обработан.

Второй шаг — проверить обратное соответствие (FCrDNS), убедившись что домен из PTR действительно возвращает исходный IP:

dig +short mail.example.com

Результат должен совпадать с IP, для которого вы проверяли PTR. Если не совпадает — где-то рассинхрон: либо A-запись домена указывает на другой IP, либо PTR настроен не на тот домен.

Дополнительно полезно проверить командой host:

host 203.0.113.45

Она выдаёт то же самое в чуть другом формате и бывает удобнее для быстрой проверки без флагов.

Если у вас нет под рукой Linux-машины с этими утилитами, аналогичную проверку делают многие онлайн-инструменты для MX/PTR-диагностики — но команда dig -x доступна практически в любом дистрибутиве из коробки, и для разовой проверки нет смысла искать веб-сервис.

Проверяйте PTR не только сразу после настройки, но и через день-два — иногда DNS-кэши резолверов у получателей (Gmail, Yandex и других) держат старое значение TTL записи какое-то время, и письма могут продолжать попадать в спам ещё некоторое время после того, как сама запись уже верна.

Типичные ошибки при настройке PTR

• PTR указывает на IP хостинг-провайдера, а не на ваш домен. Так бывает, если запрос в поддержку не был обработан или вы проверяете не тот IP (например, IP из внутренней сети вместо публичного).
• Домен в PTR не совпадает с тем, что сервер заявляет в HELO/EHLO Postfix. Проверьте настройку myhostname в /etc/postfix/main.cf — она должна точно совпадать со значением PTR:

myhostname = mail.example.com

• A-запись домена не настроена или указывает на другой IP. PTR без прямого соответствия — это половина работы; принимающие сервера, которые проверяют FCrDNS, всё равно откажут.
• PTR настроен для одного IP, а почта фактически уходит с другого. Особенно актуально при NAT, нескольких сетевых интерфейсах или при аренде дополнительного IP под конкретный сервис.
• Провайдер вообще не даёт настраивать PTR на вашем тарифе. Об этом — отдельно ниже, потому что это не столько ошибка настройки, сколько ошибка выбора инфраструктуры ещё на старте.

На что смотреть при выборе VPS-провайдера под почтовый сервер

Если вы только планируете разворачивать собственный почтовый сервер — на Postfix или на связке вроде iRedMail/Mailcow — стоит выяснить возможность настройки PTR ещё до того, как вы закажете сервер и начнёте разворачивать инфраструктуру, а не постфактум, когда письма уже не доходят.

Не все тарифы, особенно бюджетные или базовые, дают клиенту возможность управлять reverse DNS для своего IP. Причины разные: часть провайдеров держит эту функцию только на выделенных серверах или на определённых линейках VPS, часть — считает её «продвинутой» опцией и включает только по запросу в поддержку, а часть на самых дешёвых тарифах вообще не предоставляет отдельный выделенный IP (используется общий пул адресов), из-за чего настроить персональную PTR-запись физически невозможно.

Что стоит уточнить у провайдера заранее:

• Есть ли у тарифа выделенный (dedicated) IPv4-адрес, а не общий/NAT.
• Можно ли настроить PTR самостоятельно через панель управления или только через тикет.
• Сколько времени обычно занимает обработка такого тикета, если самостоятельной настройки нет.
• Не находится ли IP-диапазон в чёрных списках (это отдельная, но смежная проблема — стоит проверить репутацию блока IP до аренды, если он уже использовался ранее другими клиентами).

Сравнение подходов у разных типов тарифов:

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

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