Обратный DNS для почтовых серверов: PTR, FCrDNS и HELO

IP-адресу почтового сервера нужна обратная DNS-запись - PTR, - которая превращает адрес обратно в имя хоста, и это имя хоста должно в прямом направлении разрешаться в тот же адрес. Крупные получатели проверяют это при каждом соединении, а правила Gmail для отправителей требуют этого напрямую. Это же имя сервер должен называть в приветствии HELO/EHLO. Выровняйте эти три вещи - PTR, прямую A-запись и имя в HELO - и вы устраните одну из самых частых причин, по которым почту с собственного сервера отклоняют или кладут в спам. Подвох в том, что PTR-запись находится не в зоне вашего домена. Она принадлежит владельцу IP-адреса, поэтому вы настраиваете её через хостинг-провайдера - или не настраиваете вовсе.

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

Прямой DNS сопоставляет имена с адресами: у mail.example.com есть запись A со значением 203.0.113.25. Обратный DNS работает в другую сторону, и делается это обычным DNS-запросом в особой части дерева.

Для IPv4 адрес записывается задом наперёд, октет за октетом, под in-addr.arpa:

25.113.0.203.in-addr.arpa.   3600  IN  PTR  mail.example.com.

Порядок обращается потому, что DNS читает имена справа налево - от самого общего к самому частному, - а в IP-адресах самая общая часть записана слева. Разворот позволяет делегировать дерево in-addr.arpa по границам сетей: региональный регистратор делегирует 203.in-addr.arpa, затем владелец блока получает 113.0.203.in-addr.arpa, и так далее.

Для IPv6 адрес разворачивается во все 32 шестнадцатеричные цифры, переворачивается по одной полубайтовой цифре и помещается под ip6.arpa. PTR для 2001:db8::25 находится на имени длиной в 32 метки, которое заканчивается на ...8.b.d.0.1.0.0.2.ip6.arpa. Вручную такое никто не набирает; это генерируют утилиты и панели провайдеров.

Кто управляет обратным DNS#

Именно это людей и удивляет. Обратная зона адреса принадлежит тому, кому выделен блок адресов, - обычно вашему хостинг-провайдеру, интернет-провайдеру или облачной платформе. Создать PTR-запись в DNS собственного домена нельзя, потому что имена в in-addr.arpa не входят в ваш домен.

Как её получить, зависит от провайдера:

• Поле в панели управления провайдера - частый вариант на VPS и облачных платформах: вы вводите имя хоста, а провайдер публикует PTR, нередко предварительно проверив, что ваша прямая запись уже указывает на этот адрес.
• Тикет в поддержку - частый вариант для выделенных серверов и небольших хостеров.
• Делегирование обратной зоны на ваши собственные неймсерверы - для организаций со своими блоками адресов. Для блоков меньше /24 RFC 2317 описывает приём на основе CNAME, позволяющий делегировать часть обратной зоны; провайдеры изредка им пользуются.
• Недоступно - для бытовых подключений, общих адресов и некоторых контейнерных платформ. PTR адреса остаётся таким, каким его задал владелец, обычно чем-то безликим вроде 203-0-113-25.static.provider.example.

На практике у каждого адреса одна PTR-запись. Несколько PTR-записей для одного адреса технически возможны и дают непоследовательные результаты, так что не просите о них.

Обратный DNS с прямым подтверждением#

Сама по себе PTR-запись мало что доказывает: любой, кто управляет обратной зоной, может написать в ней mail.google.com. Поэтому получатели проверяют полный круг - это называется обратным DNS с прямым подтверждением (forward-confirmed reverse DNS, FCrDNS) или DNS «по полному кругу»:

1. Получатель видит соединение с 203.0.113.25.
2. Он запрашивает PTR: mail.example.com.
3. Он запрашивает A-запись для mail.example.com: 203.0.113.25.
4. Прямой ответ содержит исходный адрес, значит, имя подтверждено.

Если шаг 3 возвращает другой адрес или вообще ничего, FCrDNS не проходит. Поскольку A-запись под вашим контролем, а PTR - под контролем провайдера, для полного круга нужны обе половины: создайте в своей зоне mail.example.com, указывающий на адрес, и попросите провайдера направить PTR на mail.example.com. Многие панели провайдеров именно поэтому отказываются ставить PTR, пока прямая запись не существует.

Имя в HELO#

Когда ваш сервер подключается к другому почтовому серверу, первое, что он говорит после баннера, - EHLO (или более старое HELO) и своё имя:

220 mx.receiver.example ESMTPEHLO mail.example.com250-mx.receiver.example Hello mail.example.com [203.0.113.25]

