Что такое PTR-запись, зачем она нужна и как её прописать? »

Необходимые настройки для беспроблемной доставки доменной почты

25 января 2020

В последнее время встречаю много вопросов по поводу недоставки доменной почты или попадания ее в спам. Почтовики все ужесточают и ужесточают политики обработки писем. Обычные владельцы сайтов отправляют вполне безобидные письма своим клиентам используя свою же доменную почту, но письма улетают в спам или вообще не доходят. Что же нужно настроить, чтобы не было проблем?

Для нормальной доставки доменной почты необходимо корректно настроить:

• PTR
• SPF
• Заголовок Return-Path

Также для защиты от несанкционированного использования Вашего домена можно настроить:

• DKIM
• ADSP
• DMARC

Что это за непонятные штуковины и как их настроить, опишу ниже.

PTR (обратная dns запись)

У любого домена в dns есть A записи, которые связывают домен с IP сервера, на котором находится сам сайт. А PTR запись делает то же самое, но наоборот, связывает IP сервера с доменом.

PTR запись очень важна для почтовиков. Когда на почтовый сервер приходит письмо, он берет IP, откуда пришло письмо, затем смотрит значение этой записи. Если значение этой записи совпадает с именем сервера, откуда пришло письмо, то почтовик пропускает письмо. Если не совпадает, то в большинстве случаев кидает в спам или вообще не пропускает. Также высока вероятность бана IP сервера Gmail’ом, если записи нет или она некорректно настроена (даже при корректной настройке остальных параметров).

Где настроить PTR запись?

На нормальных обычных хостингах PTR уже настроен, ничего делать не нужно. Если же у Вас виртуальный или физический сервер, то, как правило, нужно самому прописывать эту запись в панели управления сервером. Название поля для PTR может быть разным — ptr, reverse dns, имя сервера и т.д. Также в имени сервера (в самой ОС) должен быть указан этот домен (Linux — /etc/hostname, FreeBSD- /etc/rc.conf).

Что указывать в PTR записи, если на сервере несколько доменов?

Если на сервере хостится несколько доменов, то нужно взять один из них и прописать его в имени сервера и в PTR записи.

Как проверить PTR запись?

PTR можно проверить на соответствующих сервисах, например, тут. Также можно проверить консольными утилитами, например, dig:

dig -x 123.123.123.123 +short

Команда выше выведет значение PTR записи.

SPF

SPF (Sender Policy Framework) — это ещё одна важная запись. Необходима для того, чтобы указать почтовым серверам, с каких ресурсов будут приходить письма, т.е. верификация источника. Сама запись практически никак не влияет на несанкционированное использование домена, она больше нужна как требование большинства принимающих почтовых серверов. Также, если если нет этой записи или она некорректно настроена, то отправляемые письма скорее всего попадут в спам или будут отмечены как поддельные:

Письмо с доменной почты с некорректной SPF записью в веб-интерфейсе Яндекс.Почты

Как и где прописать SPF запись?

SPF запись прописывается в dns записях домена и представляет собой TXT запись в DNS, например:

Пример SPF записи в DNS домена

В начале записи должна быть указана версия SPF записи v=spf1. Рекомендуется использовать только эту версию.

Затем через пробел идут источники. Они могут быть следующими:

• Обычные IP адреса / подсети адресов с префиксами ip4: (для IPv4 адресов) и ip6: (для IPv6 адресов). Например, ip4:123.123.123.123. Могут использоваться в записи несколько раз. Это предпочтительный тип источника, и они не создают дополнительные DNS запросы;
• Ссылки на другие записи в DNS домена / других доменов. Например, a, mx. Такой тип не рекомендуется, т.к. значения неявные, и создаются дополнительные запросы к DNS;
• Подключение внешних валидных SPF записей через include:. Например, include:somedomain.com. Обычно такой тип используется, чтобы подключить в основную запись записи удаленного почтового сервиса или сервиса рассылки. Каждое такое подключение создает от одного дополнительного запроса в DNS, в зависимости от того, сколько подключений идет внутри. Поэтому не стоит этим злоупотреблять.

Обратите внимание на то, что в SPF допускается до 10 дополнительных запросов в DNS. Если будет больше, то запись будет невалидной. Проверить вложенность и колличество DNS запросов в SPF записи можно здесь.

