Как проверить PTR, прямой DNS и имя SMTP-отправителя

Для исходящей почты проверьте публичный IP, его PTR и прямую A/AAAA-запись имени, которое возвращает PTR. Затем отдельно выясните, какое имя MTA отправляет в EHLO. Я покажу, где проходят границы требования RFC, как проверить Postfix и что просить у владельца IP-адреса.

Что именно связывают PTR и EHLO

Для начала выпишите три значения: публичный IP, с которого MTA отправляет письмо; имя, которое возвращает PTR-запрос для этого адреса; и A/AAAA-запись этого имени. В типовой аккуратной конфигурации прямой запрос возвращает тот же исходящий IP. Отдельно проверьте EHLO: так SMTP-клиент представляется принимающему серверу. PTR отвечает на вопрос «какое имя связано с адресом», а EHLO — «как назвался SMTP-клиент». Это разные части разговора, хотя их удобно свести к одному устойчивому имени.

Здесь часто пересказывают RFC 5321 слишком смело. Стандарт не требует, чтобы EHLO буквально совпадал с PTR. Сервер-получатель может сверить аргумент EHLO с адресом клиента, но один только провал этой сверки не даёт ему права отклонить письмо. У отдельных получателей есть собственные требования к обратному и прямому DNS, поэтому я настраиваю согласованную связку имени и адреса как практическое условие, а не выдаю её за универсальный запрет протокола. Если почту ведёт подрядчик, обсудите устройство корпоративной почты до смены отправляющего IP.

Если PTR для 192.0.2.25 возвращает mail.example.com, сделайте обычный прямой запрос ровно к этому имени и сравните ответ с тем же публичным адресом. Так проверяется обратная связка DNS, которую часто называют forward-confirmed reverse DNS. Она полезна для почтовой идентичности, но не доказывает, кто запустил сервер, и не заменяет подпись письма. На диаграмме это две отдельные стрелки: IP к имени и имя обратно к адресу.

Кто меняет PTR и что написать в заявке

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

В заявке укажите адрес, который реально выходит в интернет при отправке, желаемое полное имя узла и просьбу выставить для него PTR. Перед этим убедитесь, что вы контролируете прямую зону и можете направить A-запись на этот IPv4 или AAAA на нужный IPv6. Если сервер работает за NAT, адрес виртуальной машины может отличаться от публичного адреса получателя — PTR настраивают для последнего. MX отвечает за то, куда другие серверы доставляют почту вашему домену; он не исправляет PTR исходящего соединения. Для этой проверки полезно выбрать VPS для почты с понятным управлением публичными адресами.

В заявке удобно написать без двусмысленности: «Исходящая почта уходит с публичного IP … . Просьба установить для него PTR … и сообщить, делегирована ли нам обратная зона». Если используется несколько адресов или одновременно IPv4 и IPv6, перечислите их все: сервер может выбирать маршрут не так, как вы ожидаете. Не заказывайте PTR для панели управления, адреса веб-сайта или имени MX, пока не подтвердили, что именно с этого IP устанавливается исходящее соединение. Здесь помогает журнал MTA или сетевой маршрут, а не догадка по DNS-записям домена. Для самостоятельной почты я предпочитаю закреплённый публичный IP: при смене адреса заново проверяют PTR, прямое разрешение и фактический маршрут. Это эксплуатационная рекомендация, а не отдельное требование SMTP; на динамическом адресе возможность управлять обратной зоной обычно остаётся у провайдера.

Условный пример: офис на 22 рабочих места

Разберу условную «Геоотметку» из поля company: московская инженерная компания, 22 рабочих места и собственная почта на VPS. Для безопасного примера возьмём адрес из документационного диапазона 192.0.2.0/24 и имя mail.example.com. Допустим, исходящая сессия идёт с 192.0.2.25, PTR возвращает стандартное имя хостинга, а в EHLO сервер передаёт mail.example.com. Это несогласованная настройка, которую стоит исправить и проверить. Но из неё нельзя честно вывести, что компания взломана, что письмо непременно окажется в спаме или что именно PTR был единственной причиной отказа.

Я бы поручил владельцу адреса установить PTR на выбранное имя, проверил A/AAAA для mail.example.com и сверил конфигурацию MTA. После этого отправил бы контрольное письмо и сохранил ответ принимающего сервера. Чистая обратная и прямая записи подтверждают только состояние DNS; они не подтверждают доставку во «Входящие». Если отказ останется, понадобятся SMTP-ответ получателя, очередь и журналы отправки, а также отдельная проверка аутентификации и репутации IP. Правильный результат этого этапа — предсказуемая идентичность исходящего узла, а не обещание победить любой фильтр.

В условном сценарии после исправления ожидаемая картина такая: обратный запрос к отправляющему адресу возвращает mail.example.com, прямой запрос к этому имени возвращает тот же публичный адрес, а настроенное имя EHLO не выглядит случайной строкой. Если все три проверки прошли, зафиксируйте результат и переходите к SMTP-ответу. Не приписывайте исправлению больше, чем оно сделало: оно привело в порядок DNS-идентичность узла, но само по себе не лечит ошибку авторизации, неверный SPF или низкую репутацию отправляющего IP.

• IP отправки: 192.0.2.25
• PTR: mail.example.com
• A/AAAA: адрес отправки
• EHLO: имя из конфигурации MTA

Как проверить DNS и имя исходящего клиента