RFC 5321 требует, чтобы это имя было полностью определённым доменным именем или, если у хоста нет осмысленного имени, адресным литералом в квадратных скобках. На практике получатели и спам-фильтры проверяют, что:

• Это настоящее FQDN - не localhost, не голое слово вроде server1 и не случайное имя хоста контейнера.
• Оно разрешается в DNS, в идеале в адрес, с которого идёт соединение.
• Оно совпадает с именем из PTR или хотя бы согласуется с ним.

Расхождение между HELO и PTR само по себе у большинства получателей не фатально, но добавляет баллов спама, а некоторые фильтры отклоняют имя в EHLO, которое вообще не разрешается. Чистая схема - когда все три имени одинаковы: имя в HELO, цель PTR и A-запись, указывающая обратно на IP. В Stalwart имя для HELO берётся из настроенного имени хоста сервера - ещё одна причина задать его один раз и правильно с самого начала; см. статью настройка почтового сервера Stalwart.

Что получатели с этим делают на самом деле#

Правила различаются, и крупные провайдеры их меняют, но общая картина постоянна.

Правила Gmail для всех, кто отправляет почту на личные аккаунты Gmail, требуют, чтобы у отправляющего IP была действительная PTR-запись с совпадающей прямой записью; письма с IP без неё отклоняются или ограничиваются по скорости. По IPv6 Gmail ещё строже относится к аутентификации, и сервер с IPv6-адресом, но без IPv6 PTR - частый источник загадочных отказов. Если у вашего сервера есть IPv6-подключение, а PTR для этого адреса настроить нельзя, настройте отправку только по IPv4.

Безликие обратные имена заслуживают отдельного упоминания. Спам-фильтры ищут в PTR шаблоны вроде цифр через дефис, dyn, dhcp, pool или cust, потому что ими помечают жилые и динамические диапазоны. PTR, который формально подтверждается, но выглядит как ip-203-0-113-25.provider.example, всё равно читается как «это не почтовый сервер». В SpamAssassin, старейшем из широко используемых фильтров, есть правила, названные ровно по этим случаям, - RDNS_NONE для соединения без обратного имени и RDNS_DYNAMIC для имени, похожего на динамическое, - и у любого другого фильтра есть их аналоги. Каждое добавляет к баллу немного, а для письма, которое и так на грани по другим причинам, немного - достаточно.

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

Несколько доменов на одном сервере#

PTR не обязан совпадать с доменом из вашего адреса From:. У сервера, который обслуживает почту для example.com, example.org и клиентского shop.example, один IP, один PTR и одно имя в HELO - скажем, mail.example.com, - и это нормально. Получатели проверяют, что отправляющий хост - правильно настроенный почтовый сервер, а не то, что он назван в честь каждого домена, от имени которого отправляет. Каждое письмо к своему домену привязывают SPF, DKIM и DMARC; об этой связи - в статье SPF, DKIM и DMARC простыми словами.

Чего делать не стоит - просить менять PTR под каждый домен или пытаться поставить несколько. Один адрес, одно имя, везде одинаковое.

Обратная ситуация - несколько не связанных между собой служб на одном адресе - как раз та, где с обратным DNS становится неудобно. Адрес, на котором живут сайты, игровые серверы и почтовый сервер разных клиентов, всё равно может нести только один PTR, и назвать он может лишь одного из них. Отчасти поэтому почту с общих адресов обычно отправляют через relay, и поэтому почтовому серверу лучше быть единственным, кто отправляет почту со своего адреса. Если веб-приложение на том же адресе тоже отправляет почту напрямую, оно делит с почтовым сервером PTR и репутацию, и любой отправленный им спам засчитывается обоим.

Проверка обратного DNS#

# The PTR for an address$ dig +short -x 203.0.113.25mail.example.com.# The forward record for that name: should include the same address$ dig +short A mail.example.com203.0.113.25# The same for IPv6$ dig +short -x 2001:db8::25# The short form, which prints both directions$ host 203.0.113.2525.113.0.203.in-addr.arpa domain name pointer mail.example.com.

В Windows Resolve-DnsName 203.0.113.25 возвращает PTR, и nslookup 203.0.113.25 делает то же самое.

Чтобы увидеть, что ваш сервер говорит в HELO, отправьте тестовое письмо на внешний ящик и прочитайте самый верхний заголовок Received:, добавленный получателем, - в нём рядом записаны имя из HELO и результат обратного запроса:

Received: from mail.example.com (mail.example.com. [203.0.113.25])        by mx.google.com with ESMTPS id ...

Первое mail.example.com - это ваш HELO; то, что в скобках, получатель нашёл в обратном DNS. Если они совпадают и адрес правильный, всё готово. Если в скобках стоит что-то вроде unknown или безликое имя провайдера, PTR отсутствует или не направлен на ваш хост.