В конце записи указывается политика для неуказанных в записи источников и может быть:

• -all (hardfail) — отклонять (не рекомендуется, т.к. в некоторых случаях может только навредить доставке писем);
• ~all (softfail) — не следует отклонять, но обратить внимание (рекомендуется);
• ?all — относиться нейтрально (не рекомендуется);
• all или +all — принимать (не рекомендуется).

Иногда возможны случаи, когда нужно полностью взять всю SPF запись с другого домена. Для этого существует redirect=. Например, redirect=domain.com. В этом случае больше никакие записи не указываются, в т.ч. и all.

Еще обратите внимание на то, что, если сервер и MTA (exim4, sendmail и т.д.) умеют работать по IPv6 и указан только IPv4, то IPv6 тоже нужно указать в SPF записи, т.к. на некоторые почтовые сервера письма будут уходить через IPv6.

Давайте приведу простой пример. У нас есть сайт на сервере с IP 123.123.123.123, подключена доменная почта на том же сервере, плюс ко всему используем сервис рассылки responder.com, с которого идет рассылка от Вашей доменной почты. Такие сервисы обычно предоставляют адрес, который нужно добавить в SPF запись. Например это будет spf.responder.com. SPF запись получится такой:

v=spf1 ip4:123.123.123.123 include:spf.responder.com ~all

SPF запись для одного домена должна быть только одна и она не распространяется на поддомены. Для поддоменов должна быть отдельная SPF запись.

Как проверить SPF?

SPF можно проверить в заголовках исходника письма. Заголовки письма можно посмотреть на большинстве почтовых программ и веб-версий почтовиков.

Пример удачной проверки:

Пример неудачной проверки:

Валидность SPF записи можно проверить вот здесь.

DKIM

DKIM (DomainKeys Identified Mail) — это цифровая подпись писем. Она гарантирует, что письмо отправлено именно от того домена, который указан в email отправителя.

Логика такая: сервер отправляет заранее подписанное письмо почтовому серверу. Почтовый сервер сверяет подпись с публичным ключом, который указан в DNS домена. Если подпись не совпадает, то почтовый сервер следует правилам в записях DMARC и ADSP, а при их отсутствии руководствуется своими политиками.

Как настроить DKIM?

Если у Вас обычный хостинг и используете их же почтовый сервер, то DKIM скорее всего уже работает из коробки. Ничего делать не нужно.

Если же у Вас виртуальный или физический сервер, то DKIM необходимо настраивать самостоятельно. На стороне сервера Вам необходим приватный ключ для подписи писем и публичный ключ для DNS. Эти ключи генерируются самостоятельно, либо выдаются почтовыми сервисами или сервисами рассылки. Также нужно включить подпись писем в MTA (отправщике писем) на сервере.

После того, как подписывание писем на стороне сервера настроено, необходимо создать TXT запись в DNS вида:

Пример DKIM записи в DNS домена

В поле хоста должен быть указан селектор и ._domainkey на конце. Например, mail._domainkey.

Важно: селектор в DNS записи должен соответствовать селектору DKIM подписи.

В значении записи указываем через точку с запятой:

• v — версия DKIM (всегда v=DKIM1);
• k — алгоритм шифрования (всегда k=rsa);
• p — публичный ключ (p=публичный_ключ).

• t=y — режим тестирования;
• t=s — использование записи только для домена, для поддоменов запись использоваться не будет;
• h — предпочитаемый hash-алгоритм, может быть h=sha1 и h=sha256;
• s — тип сервиса, использующего DKIM, может быть s=email (электронная почта) и s=* (все сервисы, по умолчанию).

Как проверить DKIM?

Для проверки наличия самой подписи можно глянуть заголовки письма. Должно быть что-то типа такого:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=domain.com; h=date
:from:to:message-id:subject:mime-version:content-type; s=
dc-smart1; bh=sM8mwMa+DhlFNAT/Q85vxxnJ9PAemdLfkhxQbVXajbs=; b=NG
MBJ9qrrJSyCqQ9p8nFkBBDK+86d/QKOYAsQbL3V6fVdwqtJwyKAq2LNlmSagSQwp
1yBEeS88rtA6aVSoRg4pyJ/vwFYaP8LYqD8DfL5dXSzUFyEqPAgmI08qmBafPFrC
jhDVyKDbJrpCIo2i6HJ8to3gcArB2GGxdXTMM/th0=

