Обратный DNS и PTR-запись: почему без них письма улетают в спам

Обратный DNS — это проверка «в обратную сторону»: не домен ищет IP-адрес, а IP-адрес ищет доменное имя. Отвечает за неё специальная PTR-запись, и без неё почтовый сервер рискует отправлять письма прямиком в спам или получать отказ в доставке — даже если с SPF, DKIM и DMARC у вас всё в порядке.

Что вообще такое обратный DNS?

Обычный DNS работает так: вы вводите имя сайта, а система находит его IP-адрес — это называется прямым разрешением имён. Обратный DNS делает наоборот: у вас есть IP-адрес, и вы хотите узнать, какое доменное имя за ним закреплено. За эту функцию отвечает специальная зона в DNS — она называется in-addr.arpa для IPv4-адресов, и именно в ней хранятся PTR-записи.

PTR расшифровывается как Pointer, то есть «указатель». Если A-запись говорит «у домена example.ru такой-то IP», то PTR-запись говорит обратное: «у этого IP такое-то имя». Настраивается PTR не в DNS-зоне самого домена, а в зоне, которая привязана к IP-адресу — обычно это делает владелец адреса, то есть хостинг-провайдер или дата-центр.

Зачем это нужно почтовому серверу?

Когда ваш сервер отправляет письмо, принимающая сторона — например, крупный почтовый сервис — не просто смотрит на заголовки письма. Она берёт IP-адрес, с которого пришло письмо, и делает обратный запрос: какое имя закреплено за этим адресом? Затем сравнивает результат с тем, что сервер сообщил о себе при установке соединения.

Если PTR-запись отсутствует, указывает на случайный набор символов вроде технического имени провайдера или явно не совпадает с доменом отправителя — это серьёзный сигнал тревоги для антиспам-фильтров. Многие крупные почтовые сервисы попросту отказываются принимать почту с IP-адресов без корректной обратной записи, независимо от того, насколько хорошо настроены SPF, DKIM и DMARC.

Интересный факт: практика проверки обратного DNS появилась ещё в девяностые годы как способ отличить «настоящие» серверы от временных подключений массовых пользователей интернета, которым провайдеры не давали постоянных имён. С тех пор требование осталось практически неизменным и стало одним из базовых критериев доверия к почтовому серверу.

Чем PTR отличается от A и MX-записей?

Если совсем просто: A-запись и MX-запись живут в зоне вашего домена и говорят «вот наш IP» и «вот куда слать почту для нашего домена». PTR-запись живёт в зоне, привязанной к IP-адресу, и говорит «вот какое имя у владельца этого адреса». Это разные направления одной и той же связи, и в идеале они должны совпадать — тогда получается так называемое согласованное прямое-обратное разрешение (FCrDNS), которому доверяют больше всего.

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

Кто должен настраивать PTR — я или провайдер?

Настройкой PTR-записи занимается тот, кому принадлежит IP-адрес. Если вы арендуете виртуальный или выделенный сервер, это делает хостинг-провайдер или дата-центр — обычно по вашей заявке. Вам нужно лишь сообщить, какое имя должно быть привязано к вашему IP: как правило, это доменное имя почтового сервера, например mail.example.ru.

Если вы пользуетесь готовым облачным сервисом, где почта уже настроена и работает через инфраструктуру провайдера, заботиться о PTR отдельно вообще не приходится — за репутацию IP-адресов и корректность обратных записей отвечает сама платформа. В «Клауд АйСи» именно так и устроено: при аренде сервера с почтовым сервисом обратные записи настраиваются на стороне инфраструктуры, и пользователю не нужно вручную разбираться с зонами in-addr.arpa — достаточно верно указать почтовый домен.

Как проверить, настроен ли PTR правильно?

Проверить обратный DNS можно с помощью бесплатных онлайн-сервисов проверки DNS-записей — в поле нужно ввести IP-адрес сервера, а не доменное имя. Также это можно сделать через командную строку с помощью утилиты nslookup или dig, указав опцию обратного поиска.

На что стоит смотреть при проверке:

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

Что делать, если IP-адрес не свой и PTR настроить нельзя?

Такая ситуация типична для общих почтовых шлюзов, некоторых виртуальных серверов с общим пулом адресов или SaaS-сервисов рассылок. Если вы не владеете IP-адресом напрямую, самостоятельно прописать PTR не получится — придётся обращаться к тому, кто этим адресом управляет.

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

Какие ошибки с PTR встречаются чаще всего?

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

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

Как PTR сочетается с SPF, DKIM и DMARC?

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

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