Как запросить PTR и исправить типичные ошибки#

Когда провайдер всё же предлагает обратный DNS, запрос короткий, но порядок важен.

1. Выберите имя хоста. Используйте имя, которое будет называть ваш почтовый сервер, обычно mail.example.com. Не голый домен и не имя, которое уже указывает куда-то ещё.
2. Сначала создайте прямую запись. Добавьте mail.example.com как запись A (и AAAA, если отправляете по IPv6), указывающую на адрес сервера, и проверьте её снаружи командой dig @1.1.1.1 +short A mail.example.com. Провайдеры, которые проверяют запросы, откажут в PTR, если прямой записи ещё нет.
3. Запросите PTR в поле панели или тикетом, указав точный адрес и точное имя хоста. Для IPv6 укажите полный адрес, с которого отправляет сервер, - у сервера может быть целый диапазон, а использовать он будет только один адрес.
4. Задайте почтовому серверу то же имя хоста, чтобы HELO совпадал.
5. Дождитесь истечения TTL и проверьте через dig -x, затем отправьте тестовое письмо на внешний ящик и прочитайте заголовок Received:.

Ошибки, которые всплывают после этого, немногочисленны и повторяются:

• Точка в конце или опечатка. PTR вида mail.example.com.example.com или mial.example.com ничего не подтверждает. Читайте ответ dig -x по буквам.
• Прямую запись позже поменяли. Кто-то при миграции переносит mail.example.com на новый адрес и забывает, что старый сервер всё ещё отправляет почту. FCrDNS на старом молча ломается.
• Сервер отправляет с другого адреса, чем ожидалось. Машина с несколькими адресами или NAT перед контейнером может подключаться наружу не с того адреса, о котором вы спрашивали. Заголовок Received: у получателя показывает, какой адрес подключился на самом деле; ставьте PTR на него.
• Забыли про IPv6. Настройка IPv4 идеальна, сервер предпочитает IPv6, когда получатель его предлагает, а у IPv6-адреса нет PTR. Либо добавьте его, либо ограничьте исходящую почту протоколом IPv4.
• Имя в HELO - это имя хоста контейнера. Некоторые программы по умолчанию берут системное имя хоста, а в контейнере это случайная строка. Задайте его явно.

Если PTR настроить нельзя#

Это обычная ситуация, и собственная почта на этом не заканчивается.

1. Отправляйте через relay. Ваш сервер передаёт исходящую почту smarthost на порт 587 или 465, а получатель видит IP relay с правильным обратным DNS и сложившейся репутацией. Ваша DKIM-подпись по-прежнему указывает на ваш домен. Настройка описана в статье SMTP relay для исходящей почты.
2. Всё равно принимайте почту напрямую. Обратный DNS важен для отправляющей стороны. Почта, доставляемая вам, от PTR вашего сервера не зависит, так что приём на порту 25 работает в любом случае.
3. Задайте в HELO имя, которое разрешается, даже если PTR безликий. FCrDNS это не исправит, но второй штраф уберёт.

Вариант 1 - стандартный ответ, и заодно он решает проблему блокировки исходящего порта; см. статью порт 25 и блокировка исходящей почты.

FAQ#

Создавать ли PTR-запись в DNS моего домена?

Нет. Обратный DNS адреса принадлежит владельцу адреса, обычно вашему хостинг-провайдеру. В своей зоне вы создаёте прямую A-запись, а провайдера просите прописать PTR для IP.

Должен ли PTR совпадать с моим почтовым доменом?

Нет. Он должен быть настоящим именем хоста, которое разрешается обратно в тот же IP. Один сервер может отправлять почту для многих доменов под одним PTR, например mail.example.com.

Сколько времени нужно, чтобы изменение PTR заработало?

Как и любое изменение DNS - столько, сколько длится TTL старой записи, а провайдеры часто ставят его в сутки. Просите об этом заранее, задолго до начала отправки, а не в тот же день.

PTR правильный, но Gmail всё равно отклоняет почту. Почему?

Проверьте IPv6. Если у сервера есть IPv6-адрес и он отправляет через него, этому адресу нужны собственный PTR и совпадающая AAAA-запись. Затем проверьте SPF, DKIM и DMARC - обратный DNS лишь одно из требований. Полный список - в статье почему письма попадают в спам.

Нужен ли обратный DNS, чтобы принимать почту?

Для приёма вашим сервером - нет. Отправители доставляют почту на ваш MX независимо от вашего PTR. Обратный DNS влияет на то, как получатели оценивают почту, которую отправляете вы.