Сначала запросите DNS с машины вне локальной сети или у внешнего резолвера. Для IPv4 команда dig -x делает обратный PTR-запрос; прямые запросы проверяют полученное имя. В примере ниже 192.0.2.25 — тестовый адрес, его заменяют на реальный публичный IP отправки. Для IPv6 проверьте соответствующий адрес и AAAA-запись. Если +short ничего не показал, откройте полный ответ и проверьте статус DNS и имя резолвера: пустая строка не отличает отсутствующую запись от ошибки или недоступного ответчика.

На Postfix проверьте исходящее имя клиента командой postconf myhostname smtp_helo_name. У smtp_helo_name значение по умолчанию — $myhostname; параметр можно переопределить отдельно. Поэтому советы править mydomain «наугад» здесь не годятся: сначала смотрите фактическое значение, затем меняйте его осознанно и проверяйте отправку. Для другой почтовой программы найдите её параметр исходящего HELO/EHLO в документации именно вашей версии. Входящая проверка на собственном порту 25 показывает баннер и то, как сервер принимает введённый вами EHLO; она не показывает, каким EHLO ваш MTA представляется чужому MX. Чужая проверка не становится вашей исходящей сессией только потому, что вы набрали команду в telnet.

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

dig -x 192.0.2.25 +short
dig mail.example.com A +short
dig mail.example.com AAAA +short
postconf myhostname smtp_helo_name

Замените адрес и имя на свои. Последняя строка — для Postfix; она показывает параметры локального MTA, а не доказывает, что конкретный маршрут отправки не переопределён отдельно. При необходимости сравните обычный и полный ответ dig, чтобы видеть TTL и DNS-статус. Сохраните вывод до и после правки — короткое сравнение полезнее фразы «вроде уже поменялось».

• Публичный IP, фактически выбранный для отправки
• PTR для этого адреса
• A/AAAA для имени из PTR
• Исходящее имя Postfix: smtp_helo_name

Почему корректный PTR не обещает доставку

Обратная запись помогает получателю связать отправляющий IP с именем узла. Некоторые почтовые сервисы прямо требуют валидные прямую и обратную записи; при их отсутствии или несовпадении они могут временно ограничить отправку, отклонить сообщение или поместить его в спам. Это правило конкретного получателя, а не поведение всей почты в интернете. Если один адресат возвращает отказ, сохраните полный код и текст ответа: они точнее, чем догадки по одному PTR. Когда проверяю IP, я отдельно смотрю репутацию почтового адреса, но не подменяю этим диагностику SMTP.

SPF, DKIM и DMARC решают другие задачи и не «включаются после PTR» в универсальном порядке. Проверяйте каждый результат отдельно, включая TLS, доступность исходящего SMTP и фактический ответ принимающей стороны. PTR не очищает репутацию адреса, не исправляет чужую конфигурацию и не даёт права объявлять IP безопасным. Если проверки DNS прошли, а доставка всё ещё хромает, сверьте SPF, DKIM и DMARC и продолжайте по диагностическим данным. Один ответ DNS не объяснит весь почтовый маршрут; у фильтра обычно хватает других причин.

Если тестируете SMTP вручную, подключение к своему серверу на TCP-порту 25 начинает с ответа 220 от сервера; потом уже клиент передаёт EHLO и получает ответ вроде 250. Так можно проверить баннер, доступность команды и объявленные расширения. Но введённое вами EHLO test.example — это имя проверяющего клиента, а не имя, которое ваш Postfix отправляет при исходящей доставке. Чтобы увидеть фактическую исходящую идентичность, смотрите конфигурацию MTA и данные принятого тестового письма на стороне получателя. Для TLS отдельно проверяют объявление STARTTLS и успешность рукопожатия; открытый ретранслятор тоже относится к отдельной проверке SMTP, а не к PTR.

Что перепроверить после изменения записи

Не назначайте DNS срок «один час» или «сутки»: единого таймера обновления для всех резолверов нет. Новое значение должен опубликовать тот, кто управляет обратной зоной; кэши обновятся по своим TTL. Сверьте ответ авторитетного сервера, если знаете его адрес, затем проверьте результат через несколько внешних рекурсивных резолверов. Если ответы расходятся, сохраните их и уточните у провайдера, опубликована ли запись и какой TTL действует. Не повторяйте правку вслепую каждые пять минут: сначала выясните, где находится старое значение — в зоне или в кэше.

После обновления пройдите всю цепочку заново: публичный IP фактической отправки, PTR, A/AAAA, исходящий smtp_helo_name и реальное письмо с ответом получателя. Если у сервера есть IPv4 и IPv6, проверьте оба пути: MTA может выбрать для доставки не тот адрес, который вы проверяли вручную. Затем отдельно разберите очереди, TLS, аутентификацию и репутацию. Короткий список экономит время: согласованный DNS — нужная основа, но не вся диагностика. Бэкап DNS-проверки тоже прост: сохраните исходные ответы и время запроса, чтобы сравнивать факты, а не память.

Я не начинаю с вывода «раз PTR исправен, значит виноваты фильтры». Сопоставьте один и тот же исходящий IP и один и тот же тестовый адресат, сохраните время отправки, журналы очереди и полный ответ сервера-получателя. Так становится видно, застряло ли письмо до SMTP, было ли временное ограничение или получатель принял его, но затем применил свою сортировку. Если ошибка затрагивает только один адресат, изучите его код ответа и локальные правила; если проблемы у нескольких, сначала проверьте сам путь отправки и общие настройки домена. Этот порядок не гарантирует результат, зато отделяет наблюдаемую причину от версии «наверное, DNS».

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