Как настроить запись PTR для почтового сервера

Gmail, YahooMicrosoft проверяет записи PTR во входящей почте и отклоняет или отправляет в папку «Спам» сообщения с серверов без действительного обратного DNS-запроса. В отличие от других платформ. SPF, DKIM или DMARCЗапись PTR не может быть добавлена ​​в вашу собственную DNS-зону. Она должна быть настроена владельцем IP-адреса, который ваш почтовый сервер использует для отправки сообщений.

Записи PTR часто оказываются недостающими после полной настройки остальной части стека аутентификации. Большинство отправителей настраивают все, что находятся под их непосредственным контролем, и все равно сталкиваются с проблемами доставки, поскольку отправляющий IP-адрес не указывает на доверенное имя хоста.

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

Как настроить запись PTR для почтового сервера: 5 шагов

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

Весь процесс обычно занимает от 1 до 5 рабочих дней. Первые три шага занимают всего несколько минут. Провайдер обрабатывает обновление PTR, а затем на заключительном этапе проверяется корректность работы обратного DNS.

Шаг 1: Найдите публичный IP-адрес вашего почтового сервера.

Определите публичный IP-адрес, который ваш почтовый сервер использует для исходящих SMTP-соединений. Это тот IP-адрес, который фактически видят принимающие почтовые серверы, а не какой-либо внутренний или частный IP-адрес, который может также использовать ваш сервер.

Запустите команду curl ifconfig.me из командной строки почтового сервера или проверьте сетевые настройки вашей облачной платформы. Для выделенных SMTP-сервисов IP-адрес отправителя обычно отображается непосредственно в панели управления провайдера.

Убедитесь, что IP-адрес статический. Для записей PTR требуются статические IP-адреса; они бесполезны, если базовый IP-адрес периодически меняется. Облачные платформы обычно по умолчанию назначают статические IP-адреса для почтовых серверов, но проверьте это, прежде чем переходить к следующему шагу.

Шаг 2: Определите владельца вашего IP-блока.

Найдите IP-адрес, используя Инструмент обратного DNS от MXToolbox или путем выполнения запроса WHOIS к ARIN, RIPE или APNIC, в зависимости от вашего региона. Результат определит организацию, которая контролирует блок IP-адресов, обычно это ваш облачный провайдер, хостинговая компания или интернет-провайдер.

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

Шаг 3: Выберите имя хоста и добавьте соответствующую запись A.

Выберите имя хоста, которое четко определяет роль и домен почтового сервера, например, mail.yourcompany.com или smtp.yourcompany.com — это хороший вариант. Избегайте общих имен хостов, предоставляемых интернет-провайдерами, таких как host-203-0-113-25.example-isp.com, которые выглядят подозрительно для принимающих почтовых серверов, даже если технически они работоспособны.

В DNS вашего домена создайте запись A, указывающую на публичный IP-адрес вашего почтового сервера, используя это имя хоста. Эта запись A должна существовать до отправки запроса PTR; для корректного обратного DNS-запроса (FCrDNS) требуется, чтобы прямой и обратный поиски совпадали.

Перед отправкой запроса PTR подождите до 24 часов, пока загрузится запись A. Большинство DNS-серверов обновляются в течение нескольких часов, но ожидание полного временного окна позволяет избежать несоответствия в процессе проверки владельца IP-адреса.

Шаг 4: Настройте PTR через владельца вашего IP-адреса.

Точный порядок действий полностью зависит от вашего провайдера. Облачные платформы, такие как AWS, Azure и GCP, а также выделенные VPS-хостинги обычно предлагают самостоятельную настройку PTR непосредственно в своих консолях. Традиционные хостинги общего пользования и интернет-провайдеры, как правило, требуют вместо этого открытия заявки в службу поддержки.

При отправке запроса укажите три вещи: IP-адрес, желаемое имя хоста и подтверждение того, что вы контролируете домен (соответствующая запись A из шага 3 служит таким подтверждением). Большинство провайдеров отвечают в течение 1–3 рабочих дней. Точные пути навигации см. в разделе, посвященном конкретному провайдеру, ниже.

Шаг 5: Проверка с помощью FCrDNS

После того, как владелец IP-адреса подтвердит установку PTR, проверьте это с помощью двух команд. Во-первых, выполните команду dig -x 203.0.113.25 @8.8.8.8 (заменив ваш фактический IP-адрес), чтобы убедиться, что обратный поиск возвращает выбранное вами имя хоста. Затем выполните команду dig mail.yourcompany.com @8.8.8.8 (заменив ваше имя хоста), чтобы убедиться, что прямой поиск A возвращает тот же IP-адрес.