Корректность связки подписи и публичного ключа можно можно так же увидеть в заголовках письма:

Если проверка DKIM не пройдет, то увидим dkim=fail.

Как прописать в DNS несколько DKIM ключей?

Иногда необходимо прописать в DNS домена несколько публичных DKIM ключей, когда письма от доменной почты идут не только с сервера, но и, например, с сервиса почтовой рассылки. Для добавления дополнительной записи необходимо создать еще одну TXT запись. При этом селектор в хосте должен быть другой:

Пример указания нескольких DKIM записей в DNS домена

ADSP

ADSP (Author Domain Signing Practices) — политика, которая позволяет сообщать принимающим почтовым серверам, что делать с письмом пришедшим с нашего домена, но не имеющее подписи. Если этой записи нет, то принимающий почтовый сервер следует своим политикам обработки писем. Эту запись нужно указывать после настройки DKIM.

ADSP запись признана устаревшей и не нужна при использовании DMARC.

Как прописать ADSP запись?

ADSP запись прописывается в TXT записи в DNS записях домена:

Пример ADSP записи в DNS домена

• all — все письма должны быть подписаны (рекомендуется);
• discardable — отклонять все неподписанные письма (не рекомендуется, т.к. в некоторых случаях может навредить);
• unknown — аналогично отсутствию записи (бесполезное значение).

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) — ещё одна политика обработки писем для почтовых серверов. Она задает политику проверки приходящей доменной почты и указывает, что делать, если письма не проходят проверку SPF или DKIM. Для этой записи необходимо предварительно настроить SPF и DKIM. Если DMARC записи нет, то принимающий почтовый сервер следует своим политикам обработки писем.

Как настроить DMARC?

DMARC — это обычная TXT запись. Прописывается в DNS домена:

Пример DMARC записи в DNS домена

Основные параметры записи:

v — версия записи, должно быть DMARC1 (наличие обязательно).

p (policy) — политика домена, может быть:

• none — не принимать никаких особых действий, всё на усмотрение почтовика;
• reject — не принимать письмо.

sp (subdomain policy) — политика поддоменов, может принимать те же значения, что и p (policy).

pct (percentage) — процент писем, которые подвергаются политикам. Например, при политике v=DMARC1; p=quarantine; pct=50; половина писем не прошедших аутентификацию пойдет в спам. По умолчанию pct=100.

Что же указать в DMARC?

Если же Вы на 100% уверены, что все Ваши письма проходят проверку DKIM и SPF, то можете использовать quarantine или reject, при этом поднимая процент обрабатываемых писем через параметр pct.

Заголовок Return-Path

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

Письмо с некорректным заголовком Return-Path в веб-интерфейсе Яндекс.Почты

Сам заголовок должен быть передан сайтом/приложением и содержать в адресе тот же домен, что и в заголовке From.

Рекомендации

• В первую очередь проверьте/настройте PTR запись, пропишите корректную SPF запись и проверьте наличие корректного заголовка Return-Path в отправляемых письмах. Этого будет достаточно для нормальной отправки писем.
• Не помешает еще проверить наличие IP адреса сервера, откуда идет почта, в спамлистах, например, здесь. Если же Вы обнаружили, что IP в спамлистах, то желательно его сменить. Обычно на хостингах это решается покупкой выделенного IP, на виртуальных серверах пересозданием сервера, на физических серверах сменой сервера или покупкой дополнительного IP адреса.
• Для дополнительной защиты от несанкционированного использования Вашего домена корректно настройте DKIM, ADSP и DMARC.
• Не отправляйте слишком большие письма. Заголовки письма тоже учитаваются. Можно упереться в лимит размера.
• Не отправляйте письмо большому количеству получателей. Можно так же упереться в лимиты.
• В письме не должно быть очень длинных строк. Можно упереться в лимиты длины строки (да, такое тоже бывает).
• Не занимайтесь рассылкой писем с Вашего хостинга/сервера. Для этого существуют грамотно настроенные сервисы рассылки.
• Если Вы не занимаетесь рассылкой, но частота отправки писем очень большая, то шлите почту через сервисы рассылки. Иначе принимающие почтовые серверы могут временно ограничить прием писем от Вашей доменной почты.

