PTR и HELO: как настроить обратную DNS-запись для рассылок

1. Что такое PTR и HELO простыми словами

Когда ваш сервер отправляет письмо, он подключается к серверу получателя с определенного IP-адреса. Принимающая сторона видит только IP и должна решить, можно ли ему доверять. Для этого она делает обратный DNS-запрос: спрашивает, какое имя закреплено за этим IP. Ответ хранится в PTR-записи (pointer record), которая живет не в зоне вашего домена, а в зоне владельца IP-адреса: хостинг-провайдера, облачного провайдера или ESP.

HELO (в современном варианте EHLO) это команда, которой отправляющий сервер представляется в начале SMTP-сессии. По RFC 5321 аргументом EHLO должно быть полное доменное имя сервера (FQDN) либо, если его нет, адресный литерал. На практике фильтры сравнивают три вещи: IP подключения, имя из PTR и имя из EHLO. Совпадение всех трех называется forward confirmed reverse DNS (FCrDNS) и считается признаком честно настроенного отправителя.

Важно понимать разделение зон ответственности. SPF, DKIM и DMARC вы настраиваете в DNS своего домена. PTR вы в своей зоне настроить не можете: она редактируется тем, кому делегирована обратная зона IP-адреса. Это главный источник путаницы у маркетологов и CRM-команд, которые впервые сталкиваются с отказами по этой причине.

2. Как проверить PTR почтового сервера

Сначала узнайте, с какого IP реально уходят ваши письма. Самый надежный способ: посмотреть заголовки доставленного письма, поле Received покажет цепочку серверов и внешний IP отправителя. Если вы отправляете через ESP, список исходящих IP обычно есть в документации платформы или в кабинете.

Дальше выполните обратный запрос. В Linux и macOS: dig -x 203.0.113.10 +short. В Windows: nslookup 203.0.113.10. В ответ вы должны получить имя хоста, например mail.example.com. Если ответа нет (пусто или NXDOMAIN), PTR-записи у исходящего IP нет, и это уже само по себе проблема.

Затем проверьте прямую запись полученного имени: dig mail.example.com A +short. Имя из PTR должно резолвиться обратно в тот же IP. Только тогда схема замыкается и проходит проверку FCrDNS.

3. Почему Gmail требует PTR и FCrDNS

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

Если требование не выполнено, Gmail отклоняет письмо с постоянной ошибкой. Характерный ответ выглядит так: 550 5.7.25 требует настройки PTR-записи для отправляющего IP (в оригинале: The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not point to the sending IP). Это hard reject: письмо не попадет ни во входящие, ни в спам, и повторная отправка без исправления даст тот же результат.

Логика провайдера проста. Спамеру легко подделать имя в EHLO, но сложно заставить владельца чужого IP прописать на него PTR. Наличие согласованной пары PTR и прямой записи означает, что владелец IP и владелец имени действуют согласованно. Mail.ru и Яндекс в своих правилах для отправителей также требуют корректную и осмысленную обратную DNS-запись исходящего IP (не автоматически сгенерированную вида dsl-4-3-2-1.provider.net), поэтому настройка PTR закрывает сразу несколько площадок.

4. PTR HELO mismatch: когда несовпадение критично

Ситуация ptr helo mismatch означает, что сервер представился одним именем (например, EHLO smtp.vendor.com), а PTR его IP указывает на другое (например, 203-0-113-10.hosting-provider.net). Строгого требования полного совпадения в стандартах нет, и Gmail в первую очередь проверяет именно связку PTR и прямой записи. Но часть фильтров и корпоративных шлюзов оценивает расхождение EHLO и PTR как дополнительный негативный сигнал.

Практическое правило: приведите все три имени к одному согласованному виду. Если вы управляете сервером, задайте hostname, совпадающий с PTR, и укажите это же имя в настройках почтового сервера (в Postfix это параметры myhostname и smtp_helo_name). Если отправляете через ESP, mismatch обычно возникает из-за вашего выделенного IP, к которому еще не привязали обратную запись, и решается заявкой в поддержку платформы.

Отдельный случай: один IP обслуживает несколько доменов отправки. Это нормально. PTR одна на IP, и она не обязана совпадать с доменом в адресе отправителя. Проверяется согласованность IP и имени сервера, а не домена From. За соответствие домена From отвечают SPF и DKIM alignment.

5. Как настроить PTR для рассылки: три сценария

Сценарий первый: вы отправляете через ESP (Unisender, Sendsay, DashaMail и подобные) с общего пула IP. Ничего настраивать не нужно: PTR уже прописаны провайдером. Ваша задача только убедиться, что отказы не связаны с этим, проверив заголовки писем.

Сценарий второй: вы купили у ESP выделенный IP. Обратная зона все еще принадлежит платформе, поэтому PTR настраивается через нее: обычно это заявка в поддержку с указанием желаемого имени, например mail.yourdomain.com. Перед заявкой создайте прямую A-запись этого имени, указывающую на выделенный IP, иначе FCrDNS не замкнется.

Сценарий третий: собственный сервер на VPS или в облаке. PTR запрашивается у хостинг-провайдера (у многих это делается в панели управления, у части через тикет). Порядок действий: выберите имя, создайте A-запись на IP сервера, дождитесь обновления DNS, попросите провайдера установить PTR, настройте hostname и EHLO сервера на то же имя. Меняйте параметры в нерабочее время и проверяйте отправку после каждого шага.

6. Дерево диагностики: нет PTR записи исходящего IP

Используйте эту последовательность, когда видите отказы с упоминанием PTR или reverse DNS.

Если на шаге 2 выяснилось, что IP общий и проблема на стороне ESP, не пытайтесь чинить это сами: соберите заголовки, тексты отказов и откройте тикет в поддержку платформы. Если IP выделенный, у вас есть рычаг, и исправление занимает время одной заявки плюс обновление DNS.

7. Как убедиться, что проблема решена

После настройки повторите полную проверку: dig -x по IP, dig A по имени из PTR, сравнение с EHLO. Все три значения должны быть согласованы. Затем отправьте тестовое письмо на адрес Gmail и посмотрите ответ сервера в логах отправки: отказы 550 5.7.25 должны исчезнуть.

Откройте заголовки тестового письма в Gmail (пункт Show original). В строках Received вы увидите ваше новое имя хоста, а в сводке аутентификации результаты SPF, DKIM и DMARC. Учтите, что PTR влияет на прием письма сервером, но не гарантирует попадание во входящие: репутация домена и жалобы оцениваются отдельно.

Дальше следите за метриками. В Google Postmaster Tools смотрите долю прохождения SPF, DKIM, DMARC и соответствие требованиям Google, в Mail.ru Postmaster объем, доставку и жалобы. Если после исправления DNS письма принимаются, но все равно попадают в спам, причина уже не в PTR: разбирайте репутацию и контент по материалам /blog/spf-dkim-dmarc-pass-no-inbox и /blog/pisma-v-spame-gmail.