[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-1bdeb789-1236-4c08-a702-f5831fefdd5f":3},{"id":4,"body":5,"uuid":6,"created_at":7,"updated_at":8,"brand":9,"header":10,"short_body":11,"image":12,"published":13,"published_at":14,"tags":15},40,"\u003Cp>\u003Cstrong>PTR-запись — обратная DNS-запись: она отвечает на вопрос «какое имя у этого IP-адреса».\u003C\u002Fstrong> Для почтового сервера она обязательна: принимающий сервер берёт IP, с которого пришло письмо, запрашивает его PTR, а затем проверяет, что полученное имя указывает обратно на тот же IP. Нет записи или круг не замыкается — письмо получает минус к репутации или отказ, например \u003Ccode>550 5.7.25\u003C\u002Fcode> у Yahoo.\u003C\u002Fp>\n\u003Cp>Ниже — как устроена PTR-запись, как проверить её командами \u003Ccode>dig\u003C\u002Fcode> и \u003Ccode>nslookup\u003C\u002Fcode>, кто и где её настраивает и что делать, если почту за вас отправляет сервис.\u003C\u002Fp>\n\u003Ch2>Что такое PTR-запись\u003C\u002Fh2>\n\u003Cp>Обычная A-запись переводит имя в адрес: \u003Ccode>mail.example.ru\u003C\u002Fcode> → \u003Ccode>203.0.113.10\u003C\u002Fcode>. PTR делает обратное: \u003Ccode>203.0.113.10\u003C\u002Fcode> → \u003Ccode>mail.example.ru\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>Хранится PTR в специальной зоне \u003Ccode>in-addr.arpa\u003C\u002Fcode>, где октеты адреса записаны в обратном порядке:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>10.113.0.203.in-addr.arpa.  PTR  mail.example.ru.\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Для IPv6 используется зона \u003Ccode>ip6.arpa\u003C\u002Fcode>, и адрес раскладывается по полубайтам, тоже в обратном порядке. Механика та же.\u003C\u002Fp>\n\u003Cp>Отсюда главное свойство PTR, которое объясняет почти все трудности с ней: \u003Cstrong>обратную зону ведёт владелец IP-адреса\u003C\u002Fstrong>, а не владелец домена. Вы можете управлять зоной \u003Ccode>example.ru\u003C\u002Fcode> у любого регистратора, но запись для \u003Ccode>203.0.113.10\u003C\u002Fcode> создаст только тот, кому принадлежит этот адрес: хостинг, облако или интернет-провайдер.\u003C\u002Fp>\n\u003Ch2>Зачем PTR почтовому серверу\u003C\u002Fh2>\n\u003Cp>Принимающий сервер не знает о вас ничего, кроме IP-адреса, с которого открыто соединение. PTR — первое, что он про этот адрес выясняет.\u003C\u002Fp>\n\u003Cp>Требования Gmail для всех отправителей прямо включают обратную DNS: у отправляющего IP должны быть действительные прямая и обратная записи, а имя хоста из PTR должно указывать на тот же IP A-записью (или AAAA-записью для IPv6).\u003C\u002Fp>\n\u003Cp>Yahoo отклоняет письма с IP без корректной обратной зоны ответом \u003Ccode>550 5.7.25 Forward-confirmed reverse DNS failed\u003C\u002Fcode>. Разбор этого кода — на странице \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ferrors\u002Fyahoo\u002F5-7-25-reverse-dns\">550 5.7.25 у Yahoo\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>Остальные провайдеры редко называют PTR в тексте отказа, но учитывают её. Сервер без обратной записи похож на заражённый домашний компьютер: у абонентских адресов PTR обычно нет или она шаблонная.\u003C\u002Fp>\n\u003Ch2>FCrDNS: проверка в обе стороны\u003C\u002Fh2>\n\u003Cp>Одной записи PTR недостаточно. Проверка называется FCrDNS (forward-confirmed reverse DNS) и состоит из двух запросов:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Обратный:\u003C\u002Fstrong> \u003Ccode>203.0.113.10\u003C\u002Fcode> → PTR → \u003Ccode>mail.example.ru\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Прямой:\u003C\u002Fstrong> \u003Ccode>mail.example.ru\u003C\u002Fcode> → A → должен вернуться \u003Ccode>203.0.113.10\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Если второй запрос возвращает другой адрес или не возвращает ничего, проверка не пройдена, даже если PTR существует. Так бывает, когда PTR указывает на имя, для которого никто не создал A-запись, или когда сервер переехал на новый IP, а A-запись осталась старой.\u003C\u002Fp>\n\u003Cp>К этим двум проверкам почти всегда добавляют третье условие: имя, которым сервер представляется в команде \u003Ccode>EHLO\u003C\u002Fcode>, должно совпадать с именем из PTR. Расхождение само по себе не всегда приводит к отказу, но часть фильтров ставит его в минус.\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Что проверяется\u003C\u002Fth>\n\u003Cth>Пример правильного значения\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>PTR адреса \u003Ccode>203.0.113.10\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>mail.example.ru\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>A-запись \u003Ccode>mail.example.ru\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>203.0.113.10\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Имя в \u003Ccode>EHLO\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>mail.example.ru\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Ch2>Как проверить PTR-запись\u003C\u002Fh2>\n\u003Ch3>Командой dig\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\">dig -x 203.0.113.10 +short\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Ответ — имя хоста с точкой в конце, например \u003Ccode>mail.example.ru.\u003C\u002Fcode>. Пустой ответ означает, что PTR нет.\u003C\u002Fp>\n\u003Cp>Теперь прямая проверка:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">dig mail.example.ru A +short\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Должен вернуться тот же \u003Ccode>203.0.113.10\u003C\u002Fcode>. Если вернулся другой адрес или ничего, FCrDNS не проходит.\u003C\u002Fp>\n\u003Ch3>Командой nslookup\u003C\u002Fh3>\n\u003Cp>На Windows \u003Ccode>dig\u003C\u002Fcode> обычно нет, там то же самое делает \u003Ccode>nslookup\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>nslookup 203.0.113.10\nnslookup mail.example.ru\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>В первом ответе ищите строку \u003Ccode>name = mail.example.ru\u003C\u002Fcode>, во втором — тот же IP в блоке \u003Ccode>Addresses\u003C\u002Fcode>. Ответ \u003Ccode>Non-existent domain\u003C\u002Fcode> на первый запрос означает, что PTR не настроена.\u003C\u002Fp>\n\u003Ch3>Командой host\u003C\u002Fh3>\n\u003Cp>На Linux и macOS есть короткий вариант:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">host 203.0.113.10\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Он печатает \u003Ccode>10.113.0.203.in-addr.arpa domain name pointer mail.example.ru.\u003C\u002Fcode> или сообщение \u003Ccode>not found\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch3>Как узнать IP, который нужно проверять\u003C\u002Fh3>\n\u003Cp>Проверять нужно тот адрес, с которого сервер \u003Cstrong>отправляет\u003C\u002Fstrong>, а не тот, на котором работает сайт. Его проще всего взять из заголовков доставленного письма: принимающий сервер записывает в верхний заголовок \u003Ccode>Received\u003C\u002Fcode> и IP, и имя, которое получил по PTR. Вставьте заголовки письма в \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Femail-header-analyzer\">анализ заголовков\u003C\u002Fa>, и цепочка \u003Ccode>Received\u003C\u002Fcode> покажет каждый переход с адресом.\u003C\u002Fp>\n\u003Cp>Если почтовый сервер не только отправляет, но и принимает почту на том же адресе, \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Fsmtp-test\">проверка SMTP-сервера\u003C\u002Fa> подключится к нему и покажет обратное имя адреса, приветствие сервера и поддержку STARTTLS. Прямую половину FCrDNS проверьте затем командой \u003Ccode>dig\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch2>Как PTR видна в заголовках письма\u003C\u002Fh2>\n\u003Cp>Принимающий сервер записывает результат обратного запроса прямо в письмо. Верхний заголовок \u003Ccode>Received\u003C\u002Fcode>, который добавил сервер получателя, у Postfix и многих других серверов выглядит так:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Received: from mail.example.ru (mail.example.ru [203.0.113.10])\n        by mx.example.net with ESMTPS id 4Xk2Pq…\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Первое имя после \u003Ccode>from\u003C\u002Fcode> показывает, как отправитель представился в \u003Ccode>EHLO\u003C\u002Fcode>. В скобках — имя, полученное по PTR, и сам IP. Если оба имени совпадают, у сервера всё в порядке.\u003C\u002Fp>\n\u003Cp>Если PTR нет, вместо имени в скобках стоит \u003Ccode>unknown\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Received: from mail.example.ru (unknown [203.0.113.10])\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Такой заголовок читается за секунду и не требует доступа к серверу: достаточно открыть исходный текст любого письма, которое получатель принял. Если в скобках стоит шаблонное имя провайдера, а в \u003Ccode>EHLO\u003C\u002Fcode> — ваше, значит, PTR не заменили на имя вашего домена.\u003C\u002Fp>\n\u003Ch2>«Некорректно настроена PTR-запись на домене отправителя»\u003C\u002Fh2>\n\u003Cp>Такое предупреждение выдают онлайн-проверки писем и спам-фильтры. Почти всегда за ним стоит одна из четырёх ситуаций:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>PTR нет вовсе.\u003C\u002Fstrong> Состояние по умолчанию для многих свежих VPS и облачных серверов.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>PTR указывает на имя без A-записи\u003C\u002Fstrong> или на имя, которое резолвится в другой адрес.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>PTR общая, выданная провайдером\u003C\u002Fstrong>, вида \u003Ccode>203-0-113-10.static.provider.net\u003C\u002Fcode> или со словами \u003Ccode>dynamic\u003C\u002Fcode>, \u003Ccode>client\u003C\u002Fcode>, \u003Ccode>pool\u003C\u002Fcode>. Механическую проверку она иногда проходит, но фильтры читают такие имена как адрес абонентской сети.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>PTR и \u003Ccode>EHLO\u003C\u002Fcode> расходятся\u003C\u002Fstrong>: сервер представляется \u003Ccode>localhost\u003C\u002Fcode> или внутренним именем контейнера.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Формулировка «на домене отправителя» сбивает с толку: PTR относится к IP-адресу, а не к домену из адреса отправителя. Исправлять запись нужно там, где выдан адрес.\u003C\u002Fp>\n\u003Ch2>Кто настраивает PTR-запись\u003C\u002Fh2>\n\u003Ch3>Хостинг или облако\u003C\u002Fh3>\n\u003Cp>Если сервер арендован, PTR задаётся у хостинга. У многих облачных провайдеров для этого есть поле в панели управления. В Timeweb Cloud, например, это раздел «Сети» → «Публичные IP» → вкладка «PTR». Где поля нет, PTR ставят по заявке в поддержку: укажите IP и нужное имя.\u003C\u002Fp>\n\u003Cp>Заявка короткая. Например: «Прошу установить PTR-запись для IP 203.0.113.10: mail.example.ru. A-запись mail.example.ru → 203.0.113.10 уже опубликована. Адрес используется почтовым сервером».\u003C\u002Fp>\n\u003Cp>Перед заявкой создайте A-запись для этого имени у своего регистратора. Часть хостингов проверяет, что имя указывает на ваш адрес, и без этого запись не поставят.\u003C\u002Fp>\n\u003Ch3>Интернет-провайдер, если сервер стоит в офисе\u003C\u002Fh3>\n\u003Cp>Для сервера в собственной серверной PTR настраивает провайдер, выдавший IP. Обычное условие — статический адрес: для динамического PTR не настроить, и отправлять почту напрямую с такого адреса бессмысленно.\u003C\u002Fp>\n\u003Cp>Для PTR-записи у Ростелекома схема та же: подключить статический IP, затем подать заявку в техподдержку с номером договора, адресом и нужным именем хоста. Если оператор первой линии не понимает запрос, попросите передать его специалистам по сетевым услугам.\u003C\u002Fp>\n\u003Ch3>Если у вас свой блок адресов\u003C\u002Fh3>\n\u003Cp>Владелец блока может получить делегирование обратной зоны и вести PTR на своих DNS-серверах. Для блока меньше \u002F24 используется бесклассовое делегирование по RFC 2317. Это редкий случай, и если он ваш, вы, скорее всего, уже знаете, где эта зона.\u003C\u002Fp>\n\u003Ch2>Как настроить PTR-запись: порядок действий\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>Выберите имя.\u003C\u002Fstrong> Имя на вашем домене, например \u003Ccode>mail.example.ru\u003C\u002Fcode>. Не используйте корень домена, если на нём сайт с другим IP.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Создайте A-запись\u003C\u002Fstrong> \u003Ccode>mail.example.ru\u003C\u002Fcode> → отправляющий IP у регистратора.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Закажите PTR\u003C\u002Fstrong> \u003Ccode>IP\u003C\u002Fcode> → \u003Ccode>mail.example.ru\u003C\u002Fcode> у владельца адреса.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Пропишите это имя в \u003Ccode>EHLO\u003C\u002Fcode>\u003C\u002Fstrong> в настройках почтового сервера. В Postfix это параметр \u003Ccode>myhostname\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Проверьте\u003C\u002Fstrong> \u003Ccode>dig -x\u003C\u002Fcode> и \u003Ccode>dig A\u003C\u002Fcode> и дождитесь, пока изменения разойдутся: у обратной зоны TTL бывает несколько часов.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Повторите для каждого отправляющего IP\u003C\u002Fstrong>, включая IPv6. Если сервер отправляет по IPv6, а PTR есть только у IPv4, часть писем уйдёт с ненастроенного адреса, и отказы будут случайными.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>Частые ошибки\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>PTR создана в своей DNS-зоне.\u003C\u002Fstrong> Панель регистратора разрешает добавить запись типа PTR в зону \u003Ccode>example.ru\u003C\u002Fcode>, но получатели её не спрашивают: они смотрят зону \u003Ccode>in-addr.arpa\u003C\u002Fcode>, которой управляет владелец IP.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Забыт IPv6.\u003C\u002Fstrong> Сервер получил IPv6-адрес, и почта к Gmail уходит через него, а PTR настроена только для IPv4. Требования Gmail распространяются и на IPv6: нужна PTR адреса и AAAA-запись имени, указывающая на тот же адрес.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Сервер переехал, PTR осталась.\u003C\u002Fstrong> Новый IP, старая PTR у старого хостинга, A-запись уже указывает на новый адрес. FCrDNS ломается сразу в обе стороны.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Одна PTR на несколько имён.\u003C\u002Fstrong> У адреса может быть несколько PTR, но многие проверки берут первую. Держите одну запись на один отправляющий IP.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>PTR ведёт на имя с wildcard-записью.\u003C\u002Fstrong> Имя резолвится, но в чужой адрес, и проверка не проходит. Используйте явную A-запись.\u003C\u002Fp>\n\u003Ch2>PTR, SPF и DKIM: что за что отвечает\u003C\u002Fh2>\n\u003Cp>Эти записи часто путают, потому что все они встречаются в одном отчёте о проверке письма. Отвечают они на разные вопросы.\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Запись\u003C\u002Fth>\n\u003Cth>О чём говорит\u003C\u002Fth>\n\u003Cth>Кто публикует\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>PTR\u003C\u002Ftd>\n\u003Ctd>Какое имя у IP-адреса отправляющего сервера\u003C\u002Ftd>\n\u003Ctd>Владелец IP\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>SPF\u003C\u002Ftd>\n\u003Ctd>Каким серверам разрешено отправлять от домена\u003C\u002Ftd>\n\u003Ctd>Владелец домена\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>DKIM\u003C\u002Ftd>\n\u003Ctd>Подписал ли письмо домен и не изменилось ли оно в пути\u003C\u002Ftd>\n\u003Ctd>Владелец домена\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>PTR характеризует сервер, а SPF и DKIM — домен. Правильная PTR не спасёт письмо с доменом без подписи, а идеальные SPF и DKIM не помогут, если сервер отправляет с адреса без обратной записи. Для собственного почтового сервера нужны все три, а DMARC затем связывает SPF и DKIM с адресом в поле «От кого». Состояние доменной половины покажет \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Femail-dns-checker\">проверка DNS для почты\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Если почту отправляет сервис\u003C\u002Fh2>\n\u003Cp>Когда письма уходят через транзакционный сервис или SMTP-релей, соединение с получателем открывают серверы сервиса со своих IP. PTR этих адресов, их A-записи и имя в \u003Ccode>EHLO\u003C\u002Fcode> — забота сервиса, и в вашей DNS-зоне для них ничего настраивать не нужно.\u003C\u002Fp>\n\u003Cp>В FMailer это так и устроено: имя, которым отправляющие серверы представляются в \u003Ccode>EHLO\u003C\u002Fcode>, совпадает с PTR их IP-адресов и с A-записью этого имени. От вас нужны записи, которые относятся к домену: DKIM, SPF и DMARC, и их FMailer публикует сам после делегирования поддомена через NS-записи. Порядок описан в разделе \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Fdocs\u002Fns-records\">«Настройка NS-записей»\u003C\u002Fa>, параметры подключения — в \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Fdocs\u002Fsmtp\">документации по SMTP\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Частые вопросы\u003C\u002Fh2>\n\u003Ch3>Где посмотреть PTR-запись своего сервера?\u003C\u002Fh3>\n\u003Cp>Выполните \u003Ccode>dig -x ВАШ_IP +short\u003C\u002Fcode> или \u003Ccode>nslookup ВАШ_IP\u003C\u002Fcode>. Если ответа нет, PTR не настроена. Отправляющий IP удобнее всего взять из заголовка \u003Ccode>Received\u003C\u002Fcode> доставленного письма.\u003C\u002Fp>\n\u003Ch3>Можно ли добавить PTR-запись у регистратора домена?\u003C\u002Fh3>\n\u003Cp>Нет, если регистратор не владеет вашим IP-адресом. PTR живёт в обратной зоне адреса, и ведёт её тот, кто выдал IP: хостинг, облако или интернет-провайдер.\u003C\u002Fp>\n\u003Ch3>Что такое обратная запись PTR и чем она отличается от A-записи?\u003C\u002Fh3>\n\u003Cp>A-запись переводит имя в IP, PTR — IP в имя. Для почты нужны обе, и они должны указывать друг на друга: это и есть проверка FCrDNS.\u003C\u002Fp>\n\u003Ch3>Нужна ли PTR-запись, если я отправляю через SMTP Яндекса, Mail.ru или сервис рассылок?\u003C\u002Fh3>\n\u003Cp>Нет. Письма доставляют серверы провайдера со своих адресов, и их PTR настроена на его стороне. От вас нужны SPF, DKIM и DMARC вашего домена.\u003C\u002Fp>\n\u003Ch3>Какое имя указывать в PTR?\u003C\u002Fh3>\n\u003Cp>Полное имя хоста на вашем домене, у которого есть A-запись на этот же IP, например \u003Ccode>mail.example.ru\u003C\u002Fcode>. То же имя укажите в \u003Ccode>EHLO\u003C\u002Fcode> почтового сервера.\u003C\u002Fp>\n\u003Ch3>Сколько ждать, пока PTR заработает?\u003C\u002Fh3>\n\u003Cp>Обычно от нескольких минут до нескольких часов, в зависимости от TTL обратной зоны у провайдера. Если через сутки \u003Ccode>dig -x\u003C\u002Fcode> возвращает старое значение, уточните у провайдера, применена ли заявка.\u003C\u002Fp>\n\u003Ch2>Итог\u003C\u002Fh2>\n\u003Cp>PTR-запись связывает IP-адрес почтового сервера с именем хоста, а A-запись этого имени должна вести обратно на тот же адрес. Настраивает PTR владелец IP (хостинг, облако или провайдер), а проверяется она двумя командами \u003Ccode>dig\u003C\u002Fcode>. Имя из PTR стоит использовать и в \u003Ccode>EHLO\u003C\u002Fcode>. Если почту отправляет сервис, обратная зона его адресов — его забота, а ваша — записи домена.\u003C\u002Fp>\n\u003Ch2>Попробовать FMailer\u003C\u002Fh2>\n\u003Cp>Подключите поддомен на fmailer.ru: отправка пойдёт с серверов, у которых PTR, A-запись и \u003Ccode>EHLO\u003C\u002Fcode> уже согласованы, а DKIM, SPF и DMARC FMailer опубликует сам. Свой почтовый сервер, обратную зону и прогрев IP поддерживать не придётся.\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Ffmailer.ru\">Подключить домен на fmailer.ru →\u003C\u002Fa>\u003C\u002Fp>","1bdeb789-1236-4c08-a702-f5831fefdd5f","2026-10-07T20:59:50.884954+03:00","2026-10-07T20:59:50.889078+03:00","fmailer","PTR-запись для почтового сервера: что это, как проверить и настроить","PTR-запись связывает IP почтового сервера с именем хоста. Как проверить PTR через dig и nslookup, что такое FCrDNS, кто настраивает запись и почему без неё письма отклоняют.","https:\u002F\u002Fapi.fmailer.ru\u002Fmedia\u002Fblog\u002Frecord_1bdeb789-1236-4c08-a702-f5831fefdd5f\u002F09-ptr-zapis-dlya-pochtovogo-servera.jpg",true,"2026-10-20T09:00:00+03:00",[16,17,18,19,20,21,22,23,24,25],"ptr запись","проверить ptr запись","ptr запись сервер","проверка ptr записи","ptr запись домен","ptr запись для почтового сервера","настроить ptr запись","обратная запись ptr","некорректно настроена ptr запись на домене отправителя","ptr запись ростелеком"]