Полезные ссылки

При регистрации доменного имени, и в процессе его использования, возникает необходимость понимания различных терминов, которые в основном связаны с конфигурацией DNS-серверов. Одним их таких терминов является PTR-запись, скорее всего многие слышали о данной DNS-записи. Давайте разберёмся для чего необходима PTR-запись.

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

На услугах виртуального хостинга PTR-запись добавлена по умолчанию для имени нашего сервера, например morbo.handyhost.ru, но это не помешает Вам отправлять письма пользователям сайта.

Если Вы заказали у нас услугу VPS-сервера или Выделенного сервера, и Вам необходимо добавить PTR-запись, напишите запрос нам в техническую поддержку, мы поможем с добавлением.

Заказать услугу VPS или арендовать Выделенный сервер Вы можете на нашем сайте перейдя по ссылке.

I know this has been marked as answered but I want to provide a more comprehensive answer. For my examples I will be using:

• google.com’s IP address 172.217.3.206 because it does have a
  PTR record.
• serverfault.com’s IP address 151.101.1.69 because it does not have a PTR record.

The first thing to note is dig is a multiplatform command, you can get it for Windows on the ISC BIND website listed under BIND, then select your Windows platform (32 or 64 bit). It has many other tools including its own nslookup binary. I don’t use that nslookup.exe version, instead I use the default one that comes with Windows (C:WindowsSystem32
slookup.exe). However if you want to use dig you may want to edit your local PATH environment variable, or move the dig tool to your C:WindowsSystem32 folder.

Command 2) dig -x 172.217.3.206 — This version of the command is a lot simpler, as described in the dig -h, the -x flag is a «shortcut for reverse lookups». The output is identical to the output shown above in the previous command.

Command 3) dig -x 151.101.1.69 — This example is showing what it looks like when a PTR record is not found, using the serverfault.com example. As you can see, the answer does not list a PTR, and can only find the SOA record of 151.in-addr.arpa:

Server: google-public-dns-a.google.com
Address: 8.8.8.8

Name: sea15s11-in-f14.1e100.net
Address: 172.217.3.174

Command 5) nslookup -debug 172.217.3.174 — Use this command instead to see the full list, including the record type and the full list of results. The -debug flag persists, to turn it off you must use -nodebug:

Command 6) nslookup -type=PTR 172.217.3.174 — This version of the command specifies PTR records with the -type flag. It is different than the version without the -type flag in two ways. The first is it lists all PTR answers. The second is that it includes the information «Non-authoritative answer» which the other command neglects to include. If you carefully look above at the debug output, the authority records state 0, so both of these commands should state «Non-authoritative answer».

Server: google-public-dns-a.google.com
Address: 8.8.8.8

Non-authoritative answer:
174.3.217.172.in-addr.arpa name = sea15s11-in-f14.1e100.net
174.3.217.172.in-addr.arpa name = sea15s11-in-f14.1e100.net
174.3.217.172.in-addr.arpa name = sea15s11-in-f174.1e100.net
174.3.217.172.in-addr.arpa name = sea15s11-in-f174.1e100.net

Command 7) nslookup -debug -d2 -type=PTR 151.101.1.69 — Here is how you would get as much detail as possible about the full reverse lookup request. Reminder: To turn it off use -nodebug and -nod2. This example is purposely failing on the serverfault.com example:

Command 8) nslookup 174.3.217.172.in-addr.arpa — You may be wondering if you can use the traditional reverse DNS lookup method with nslookup as we did in Command 1 with dig. You can. Notice the same nslookup failings as I listed above (Command 6) between this command and the one with the -type=PTR flag set below (Command 9):

Server: google-public-dns-a.google.com
Address: 8.8.8.8

Name: 174.3.217.172.in-addr.arpa

Command 9) nslookup -type=PTR 174.3.217.172.in-addr.arpa — As you may expect, it looks identical to Command 6.

тем что Вы клиент MTC и взяли в аренду выделенный IP

anonymous

(20.05.15 15:54:49 MSK)

А кто еще ? Спроси что они предлагают, а потом заставь их это сделать.

если у них есть такая процедура как установка rdns, то вам повезло. если нет, то писать до тех пор, пока запрос не попадет админу, который знает где прописывать

anonymous

