Defaults.Exposed › Исправления › Обратный DNS (PTR)

Как исправить Обратный DNS (PTR)

Обратный DNS — это удостоверение сервера, отправляющего почту вашего бизнеса. Когда принимающий сервис вроде Gmail или Microsoft 365 проверяет, кто стоит за отправляющим адресом, и получает имя, которое подтверждается, ваша почта выглядит легитимно. Когда удостоверения нет — или имя и номер не совпадают, — ваши совершенно настоящие счета и предложения считаются подозрительными и тихо уходят в спам или отклоняются.

Главное для вашего бизнеса: Ваши счета, предложения и ответы клиентам тихо оседают в спаме или вообще не доходят — поэтому сделки буксуют, платежи приходят с опозданием, а клиенты думают, что вы их проигнорировали, и ничего из этого не проявляется как ошибка, которую вы бы заметили.

Во что это может вам обойтись

Вы отправляете предложение горячему клиенту, оно падает к нему в спам, и он уходит к конкуренту, который «хотя бы ответил», — а вы даже не знали, что письмо не дошло.
Счета клиентам исчезают в спаме, платежи приходят с задержкой в недели, и страдает ваш денежный поток, потому что письмо никто не видел.
Клиент жалуется, что вы ему не ответили, — а вы ответили; его почтовый сервис тихо выбросил ваш ответ, потому что ваш отправляющий сервер не смог доказать, кто он.
Ваш домен проходит проверку безопасности нового клиента по всему остальному, а потом помечается, потому что у вашего почтового сервера нет надлежащей идентичности, — мелочь, из-за которой вы выглядите небрежно.
Вы перешли на дешёвый VPS или новое приложение для рассылок и счетов, и в одночасье ваша доставляемость падает — потому что у этого нового отправляющего сервера нет удостоверения обратного DNS, и крупные сервисы ему больше не доверяют.

Почему это важно. Каждый крупный почтовый сервис проверяет идентичность сервера, отправляющего вашу почту, и делает это на каждом сообщении. Если сервер не может доказать, кто он, — или если его имя и номер противоречат друг другу, — ваша настоящая деловая почта обрабатывается так, будто может оказаться спамом. Вы теряете ответы, платежи и доверие, и поскольку ничего не отскакивает, обычно так и не узнаёте почему.

Коротко

Когда ваш бизнес отправляет письмо, оно уходит с почтового сервера, а у каждого сервера в интернете есть числовой адрес — его IP. Обратный DNS (запись «PTR») — это удостоверение сервера: оно позволяет любому, кто видит номер, узнать надлежащее имя за ним, вроде mail.вашакомпания.com.

Крупные принимающие сервисы — Gmail, Microsoft 365, Yahoo — проверяют это удостоверение на каждом вашем сообщении. Сервер, который может себя назвать и у которого имя и номер согласуются друг с другом, выглядит как легитимный почтовый сервер. Сервер без удостоверения или с несовпадающим удостоверением выглядит ровно как анонимные, одноразовые машины, которыми пользуются спамеры. Поэтому ваши настоящие счета и предложения начинают каждый разговор под подозрением — и многие из них проигрывают.

Досадно то, что ничто не сообщает вам об этом. Нет ни отскока, ни ошибки. Ваша почта просто тихо работает хуже, чем могла бы.

Чем это может вам обойтись

Вот повседневные способы, которыми отсутствующая или несовпадающая запись обратного DNS превращается в утекающие деньги и доверие. Мы никогда не называем настоящий бизнес — это закономерности, которые мы видим по данным.

Предложение, которое не дошло. Вы отправляете подробное предложение клиенту, попросившему его тем же утром. Его сервис не может подтвердить ваш отправляющий сервер и роняет письмо в спам. В спам он не лезет. К обеду он уже взял предложение конкурента — то, что «хотя бы пришло». Вы списываете это на медленного лида; на деле ваше письмо никто не видел.
Счёт в пустоте. Вы выставляете счёт хорошему клиенту. Он попадает в спам. Через тридцать дней вы напоминаете о просроченном платеже не по вине клиента — и вот неловкий разговор, натянутые отношения и кассовый разрыв, которого можно было полностью избежать.
«Вы не ответили». Клиент раздражён, что вы проигнорировали его вопрос. Вы не игнорировали — вы ответили в тот же день. Его почтовый сервис тихо выбросил ваш ответ, потому что отправляющий сервер выглядел неблагонадёжно. Вы выглядите непрофессионально за то, что на самом деле сделали правильно.
Самодельный отправляющий сервер, тихо отравивший всё. Чтобы сэкономить, ваша почта (или хотя бы рассылки и автоматические счета) начала уходить через дешёвый VPS или новое приложение рассылки. У этого сервера никогда не было удостоверения обратного DNS. В одночасье доставляемость просела по всем фронтам — и поскольку нет сообщения об ошибке, до причины докопались только спустя месяцы.
Флаг на проверке безопасности. ИТ-служба более крупного клиента при подключении проводит рутинную проверку вашего домена. Всё остальное в порядке, но у вашего почтового сервера нет надлежащей идентичности. Это мелкий технический момент, но он читается как небрежность — и вот вы чините его под давлением сроков или оправдываетесь, тогда как домен конкурента только что прошёл всё гладко.

