Блог компании 3v-Hosting
9 мин.
Когда неопытный администратор впервые настраивает собственный почтовый сервер, то всё обычно выглядит почти подозрительно просто. Установил SMTP, открыл 25 порт, прописал DNS и письма улетели. Кажется, что система работает.
Но потом начинают проявляться некоторые странности.
То Gmail отправляет сообщения в spam без объяснений. То Outlook может просто оборвать соединение. А некоторые серверы и вовсе отвечают сообщением "550 5.7.1 Client host rejected: cannot find your reverse hostname".
В этот момент многие впервые сталкиваются с таким понятием как reverse DNS. Эта вещь настолько старая, что разговоры о ней могут казаться чем-то из эпохи dial-up модемов. Но проблема в том, что почтовые серверы до сих пор живут по довольно консервативным правилам, среди которых есть и почти обязательное правило проверки reverse DNS. Без него современная почта работает плохо, нестабильно или вообще никак. Иногда письма доходят, а иногда нет. Ну и неудобным моментом также является то, что многие сервисы даже не сообщают напрямую, что проблема именно в PTR-записи.
Отдельная ирония заключается в том, что отсутствие reverse DNS влияет не только непосредственно на доставку электронных писем, но и способно испортить репутацию IP-адреса, присвоенного почтовому серверу, буквально за несколько часов, даже если сервер новый, чистый и ещё не отправил ни одной массовой рассылки.
Давайте в этой статье разберёмся что же такое reverse DNS, как и где это настраивается и как вообще с этим работать.
Что такое reverse DNS на практике понять довольно просто. Для этого сначала освежим в памяти, что такое обычный DNS.
DNS - это система, которая связывает доменные имена с IP-адресами. Человеку удобно запомнить example.com, а серверы в сети работают с IP-адресами. Поэтому DNS можно себе упрощенно представить как большую таблицу, в одной колонке которой написаны все домены, а во второй колонке - соответствующие им IP адреса.
То есть когда вы вводите адрес сайта в поисковой строке браузера, браузер не знает заранее, где находится этот сайт. Ему нужен IP-адрес сервера, поэтому система отправляет DNS-запрос и спрашивает: "Какой IP у домена example.com?"
В результате, после непродолжительной цепочки проверок, на том или ином DNS сервере (детали опустим) находится запись, где указано примерно следующее:
example.com → 203.0.113.10
Ваш браузер получает IP-адрес и уже после этого подключается к нужному серверу.
Так вот с reverse DNS (rDNS) всё происходит в обратную сторону. Есть IP-адрес, и нужно выяснить, какое доменное имя за ним закреплено. И вот для этого существуют так называемые PTR-записи.
Снова таки, по аналогии, можно представить себе всю систему DNS как телефонный справочник. В одном случае вы знаете имя человека и ищете его номер, а в другом случае у вас есть номер телефона, и вы пытаетесь узнать, кому он принадлежит. Примерно так работает разница между обычным DNS и rDNS.
Вот так выглядит стандартная DNS-запись, когда по имени хоста находится IP-адрес:
mail.example.com → 203.0.113.10
А вот обратное разрешение, когда по IP-адресу определяется имя сервера:
203.0.113.10 → mail.example.com
Быстро проверить наличие PTR-записи для того или иного IP-адреса можно командой:
dig -x 203.0.113.10
или командой:
host 203.0.113.10
И если всё настроено правильно, то в ответе вы увидите доменное имя.
Но на этом проверку заканчивать рано, так как почтовые системы любят, когда прямое и обратное разрешение совпадают между собой. Поэтому после проверки PTR полезно посмотреть и обычную (прямую) DNS-запись:
dig mail.example.com
В идеальной ситуации получается замкнутая цепочка, когда IP указывает на домен, а домен возвращает тот же IP. Именно такую конфигурацию ожидают многие почтовые сервисы и антиспам-системы. Иногда отсутствие этого соответствия вызывает больше проблем, чем полностью отсутствующая PTR-запись.
Чтобы понять значение reverse DNS, стоит ненадолго заглянуть в историю электронной почты.
Первые почтовые системы появились задолго до современных антиспам-фильтров. Интернет был значительно меньше, а большинство серверов принадлежало университетам, исследовательским центрам и крупным организациям. Почтовые узлы общались друг с другом почти полностью основываясь на доверии. И если сервер представился корректно и смог установить SMTP-соединение, то его письма обычно принимались без лишних проверок.
А потом интернет очень быстро вырос. Появились ботнеты, массовые спам-рассылки, взломанные серверы, вредоносное ПО и целые сети заражённых устройств, которые круглосуточно отправляли миллионы писем. В новых условиях почтовым сервисам пришлось искать способы быстро отличать легитимные серверы от подозрительных.
Так постепенно сформировался набор признаков, по которым оценивается репутация почтового узла и Reverse DNS оказался одним из самых простых и одновременно самых эффективных критериев.
Логика здесь довольно приземлённая. Так, если сервер принадлежит компании, организации или обычному системному администратору, то его обычно настраивают полностью, по всем правилам. То есть имеется доменное имя, настроен hostname, прописаны DNS-записи, работает SPF, подключён DKIM. PTR-запись тоже присутствует, потому что она входит в базовый набор почтовой инфраструктуры.
Типичный корректно настроенный почтовый сервер выглядит примерно так:
mail.example.com;
Сразу давайте познакомимся и с этими определениями, они нам пригодятся.
SPF (Sender Policy Framework) - DNS-запись, которая указывает, какие серверы имеют право отправлять почту от имени вашего домена. Позволяет получающему серверу проверить, не подделан ли адрес отправителя.
DKIM (DomainKeys Identified Mail) - механизм цифровой подписи писем. Почтовый сервер подписывает сообщение специальным ключом, а получатель проверяет подпись и убеждается, что письмо не было изменено по пути.
DMARC (Domain-based Message Authentication, Reporting and Conformance) - политика проверки почты, которая объединяет SPF и DKIM. Позволяет владельцу домена указать, что делать с письмами, не прошедшими проверку: принять, отправить в спам или отклонить.
Теперь продолжим.
С подозрительными серверами картина часто совсем другая. Особенно это касается заражённых машин, случайно поднятых SMTP-сервисов или VPS, которые используют исключительно для массовых рассылок.
Для них характерны такие признаки как:
Для антиспам-систем это является набором очень показательных сигналов нелегитимного или вредоносного почтового сервиса.
Конечно, наличие PTR-записи само по себе не гарантирует хорошую репутацию, так как спамер тоже может настроить reverse DNS. Но отсутствие PTR почти всегда выглядит подозрительно. Именно поэтому многие почтовые сервисы начинают проверку сервера с самых простых вещей: существует ли обратная DNS-запись, соответствует ли она имени хоста и не возникает ли противоречий между прямым и обратным разрешением адресов. Именно на этом этапе отсеивается огромное количество мусорного трафика.
Чаще всего проблема проявляется не сразу. Почтовый сервер отправляет сообщения без ошибок, SMTP-сессии завершаются успешно, в логах появляется привычное status=sent. Только вот письма почему-то не доходят до получателей.
Одни письма оказываются в папке "Спам", другие получают низкий рейтинг доверия. Некоторые почтовые сервисы могут вообще отклонить соединение ещё на этапе приёма сообщения и вернуть ошибку:
550 5.7.1 Client host rejected: cannot find your reverse hostname
Особенно внимательно наличие PTR-записи проверяют такие глобальные почтовые сервисы как Gmail, Outlook, Yahoo, а также корпоративные почтовые шлюзы и популярные антиспам-системы.
Самая неприятная ситуация возникает тогда, когда явных ошибок нет. Письмо принято к отправке, сервер отчитался об успешной доставке, но фактическая доставка становится непредсказуемой, когда одни сообщения доходят без проблем, другие попадают под фильтры.
Для обычного сайта это может означать потерю писем из форм обратной связи, уведомлений CRM или сообщений о регистрации пользователей. В прикладном смысле, например для интернет-магазина - это потерянные заказы и обращения клиентов, а значит и потерянные деньги.
У PTR-записей есть одна особенность, которая часто сбивает новичков с толку. Управляет ими не владелец домена, а владелец IP-адреса.
По этой причине добавить PTR через обычную DNS-панель домена у вас не получится. Если вы арендуете сервер у хостинг-провайдера или разместили свой собственный сервер в дата-центре, то настройка reverse DNS выполняется через панель управления этого провайдера или дата-центра, отдельной услугой либо чаще всего по запросу в службу поддержки.
Сама схема выглядит довольно просто.
Сначала для почтового сервера создаётся обычная A-запись:
mail.example.com → 203.0.113.10
После этого для IP-адреса настраивается обратная запись:
203.0.113.10 → mail.example.com
На сервере желательно использовать то же имя в качестве hostname:
hostnamectl set-hostname mail.example.com
В результате получается замкнутая цепочка проверок, когда домен разрешается в IP-адрес, а IP-адрес возвращает тот же домен через PTR-запись.
Такую конфигурацию обычно называют Forward-Confirmed Reverse DNS (FCrDNS). Именно её и ожидают увидеть многие почтовые сервисы при проверке SMTP-соединений. Чем меньше расхождений между hostname, PTR-записью и DNS-записями домена, тем выше уровень доверия к почтовому серверу.
У разных хостинг-провайдеров механизм настройки reverse DNS может отличаться.
Где-то PTR можно изменить самостоятельно через панель управления в личном кабинете, а где-то, в том числе в 3v-Hosting, настройка выполняется по запросу клиента в службу поддержки.
Для этого обычно требуется указать:
После обновления DNS изменения обычно начинают работать в течение нескольких минут или часов.
Также важно понимать, что PTR почти всегда привязывается только к одному домену, то есть один IP - один основной reverse DNS hostname.
На обычном виртуальном хостинге вопросы, связанные с почтой, чаще всего уже решены провайдером. Почтовые серверы настроены, PTR-записи прописаны, репутация IP-адресов поддерживается централизованно.
А вот в случае с VPS-серверами ситуация другая. Администратор получает практически полный контроль над своим сервером, а вместе с ним и ответственность за настройку почтовой инфраструктуры.
Поэтому нередко возникает сценарий, когда Postfix или Exim вроде-бы уже работают, письма отправляются, а про PTR-запись никто даже не вспомнил. В таких случаях проблема может обнаружиться далеко не сразу. Просто однажды, например, перестают приходить уведомления из WordPress, сообщения из CRM начинают попадать в спам, а некоторые получатели вообще не видят отправленные письма.
Есть ещё один момент, который часто вызывает вопросы. Даже если PTR настроен правильно, исходящая почта всё равно может не работать. И это не обязательно ошибка или недоработка провайдера. Более того, подобная практика давно стала стандартом в отрасли.
Многие VPS- и облачные провайдеры ограничивают исходящие SMTP-соединения, особенно на новых серверах и новых аккаунтах. Причина довольно проста: большая часть мирового спама отправляется именно со взломанных серверов и виртуальных машин. Если разрешить любому новому VPS без ограничений отправлять почту на весь интернет, то IP-подсеть очень быстро окажется в чёрных списках.
По этой причине провайдеры вводят дополнительные проверки, временные ограничения или требуют отдельный запрос на разблокировку почтовых портов. Такая политика защищает не только инфраструктуру провайдера, но и обычных клиентов, которые используют её для легальных задач.
Поэтому для полноценной работы почтового сервера обычно требуется сразу несколько условий: корректный PTR, настроенные SPF, DKIM и DMARC, а также отсутствие ограничений на исходящие SMTP-соединения со стороны площадки, где размещён VPS. Если один из этих элементов отсутствует, проблемы с доставкой почты вполне возможны даже при внешне правильной конфигурации сервера.
Но PTR-записи нужны не только для проверки отдельного почтового сервера. Они давно стали одним из инструментов борьбы со спамом на уровне дата-центров, хостинг-провайдеров и крупных почтовых сервисов.
Проблема в том, что значительная часть спама в интернете отправляется не с каких-то специальных серверов злоумышленников, а с обычных VPS. Сервер арендуется за несколько минут, на него устанавливается почтовое ПО, после чего начинается массовая рассылка. Иногда такие серверы даже не принадлежат спамерам напрямую - это могут быть взломанные виртуальные машины или заражённые сайты.
Почтовые системы давно научились искать характерные признаки подобных узлов и один из них как раз отсутствие PTR-записи или её низкое качество.
Если сервер пытается отправлять тысячи писем и при этом не имеет корректного reverse DNS, это выглядит подозрительно ещё до анализа содержимого сообщения. В некоторых случаях достаточно нескольких подобных сигналов, чтобы IP-адрес сервера, с которого отправлялись письма получил негативную репутацию.
Дальше механизм начинает работать довольно жёстко.
Сначала письма с этого сервера начинают чаще попадать в спам. Затем IP может оказаться в одной из репутационных баз или DNSBL-списков, например в Spamhaus SBL. После этого другие почтовые системы начинают автоматически проверять такой адрес и снижать уровень доверия к сообщениям. В тяжёлых случаях новые подключения от этого IP могут отклоняться ещё до передачи письма.
Отдельное внимание уделяется самим именам хостов. Например, такие PTR-записи:
ip-203-0-113-10.provider.local
или
vps123.hosting.internal
обычно создаются автоматически при установке сервера и мало что говорят о его владельце.
Для почтовых систем гораздо убедительнее выглядят имена, связанные с реальным доменом:
mail.example.com smtp.example.com mx1.example.com
Такой hostname показывает, что сервер не просто получил IP-адрес и начал отправлять почту, а был настроен администратором как часть полноценной почтовой инфраструктуры.
Конечно, сам по себе PTR не спасёт от попадания в чёрные списки, так как если с сервера идёт спам, то его всё равно рано или поздно заблокируют. И поделом. Но отсутствие PTR или случайное имя хоста часто становятся первым тревожным сигналом, из-за которого доверие к IP начинает снижаться ещё до появления реальных жалоб на рассылки и в таких случаях провайдер может снова ограничить исходящий почтовый трафик или вовсе отказать в обслуживании, если IP-адрес вашего сервера постоянно попадает в спамлисты.
Похожая ситуация встречается после получения нового VPS. Администратор настраивает PTR, SPF, DKIM и остальные записи, но письма всё равно доставляются плохо. Причина может скрываться в истории самого IP-адреса. IPv4-адреса давно стали дефицитным ресурсом, поэтому провайдеры постоянно перераспределяют их между клиентами. Если предыдущий владелец использовал сервер для спам-рассылок или его IP успел попасть в репутационные базы, последствия могут сохраняться ещё долгое время после передачи адреса новому клиенту. В таких случаях приходится не только настраивать почтовую инфраструктуру, но и заниматься восстановлением репутации IP или запрашивать его замену у провайдера. Иногда проблема оказывается шире и затрагивает целый диапазон адресов или даже всю сеть дата-центра. Поэтому наличие PTR стоит рассматривать как обязательное условие для работы почты, но далеко не как единственную проверку, которую проходят современные почтовые сервисы.
Во времена, когда антиспам-фильтры были гораздо проще, наличие PTR-записи уже считалось хорошим признаком корректно настроенного сервера. Но сейчас этого явно недостаточно.
Современные почтовые системы оценивают не какой-то один параметр, а всю инфраструктуру целиком. Проверяется домен, IP-адрес, история отправки, DNS-записи, настройки SMTP и множество косвенных признаков, по которым можно понять, насколько сервер заслуживает доверия. По сути, PTR сегодня находится примерно в том же положении, что и HTTPS для сайта. Его наличие никого не удивляет, потому что это базовое требование. А вот отсутствие почти сразу вызывает вопросы.
Минимальная конфигурация почтового сервера обычно включает корректную PTR-запись, hostname, SPF, DKIM, DMARC, валидные MX-записи, TLS для SMTP и чистую репутацию IP-адреса. Всё это работает как единая система и если один из элементов отсутствует, то вероятность проблем с доставкой писем начинает расти.
По этой причине при диагностике почтовых проблем всегда полезно смотреть на картину целиком. Например, сервер может иметь идеальный PTR, но находиться в чёрных списках. Или наоборот - обладать безупречной репутацией IP, но использовать некорректный hostname.
Кстати, именно hostname часто становится источником проблем у начинающих администраторов.
Вот вы настроили сервер, запустили сайт, установили SSL, настроили Postfix или любой другой почтовый сервис, опубликовали SPF записи в DNS и т.д. и т.п. На первый взгляд вы всё сделали правильно. Но потом выясняется, что сервер по-прежнему использует имя вроде:
ubuntu localhost vps123
или вообще не имеет PTR-записи.
При этом почта может работать частично. Письма на один адрес доходят, на другой попадают в спам, а третий почтовый сервер полностью отклоняет соединение. Такая ситуация способна оставаться незамеченной неделями, потому что тестовая отправка на собственный Gmail часто проходит успешно.
Проверить базовые настройки можно довольно просто. Для проверки PTR достаточно выполнить в консоли команду:
dig -x YOUR_IP
или:
nslookup YOUR_IP
После этого полезно проверить прямую DNS-запись домена и убедиться, что она указывает на тот же IP-адрес. Затем стоит посмотреть hostname сервера:
hostname -f
В идеальной конфигурации hostname, PTR-запись и DNS-записи домена должны ссылаться друг на друга без противоречий - об этом мы уже писали выше более подробно.
Почта остаётся одной из самых консервативных технологий интернета. Многие механизмы проверки были придуманы десятилетия назад и продолжают использоваться до сих пор в логике "работает - не трогай". И Reverse DNS как раз является одним из таких механизмов. Конечно, он давно перестал быть единственным критерием доверия к почтовому серверу, но без него полноценная почтовая инфраструктура всё ещё выглядит незавершённой и вызывает сомнения.
Технически можно. Но на практике многие почтовые сервисы относятся к таким письмам с недоверием, поэтому они чаще попадают в спам или получают низкий рейтинг доверия.
Почти. Reverse DNS - это механизм поиска доменного имени по IP-адресу, а PTR - это конкретная запись, которая обеспечивает его работу. Хотя в повседневной практике эти термины часто используют как синонимы.
Обычно от нескольких минут до нескольких часов. Иногда изменения распространяются дольше из-за всякого рода DNS-кэшей у провайдеров и почтовых сервисов.
Для работы сайта - обычно не нужен. А вот для почтового сервера - почти всегда нужен, если нужна нормальная доставляемость писем.
Потому что, как мы выяснили, PTR - это лишь одна из множества проверок. Gmail дополнительно оценивает SPF, DKIM, DMARC, репутацию IP-адреса и историю отправки почты.
Зависит от провайдера. Где-то PTR можно изменить через панель управления, а где-то для этого нужно обратиться в службу поддержки.
Итак, PTR-запись относится к тем настройкам, о которых обычно вспоминают только после появления проблем с почтой. Она не влияет на производительность сервера, не делает сайт быстрее и никак не меняет работу приложений. Зато именно по таким мелочам почтовые системы оценивают, насколько можно доверять серверу.
Сегодня reverse DNS входит в число базовых требований для любой почтовой инфраструктуры. Отсутствие PTR не обязательно приведёт к немедленному отказу в доставке, но почти наверняка создаст лишние проблемы и снизит доверие к отправляемым сообщениям.
Если сервер используется для корпоративной почты, отправки уведомлений, работы CRM, WordPress или любого другого программного обеспечения, которое рассылает письма, то проверка PTR должна быть такой же стандартной процедурой, как и настройка SPF, DKIM или TLS-сертификата.
Почтовая система интернета до сих пор строится на репутации и доверии. И очень часто это доверие зависит от настроек, которые пользователи никогда не увидят, а администраторы вспоминают о них только тогда, когда письма перестают доходить до адресатов.
Неопытному пользователю, которому по тем или иным причинам впервые пришлось арендовать виртуальный или выделенный сервер, навигация и работа в среде Linux могут...
При выборе между VPS и облачным хостингом очень важно понимать преимущества, которые может предоставить виртуальный частный сервер. В этой статье представлены п...
Proxy и VPN часто путают, но это разные инструменты. Разбираем, как они работают, в чём разница, когда использовать каждый и как правильно применять их в реальн...
Как перенести сайт WordPress на VPS без Docker или Kubernetes. Пошаговое руководство с использованием Nginx, MariaDB, HTTPS, советами по оптимизации и распростр...
Узнайте, что означает ошибка HTTP 504 Gateway Timeout, почему она возникает в Nginx, Cloudflare, Docker и Kubernetes, и как правильно диагностировать и устранит...
SFTP для безопасной передачи файлов: настройка в Linux, SSH-ключи, команды и рекомендации. Узнайте, как настроить, использовать и защитить передачу файлов на ва...