(20.05.15 15:57:59 MSK)

Сейчас жду отказ на офф. бланке провайдера от внесения информации в обратную зону. А положение какое, нормы и т.п?

petav

(20.05.15 15:58:33 MSK)

Именно так и показалось, что могут, но не знают о чем речь.

petav

(20.05.15 15:59:11 MSK)

Не думаю что это у нас как-то регулируется.

MrClon

(20.05.15 16:23:08 MSK)

обычно в крупных компаниях очень ограниченный круг работает с тонкими материями 🙂

anonymous

(20.05.15 16:26:33 MSK)

Чтобы разместить там почтовик, например.

anonymous

(20.05.15 18:57:35 MSK)

Deleted

(20.05.15 19:00:18 MSK)

Для почтовика любой PTR подойдёт. Скорее всего у провайдера он уже прописан. Но ТС, как я понял, хочет определённую запись. Перфекционизм?

generator

(20.05.15 19:08:28 MSK)

Таки почтовый сервер может сравнивать A и PTR. Ну и до кучи ростелеком — он раньше для динамичных адресов для физиков PTR делал.

anonymous

(20.05.15 19:18:29 MSK)

в сети встречаются почтовики настроенные параноиками. Которые отбрасывают письма пришедшие с почтовиков у которых нету ptr

snaf

(20.05.15 19:50:46 MSK)

Если нет PTR, то да. Я поэтому выше и написал, что PTR может быть любым, главное, чтобы он был, но ТС, как я понимаю, хочет определённую запись.

generator

(20.05.15 19:59:38 MSK)

почтовики настроенные параноиками отбрасывают почту если ptr не указывает на домен с которого пришла почта

snaf

(20.05.15 20:36:58 MSK)

PTR, содержащий «client», «static», «dynamic» — очень любят резать. А такие по умолчанию обычно и выдают.

Pinkbyte

(20.05.15 20:41:15 MSK)

PTR должен соответствовать MX записи прямой зоны! Почтовый сервер сравнивает записи в прямой и обратной зоне.

petav

(20.05.15 22:12:43 MSK)

У меня такой. Да и троица гёгель-яша-сру тоже такие, а хомячки все на этой троице в основном.

Еще и по спамбазам пробегаются.

Если провайдеру надо обосновывать — провайдер дебил.

Это самый энергонезатратный способ фильтрации спама. Исхожу из того, что зачем мне письмо которое пришло от компьютера с ботнет, ведь только у него нет PTR, потому что он не специально настроен для работы почты. У почтового сервера все атрибуты должны присутствовать!

Конечно яндекс и майл принимают все, но они письма через интеллектуальную систему фильтрации прогоняют, что не актуально держать и обучать для средней компании.

Вопрос самому себе — Интересно, а яндекс шарит свои спам фильтры?

petav

(20.05.15 23:00:34 MSK)

а что делать если на одном ip крутятся почтовики от разных доменов?

snaf

(20.05.15 23:08:31 MSK)

Одна валидная птр проканывает. Прописана одна, шлют с разных доменов на одном ойпишнике — брат жив.

Никогда с таким не сталкивался.

Счастливый человек. Если A != RTR, жди беды. 90% почтовиков твоё мыло принимать не будут.

beastie

(21.05.15 01:30:11 MSK)

И правильно сделают. Если админ не в состоянии сделать нормальную PTR то ничего хорошего с такого сервера придти не может.

Ничего провайдер не должен, если это не прописано в договоре с тобой. Это его личная зона, его личный блок айпишников, и он волен делать с ним все, что захочет. Я сидел с Акадо по DOCSIS и, переезжая с квартиры на квартиру (они не переносили подключение, а каждый раз приходилось заново подключаться), каждый раз писал им в саппорт и просил пойти навстречу и прописать мой MX. И каждый раз они это делали в течение дня. За это я очень любил Акадо.

mky

(21.05.15 02:26:38 MSK)

Угу, будет весьма консистентно складывать эту корреспонденцию в спам. Гугл очень чувствителен к спаму, ему надо чтобы был PTR, правильный EHLO, DKIM, SPF, DMARC и TLS с доверенным сертификатом. Тогда он, может быть, будет класть твою почту в инбокс получателю. Спамассассин тоже будет накидывать пару баллов за отсутствие PTR.