Нить всех этих историй: расходы ложатся на вас, это невидимо, пока происходит, и исправление бесплатно.

Что это на самом деле

Обычный DNS превращает имя в номер: вы вводите вашакомпания.com, и DNS возвращает IP-адрес для подключения. Обратный DNS делает обратное — превращает номер обратно в имя. По IP 203.0.113.10 обратный поиск (запись «PTR») отвечает mail.вашакомпания.com.

Почему это важно получателям: когда ваш почтовый сервер подключается к Gmail для доставки сообщения, Gmail видит подключающийся IP. Первое, что делает серьёзный почтовый фильтр, — спрашивает «что это за машина?» — выполняя обратный поиск по этому IP. У настоящего делового почтового сервера есть ответ (mail.вашакомпания.com). У одноразовой спам-машины его обычно нет, или есть общее имя, выданное провайдером, вроде host-203-0-113-10.someisp.net. Так что наличие и качество удостоверения — один из самых первых сигналов доверия, применяемых к вашей почте, ещё до того, как до SPF, DKIM или содержимого сообщения вообще доходит дело.

Проверяется почтовый сервер, а не ваш сайт. На этом спотыкаются. Адрес вашего сайта часто стоит за CDN или прокси (вроде Cloudflare) и никогда не будет иметь совпадающего удостоверения — и это нормально, потому что обратный DNS для почты касается IP MX-почтового сервера, совершенно отдельной машины. Эта проверка корректно ищет основной почтовый сервер вашего домена (MX-запись с наименьшим приоритетом), разрешает его в IP и проверяет удостоверение этого IP.

Половина, которую большинство настроек делает неверно: совпадение должно быть в обе стороны. Наличия имени самого по себе недостаточно. Gmail и другие крупные фильтры делают кое-что строже, называемое forward-confirmed reverse DNS (FCrDNS):

Найти IP → получить имя (например, mail.вашакомпания.com).
Теперь найти это имя обратно → оно должно разрешиться в тот же IP, с которого вы начали.

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

Именно так эта проверка это и оценивает:

Подтверждённое в обе стороны (FCrDNS): IP называет хост, и этот хост указывает обратно на тот же IP. Полный балл — это корректная конфигурация, и именно ей доверяют получатели.
Удостоверение есть, но не подтверждается: запись PTR существует, но имя не разрешается обратно в IP почтового сервера. Только частичный зачёт — выглядит настроенным, но крупные фильтры не доверяют полностью.
Удостоверения нет вовсе: на IP почтового сервера нет записи PTR. Без зачёта, и цена для доставляемости реальна.

Замечание о весе: в методологии это оцениваемая проверка почтовой безопасности (ценой 25 баллов, пункт приоритета P2). Это не самая весомая почтовая проверка — таковы SPF и DMARC, которые останавливают прямую подделку, — но это настоящая, оцениваемая часть вашего почтового статуса и одна из немногих, что зависит от того, правильно ли всё сделал ваш провайдер, а не вы. Если вы отправляете только через Google Workspace или Microsoft 365, вы почти наверняка её уже проходите; не проходят те, кто отправляет через свой или сторонний сервер.

Как выглядит «хорошо»: у IP вашего основного почтового сервера есть запись PTR, указывающая на настоящее имя хоста, которым вы владеете, и это имя разрешается прямо обратно в тот же IP — обе стороны согласуются (FCrDNS подтверждён).

Как это исправить (бесплатно, ~10 минут чьего-то времени)

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

Шаг 1 — Найдите IP отправляющего почтового сервера. Определите основной MX-хост домена (почтовый сервер с наименьшим числом приоритета) и разрешите его в IP-адрес:

dig MX вашакомпания.com        # найти основной (с наименьшим приоритетом) MX-хост
dig A mail.вашакомпания.com    # разрешить этот хост в его IP

Этот IP и есть тот, которому нужно удостоверение. Не используйте IP сайта — это другая машина, часто за CDN, который никогда не совпадёт.

Шаг 2 — Попросите владельца IP установить запись PTR. Обратный DNS живёт у того, кто контролирует блок IP, поэтому запрос идёт к:

Google Workspace / Gmail: управляется автоматически для собственных почтовых серверов Google — если домен, отправляющий только через Google, почему-то показывает провал, поднимите вопрос в поддержке Google. (На практике эти проходят.)
Microsoft 365: аналогично управляется автоматически для серверов Microsoft.
Самостоятельно поднятый или VPS почтовый сервер: откройте тикет у хостинг-провайдера или дата-центра с просьбой установить PTR (обратный DNS) для вашего IP на имя вашего почтового хоста. Большинство провайдеров выводят это в панели управления под «Reverse DNS», «rDNS» или «PTR». В крупных облаках это настройка из одного поля (например, AWS требует короткую форму запроса, чтобы включить rDNS на Elastic IP; большинство VPS-хостингов позволяют задать это мгновенно).
Стороннее приложение рассылки (рассылки / счета / CRM): если оно отправляет со своих общих серверов, обратным DNS занимается провайдер — вам нечего настраивать, и для этого трафика можно это игнорировать. Если оно отправляет с выделенного IP, который вы у них купили, попросите установить PTR на нём.

Сообщите им нужную запись, например: 203.0.113.10 → mail.вашакомпания.com.

Шаг 3 — Сделайте так, чтобы подтверждалось в обе стороны (этот шаг большинство упускает). Имя хоста в PTR должно также разрешаться обратно в тот же IP через обычную A-запись, которую вы контролируете в собственном DNS. Итак:

PTR гласит 203.0.113.10 → mail.вашакомпания.com (это ставит ваш провайдер).
A-запись гласит mail.вашакомпания.com → 203.0.113.10 (это ставите вы в своём DNS, например Cloudflare → DNS → добавить запись A, Name mail, content 203.0.113.10).

Обе стороны должны указывать друг на друга. Только тогда это подтверждено в обе стороны и полностью доверенно.

Шаг 4 — Перепроверьте свой домен. Убедитесь, что почтовый сервер теперь показывает forward-confirmed reverse DNS и проверка проходит. Изменения DNS распространяются за время от нескольких минут до пары часов.

Частые ошибки

Удостоверение на IP сайта вместо почтового сервера. Обратный DNS для почты касается MX-сервера. PTR на адресе вашего сайта/CDN ничего не даёт доставляемости — удостоверение получает не та машина.
Остановка на «PTR существует». Имя само по себе даёт лишь частичное доверие. Если оно не разрешается обратно в тот же IP, строгие фильтры (Gmail, M365, Yahoo) не доверяют полностью. Всегда завершайте двустороннее подтверждение (Шаг 3).
Забытая A-запись после того, как провайдер поставил PTR. Провайдер ставит обратную половину; прямую половину вы должны поставить в своём DNS. Люди делают одно и думают, что готово.
Запрос не той стороне. Отправка запроса регистратору домена или DNS-хосту вместо владельца IP приносит ответ «мы не можем этого сделать» — потому что они действительно не могут. Запрос должен идти к владельцу IP.
Общие имена хостов провайдера. PTR вроде host-203-0-113-10.someisp.net технически существует, но ничего не даёт вашему бренду или доверию. Используйте настоящее имя хоста на собственном домене, подтверждающееся в обе стороны.

Как это вписывается

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

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

Я не технический специалист — смогу ли я справиться сам?

Обычно нет, и это нормально. В отличие от большинства почтовых настроек, эта меняется не в DNS вашего собственного домена, а тем, кто владеет интернет-адресом (IP) вашего почтового сервера, то есть вашим почтовым или хостинг-провайдером. Ваша задача — просто переслать им раздел «Как это исправить». На их стороне это быстрое изменение, и оно бесплатно.

Если я использую Google Workspace или Microsoft 365, я уже защищён?

Почти наверняка да — оба управляют обратным DNS автоматически для своих почтовых серверов, так что домен, отправляющий только через них, проходит это без всяких действий с вашей стороны. Если наша проверка всё же помечает его, это почти всегда значит, что часть почты уходит через другой сервер (ваш собственный, дешёвый VPS или стороннее приложение рассылки), и именно у этого сервера нет удостоверения. Раздел с исправлением объясняет, к кому обращаться.

Может ли это исправление сломать мою почту?

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

В чём разница между этим и SPF, DKIM и DMARC?

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

У нас есть запись обратного DNS, но проверка всё равно не проходит полностью — почему?

Потому что наличия имени недостаточно; имя должно подтверждаться в обе стороны. Удостоверение гласит, что сервер называется, скажем, mail.вашакомпания.com, — но Gmail затем ищет это имя и ожидает, что оно укажет ровно обратно на тот же IP. Если нет (или указывает куда-то ещё), сервисы считают это неподтверждённым и доверяют лишь наполовину. Это двустороннее совпадение называется forward-confirmed reverse DNS, и именно его большинство настроек упускает.

Исправление правда бесплатно или это платный апселл?

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