Оба запроса должны вернуть совпадающие результаты. Это прямое и обратное совпадение — стандартная проверка FCrDNS, которую выполняют принимающие почтовые серверы. Запись PTR, возвращающая имя хоста, запись A которого не указывает на исходный IP-адрес, не проходит проверку FCrDNS и считается недействительной, даже если технически запись PTR существует.

Для полного распространения DNS-записей может потребоваться до 24 часов, после чего можно считать, что новый PTR-файл надежно виден во всех сетях.

Настройка PTR-записи хостинг-провайдером

Точный путь настройки значительно различается в зависимости от хостинг-платформы. Облачные платформы, как правило, предлагают самостоятельную настройку PTR через свои консоли или API, в то время как традиционный общий хостинг требует обращения в службу поддержки. Необходимая информация в обоих случаях одинакова: IP-адрес, имя хоста и подтверждение права собственности на домен.

AWS EC2 и SES

Для решения проблемы AWS требуется отправить запрос в службу поддержки, а не выполнять самостоятельную настройку. Откройте Центр поддержки в консоли AWS, выберите «Сервис: SES» или «Сервис: EC2» в зависимости от источника трафика и отправьте запрос обратного DNS. Укажите Elastic IP и желаемое имя хоста. Рассмотрение запроса обычно занимает 24–48 часов. Документация AWS по обратному DNS-запросу SES Подробно описывает весь процесс обработки запроса.

Microsoft Azure

Azure поддерживает настройку PTR как через портал, так и через PowerShell. На портале перейдите к ресурсу публичного IP-адреса и найдите поле «Обратное DNS». В PowerShell используйте команду Set-AzPublicIpAddress с параметром ReverseFqdn. В документации Microsoft по обратному DNS описан точный синтаксис для обоих подходов.

Виртуальная платформа Google (GCP)

В консоли GCP перейдите в раздел «Сеть VPC» → «Внешние IP-адреса». Щелкните меню с тремя точками рядом с соответствующим IP-адресом и выберите «Обратное DNS». Введите имя хоста и сохраните. GCP проверяет, что запись A имени хоста указывает на IP-адрес, прежде чем активировать PTR, а это значит, что шаг 3, описанный выше, должен быть выполнен, прежде чем этот шаг будет успешным.

Hetzner, Linode и DigitalOcean

Все три провайдера выделенных VPS предлагают самостоятельную настройку PTR непосредственно через свои панели управления. В Hetzner Robot или Cloud найдите IP-адрес в разделе «Серверы», щелкните значок карандаша рядом с rDNS и введите имя хоста. В Linode Cloud Manager откройте вкладку «Сеть» в Linode. В DigitalOcean настройте PTR в разделе «Сеть» настроек Droplet.

Общий хостинг и cPanel

Традиционные хостинг-провайдеры, предоставляющие услуги общего хостинга, такие как Bluehost, HostGator, GoDaddy и большинство провайдеров на базе cPanel, обычно не предлагают самостоятельную настройку PTR-записей. Откройте заявку в службу поддержки с запросом PTR-записи для вашего IP-адреса, указывающей на имя хоста вашего почтового сервера, и предоставьте подтверждение владения доменом с помощью соответствующей A-записи.

Некоторые хостинги, предоставляющие услуги общего хостинга, вообще не позволяют настраивать PTR, независимо от формулировки запроса. Если ваш хостинг этого не позволяет, единственный выход — перейти к провайдеру, который это делает. Обычно это означает выделенный VPS, облачную платформу или сервис транзакционной почты с поддержкой PTR.

Хостинг почтовых сервисов (Google Workspace, Microsoft 365)

Хостинговые почтовые сервисы управляют записями PTR на собственной общей инфраструктуре. Отправителям, использующим Google Workspace или Microsoft 365, не нужно настраивать PTR самостоятельно, поскольку это делает поставщик услуг для принадлежащих ему и контролируемых им IP-адресов.

Это относится только к случаям, когда отправка осуществляется через собственные исходящие серверы сервиса. Если же вы маршрутизируете почту через сторонний SMTP-сервер, используя Google Workspace или Microsoft 365 для других целей, требования PTR применяются к IP-адресу этого стороннего сервера, а не к инфраструктуре Google или Microsoft.

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

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

