Как прописать PTR для почтового сервера: почему в DNS домена её нет и кто её меняет

28 октября клиент написал в поддержку: нужно прописать PTR для настройки почты, можно ли это сделать через нас. Домен у него зарегистрирован у нас, DNS-записи ведутся в Cloudflare, почтовый сервер стоит у другой компании. Просьба звучит логично: домен наш, значит, и запись наша. Но ни мы, ни регистратор, ни Cloudflare эту запись поменять не могли.

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

Почему PTR нет в панели DNS домена

Обычная A-запись отвечает на вопрос «какой IP у этого имени» и лежит в зоне домена. PTR отвечает на обратный вопрос: «какое имя у этого IP».

mail.example.com  A    203.0.113.25
203.0.113.25      PTR  mail.example.com

Выглядит как пара к A-записи, но хранится в другом месте. Для адреса 203.0.113.25 запись лежит в обратной зоне 113.0.203.in-addr.arpa: цифры адреса там идут задом наперёд. Эта зона относится к блоку IP-адресов, а блоком распоряжается его владелец. Домен, регистратор и DNS-провайдер домена к ней отношения не имеют.

Так что PTR принадлежит адресу. Поэтому домен можно перенести к другому регистратору или в Cloudflare, и PTR останется на месте, а смена сервера с другим IP оставит старую запись на старом адресе.

Кому писать

Тому, у кого вы получаете IP-адрес:

• VPS или выделенный сервер: хостинг-провайдеру, у которого он арендован. У многих есть поле в панели, обычно оно называется PTR, rDNS или Reverse DNS. Нет поля, значит, через поддержку.
• Адрес от оператора связи в офисе: оператору. PTR ставят на статический IP, для динамического адреса такая просьба смысла не имеет.
• Почтовый сервис или внешний SMTP: никому. Письма уходят с адресов сервиса, и PTR у них его забота.

Если вы не уверены, чей адрес, посмотрите whois:

whois 203.0.113.25

В ответе будут название сети и организация. Там может оказаться не та компания, которой вы платите: whois показывает держателя блока, а сервер могли сдать через посредника. Писать всё равно надо тому, кому платите, остальное он передаст сам.

Что проверить до письма провайдеру

PTR проверяют вместе с прямой записью. Почтовый сервер получателя берёт IP отправителя, узнаёт по PTR имя, потом смотрит, какой IP у этого имени. Если вернулся тот же адрес, проверка пройдена. Это называется forward-confirmed reverse DNS, и PTR без пары такую проверку не пройдёт.

Прямая запись. Имя почтового сервера должно указывать на этот же IP:

dig +short mail.example.com A

В ответе должен быть 203.0.113.25, и только он. Если записи нет, сначала заведите её в DNS домена. Куда её вписывать, разобрано в статье про домен и свой сервер.

Прокси Cloudflare. Если DNS на Cloudflare, у записи mail должен быть режим DNS only, без оранжевого облака. Иначе имя будет указывать на адреса Cloudflare, и прямая запись с PTR не сойдётся.

Имя в HELO. Подключаясь к чужому серверу, ваш сервер представляется командой HELO или EHLO. Имя там должно совпадать с тем, что вы просите прописать в PTR. Посмотреть, что настроено, можно так:

postconf smtp_helo_name myhostname   # Postfix
exim -bP primary_hostname            # Exim

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

Порт 25. К PTR он не относится, но ломает то же самое. Многие провайдеры закрывают исходящий порт 25 от спама, и тогда ваш сервер не сможет передавать письма другим почтовым серверам, какой бы PTR ни стоял. Проверить можно с самого сервера:

nc -vz -w 5 gmail-smtp-in.l.google.com 25

Если соединение обрывается по таймауту, порт, скорее всего, закрыт. Об этом удобно спросить в том же письме.

Что написать провайдеру

Хватит двух строк: адрес и имя.

Прошу настроить PTR для IP 203.0.113.25 на mail.example.com

Не «для домена example.com»: у провайдера запись заводится на адрес, а имя он берёт из вашей просьбы. Ставьте именно почтовое имя, которое проверили выше, а не любое подходящее. Некоторые провайдеры проверяют прямую запись и откажут, если её нет.

Как убедиться, что всё сошлось

Запросите PTR:

dig +short -x 203.0.113.25

Ответ должен быть mail.example.com., точка в конце нормальна. Пустой ответ значит, что записи нет. Имя вида 203-0-113-25.static.provider.example значит, что стоит запись провайдера по умолчанию. Если изменение только что внесли, а ответ старый, подождите: резолверы держат запись в кэше, пока не истечёт её TTL. Увидеть TTL можно в той же команде без +short.

Затем проверьте прямую запись второй раз: она должна вернуть тот же IP. На настоящем письме это тоже видно. Отправьте письмо на Gmail, откройте «Показать оригинал» и посмотрите заголовок Received с вашим сервером.

Отсутствие PTR Gmail называет прямо. В наших старых тикетах отказ выглядел так:

550-5.7.1 The IP address sending this message does not have a PTR

Бывало и наоборот: в 2018 и 2019 годах Gmail так отвечал на письма с нашего сервера, хотя запись была на месте и проверки её видели. Причину мы тогда не выяснили. Так что если проверки чистые, а отказ есть, сохраните текст отказа и время: они понадобятся для разбора.

Требования Google к отправителям называют согласованные прямые и обратные записи обязательными для всех, кто пишет на адреса Gmail. Другие почтовые сервисы тоже смотрят на PTR, но правила у каждого свои.

Если на сервере несколько доменов

Нужна одна запись на адрес, а не на домен. Если с 203.0.113.25 уходит почта пяти доменов, в PTR стоит одно имя сервера, например mail.example.com, и HELO у него то же. Имя в PTR не обязано совпадать с доменом в адресе отправителя: домены подтверждаются своими SPF и DKIM. Как они устроены, рассказано в статье про почту на своём домене.

Отдельная ловушка: IPv6. Если у сервера есть такой адрес, почта может уходить через него, а у него своя обратная зона (ip6.arpa) и своя PTR. Либо попросите прописать запись и для IPv6, либо отправляйте только по IPv4. В Postfix за это отвечает параметр inet_protocols.

Ещё одна частая находка: PTR указывает на имя, которого нет. На одном из клиентских VDS мы видели запись на старое техническое имя без A-записи. Обратная запись вроде бы есть, а проверка её всё равно не проходит, поэтому смотрите и эту половину.

Когда PTR менять не нужно

На виртуальном хостинге у всех клиентов сервера один адрес, поэтому PTR под ваш домен там не поставить. То же с внешним почтовым сервисом: письма уходят не с вашего IP. Вопрос возникает только тогда, когда письма отправляет ваш сервер с вашего IP. Стоит ли держать такой сервер, мы разбирали в статье «Свой почтовый сервер: героизм или мазохизм?».

Как это устроено на Siteko. На VDS PTR настраиваем мы: напишите в поддержку адрес и имя. Исходящий порт 25 на VDS по умолчанию закрыт, про него тоже спрашивайте поддержку. На виртуальном хостинге PTR не настраивается, потому что все аккаунты работают на одном общем адресе.

Вернёмся к клиенту из начала. Бот поддержки через 18 секунд объяснил, что адрес не наш, дал текст для провайдера и напомнил про HELO. Прямая запись у него уже сходилась. Чем закончилось, мы не знаем: больше клиент не писал. Вся работа там сводилась к одному письму, только не нам, а тому, у кого арендован сервер.