Кстати, как раз гуголь iirc и не будет.

beastie

(21.05.15 05:11:31 MSK)

По RFC PTR просто должен иметь место быть. Он не должен соответствовать чему либо. А требование A==PTR уже выработано народом — Гуголь всякий НЕ БУДЕТ банить письмо если A!=PTR

Да, теперь понял свое заблуждение. т.е. достаточно записи ptr example.com и не обязательно иметь mx.example.com.

petav

(21.05.15 09:47:45 MSK)

rambler году так в 2008 и пара забугорных почтовиков, которыми я пользовался от большой безнадеги(уже и не вспомню какие это были :-))

Pinkbyte

(21.05.15 10:33:10 MSK)

Подключиться как юр.лицо и платить деньги, а не гнуть пальцы за 500р/месяц.

irr123

(21.05.15 10:42:48 MSK)

Это, в общем-то, не плохо. Не можешь хорошо оформить почтовый сервер — не берись. Спама предостаточно и так. Жаль, что mta mark в rfc не прошёл, было бы весьма не плохо.

AS

(21.05.15 10:56:53 MSK)

а что делать если на одном ip крутятся почтовики от разных доменов ?

Должна быть сходимость. Поверяешь PTR. Если не тот, проверяешь, ещё раз, прямую запись, но для имени из PTR. Если совпало, то всё хорошо.

AS

(21.05.15 11:02:47 MSK)

Последнее исправление: AS 21.05.15 11:03:03 MSK
(всего

исправлений: 1)

AS

(21.05.15 11:06:07 MSK)

Последнее исправление: AS 21.05.15 11:06:58 MSK
(всего

исправлений: 1)

А кто был в таком замечен кстати ?

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

AS

(21.05.15 11:10:16 MSK)

Да мне интересны конкретные примеры

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

AS

(21.05.15 11:24:47 MSK)

Я зарегестировал домены в яндекс и добавил

в свой postfix, пока вопрос решается.

petav

(21.05.15 11:34:00 MSK)

Последнее исправление: petav 21.05.15 11:34:09 MSK
(всего

исправлений: 1)

Я не ТС. У меня нет таких проблем со сменой ptr и т.д.

Мне интересны isp который вот прямо сегодня в 2015 парсят ptr и сверяют с мх.

eabi

(21.05.15 12:54:56 MSK)

Ну раз у тебя проблем с ptr нет, сделай себе почтовик с таким ptr, и посмотри. И речь была не про сверку с mx, а про bla-bla.pppoe.example.com.

AS

(21.05.15 13:19:18 MSK)

Последнее исправление: AS 21.05.15 13:20:35 MSK
(всего

исправлений: 1)

• 03 декабря 2014
• Max
• 20 комментариев
• Опубликовано в категории Блог

Многие из вас встречали незнакомую аббревиатуру «PTR-запись». Давайте разберемся что это, зачем нужно и как ее прописать.

PTR запись — если объяснять простыми словами, это запись, которая связывает IP адрес с доменом вашего сайта.

У вашего домена на DNS серверах прописана А запись, которая связывает ваш домен с IP адресом сервера, где расположен ваш сайт. А PTR запись делает наоборот — связывает IP адрес с доменом.

Для чего нужна PTR запись?

В основном она необходима при отправке писем от имени вашего домена. Большинство почтовых серверов, прежде чем принять решение — поместить письмо во «Входящее» или отклонить как СПАМ, проверяют запись PTR у IP адреса сервера, с которого это письмо пришло. Если данная запись есть, и она совпадает с именем домена, от имени которого пришло письмо, то это будет являться одним из фактов для принятия положительного решения (что это письмо не СПАМ).

Если совсем быть точным, то проверяется совпадение домена из PTR записи и домена, который значится в параметре HELO (EHLO) почтового сервера-отправителя. В параметре HELO (EHLO) обычно содержится имя сервера, например, server1.hosting.ru

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

Как прописать PTR запись?

Т.к. PTR запись — это обратная запись, которая связывает IP адрес с доменом, то прописывать её должен владелец IP адреса, который назначен серверу, где расположен ваш сайт. Иными словами, вам нужно обратиться на свой хостинг и попросить прописать PTR запись для IP адреса. Регистратор доменов вам тут не поможет (если конечно вы не используете его хостинг).

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