• Проверка через командную строку: Выполните команду `dig -x [ваш IP-адрес] @8.8.8.8`, чтобы убедиться, что обратный поиск возвращает выбранное вами имя хоста. Выполните команду `dig [ваше имя хоста] @8.8.8.8`, чтобы убедиться, что прямой поиск возвращает ваш IP-адрес. Оба результата должны совпадать; это проверка FCrDNS, которую фактически выполняют принимающие почтовые серверы.
• Онлайн-инструменты проверки: Обратный DNS-запрос MXToolbox принимает IP-адрес и возвращает имя хоста PTR, а также статус "пройдено"/"не пройдено". Это полезно для нетехнического подтверждения и для включения в заявки в службу поддержки при работе с владельцем IP-адреса над устранением проблемы.
• Проверка на стороне сервера: Выполните команду `hostname -f` на самом почтовом сервере, чтобы убедиться, что настроенное на сервере имя хоста совпадает с тем, что возвращает PTR. Если они отличаются, команда HELO/EHLO почтового сервера отправляет другое имя, отличное от того, которое разрешается в PTR, и большинство принимающих серверов рассматривают это несоответствие как ошибку, даже если сам PTR технически действителен.

Распространенные проблемы с записями PTR и способы их решения.

Эти четыре проблемы являются причиной большинства проблем с доставкой PTR-запросов. В большинстве случаев для их решения необходимо связаться с владельцем IP-адреса.

Запись PTR полностью отсутствует.

Клинический диагноз: Выполнение команды dig -x [ваш IP] @8.8.8.8 не возвращает результат PTR или возвращает NXDOMAIN.

Fix: Свяжитесь с владельцем IP-адреса и запросите запись PTR, указывающую на имя хоста выбранного вами почтового сервера. Предоставьте подтверждение владения доменом и соответствующую запись A из DNS вашего домена в качестве доказательства.

Имя хоста PTR не соответствует записи A (ошибка FCrDNS)

Клинический диагноз: Обратный поиск возвращает имя хоста, но прямой поиск этого имени хоста возвращает другой IP-адрес или вообще не возвращает IP-адрес. Это классический пример ошибки FCrDNS.

Fix: Либо обновите запись A, чтобы она указывала на фактический отправляющий IP-адрес, либо попросите владельца IP-адреса обновить запись PTR, чтобы она соответствовала существующей записи A. Обе записи должны разрешаться друг в друга, чтобы FCrDNS прошел проверку.

Вместо фирменного имени хоста используется общее имя хоста интернет-провайдера.

Клинический диагноз: Запрос PTR возвращает имя хоста в формате host-203-0-113-25.example-isp.com, а не фирменное имя хоста в вашем собственном домене.

Fix: Попросите владельца IP-адреса обновить запись PTR, чтобы она указывала на имя хоста в вашем домене (mail.yourcompany.com или smtp.yourcompany.com). Использование общих имен хостов интернет-провайдера технически не приводит к ошибке FCrDNS, но они выглядят подозрительно для принимающих серверов и снижают общий уровень доверия.

Отсутствует запись PTR IPv6.

Клинический диагноз: PTR корректно работает для трафика IPv4, но Gmail отклоняет почту, доставленную по IPv6, с ошибками «reverse DNS failed» или «sender identity mismatch».

Fix: Запросите отдельную запись PTR специально для адреса IPv6. Записи PTR для IPv6 находятся в зоне ip6.arpa с использованием обозначения nibble-reversed, что означает, что они настраиваются полностью отдельно от записей IPv4, даже если обе обслуживают один и тот же почтовый сервер.

PTR Records — это качественное звучание.

Настройка PTR осуществляется по универсальной 5-шаговой схеме, но фактический путь конфигурации может различаться в зависимости от провайдера. Облачные платформы и выделенные VPS-серверы предлагают самостоятельную настройку; для общего хостинга требуется обращение в службу поддержки; хостинг почтовых сервисов выполняет весь процесс от вашего имени.

Проверка FCrDNS — это самая важная проверка после завершения настройки. Большинство проблем с доставкой, связанных с PTR, возникают из-за несоответствия между PTR и соответствующей записью A. Устраните это несоответствие, и связанные с этим проблемы с доставкой, как правило, решаются сами собой.

Надежная репутация домена и IP-адреса зависит от записей PTR, работающих совместно с SPF, DKIM и DMARC. Записи PTR подтверждают личность на сетевом уровне, но они не заменяют надлежащую гигиену списка рассылки. Для надежной доставки сообщений необходимы как аутентификация, так и качество списка.

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