Ptr запись для почтового сервера что это
PTR-запись и ее использование
Например, на сервере с доменом sweb.ru используется IP-адрес 77.222.41.9. Для этого IP-адреса существует PTR-запись со значением «sweb.ru»:
Значение PTR-записи не обязательно будет соответствовать какому-либо доменному имени, в A-записи которого используется IP-адрес.
Использование PTR-записи
Проверка PTR-записи используется при фильтрации входящей почты от нежелательных почтовых сообщений.
Так как наличие PTR-записи можно считать нормой для работающих с почтой серверов, то для каждого входящего письма проверяется наличие PTR-записи у сервера-отправителя письма. В случае отсутствия записи письмо не принимается так как отсутствие PTR-записи означает, что сервер-отправитель либо не предназначен для отправки почты (злоумышленники могли получить доступ к компьютеру с доступом в интернет и использовать компьютер для массовых нежелательных рассылок), либо настроен некорректно (администратор почтового сервера не задал PTR-запись).
Задание PTR-записи
PTR-записи заданы для всех основных IP-адресов серверов виртуального хостинга и выделенных серверов под нашим администрированием.
PTR-записи изначально отсутствуют для услуг:
Задать PTR-запись может исключительно организация, которая выдала IP-адрес. Таким образом, мы готовы внести PTR-запись только для IP-адресов, которые были предоставлены нами.
PTR записи на DNS сервере
Для корректной работы почтового сервера важно иметь правильно настроенную DNS зону, в которой должны присутствовать A, MX и PTR-записи. Если с первыми двумя всё более-менее понятно, то настройка PTR-записи (обратной зоны, когда необходимо проверить имя сервера зная его IP-адрес) не редко вызывает сложности в понимании, где она должна быть прописана и кто за неё отвечает. Без PTR-записи часть почтовых серверов откажется принимать почту с вашего сервера, отправив вам в ответ примерно такую ругань:
550-There is no reverse (PTR) record found for your host or A record does not 550 correspond PTR record (in reply to RCPT TO command) 550-Reverse DNS lookup failed. If you think this is wrong, get in touch with 550 postmaster. (in reply to RCPT TO command) 550 5.7.1 Relaying denied. IP name forged (PTR and A records mismatch) for ###.###.###.### (in reply to MAIL FROM command)
Рассмотрим распространенную ситуацию. По каким-то причинам вам перестало хватать возможностей почтового сервера, предоставляемого хостингом, там где находится ваш сайт (или просто вы зарегистрировали домен и хотите настроить свой почтовый сервер). У своего провайдера вы получили статический ip-адрес (или даже небольшую подсеть) и на хостинге прописали А и MX записи с указанием на ваш почтовик (тот самый, выделенный вам провайдером ip-адрес).
Так вот, кто выдал вам статический ip-адрес, тот и прописывает на своем DNS-сервере PTR-записи для вашего почтового сервера в зоне in-addr.arpa. Для этого необходимо послать запрос тому, кто выдал вам статический ip-адрес с просьбой зарегистрировать PTR запись для вашего домена.
DNS-запись in-addr.arpa для почтового сервера mail.mydomain.ru с адресом 123.45.67.89 выглядит так:
123.45.67.89.in-addr.arpa. IN PTR mail.mydomain.ru.
Проверить наличие PTR записи на сервере DNS можно с помощью команды nslookup или аналогичного онлайн-сервиса (к примеру http://www.nslookup.su). В командной строке вызываем nslookup и пишем:
В поле `name` видим имя одного из почтовых серверов яндекса. При правильной настройке обратной зоны, данное поле должно отобразить имя вашего почтового сервера по соответствующему ip-адресу.
Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Почтовый сервер для начинающих. PTR и SPF записи как средство борьбы со спамом
В наших прошлых материалах мы уже рассматривали настройку DNS-зоны для правильной работы почтового сервера, а также роль отдельных DNS-записей. Однако, как показывает практика, не все администраторы правильно понимают механизм работы систем электронной почты с DNS-записями. Поэтому мы решили посвятить этому вопросу отдельную статью, в которой разберем его более глубоко и расскажем о сравнительно новой технологии SPF.
Проведем аналогию с обычной почтой. На почтовом конверте или бандероли всегда содержатся адрес отправителя, адрес получатели и штампы тех почтовых отделений в которых побывало это почтовое отправление. Точно также электронное письмо в своих заголовках содержит сведения об отправителе, получателе и отметки тех почтовых серверов, которые принимали участие в обработке почты.
Допустим вы получили на почте крайне подозрительного вида посылку, якобы от любимого дедушки Константина Макаровича, но почему то штемпель отправителя указывает не на почтовое отделение села Макаровки, а на хутор Гадюкино совсем в другом конце страны. Будете вы открывать такую посылку, рискуя обнаружить вместо банки варенья из райских яблочек споры сибирской язвы, или отправите ее назад, от греха подальше?
Точно также и в системах электронной почты. Если вам пришло письмо от дедушки konstantin-makarovich@example.com, но сервер отправитель почему-то mail.spam.com, то это повод не принимать такое письмо, так как оно с большой долей вероятности является спамом.
Каким образом мы осуществили данную проверку? Очень просто, посмотрели на штемпель почтового отделения отправителя и сравнили его с обратным адресом. Например на конверте написано, что отправитель находится в городе Москва, однако на штемпеле отделения-отправителя стоит индекс 683000, который указывает на Петропавловск-Камчатский. Следовательно такое письмо мы принимать не будем, так как оно не прошло проверку отправителя.
Аналогично обстоит дело и с электронным письмом, только вместо индекса отделения-отправителя используется PTR-запись. Так получив письмо от дедушки, мы сделаем PTR-запрос и выясним, что сервер отправитель у нас mail.spam.com, в то время как согласно переданной при соединении информации должен быть mail.example.com. Все понятно, письмо падает в спам.
Однако если в заголовке будет указано, что сервер отправитель у нас mail.spam.com, то такое письмо успешно пройдет проверку по PTR-записи, не смотря на то, что домен сервера отправителя не совпадает с почтовым доменом письма.
Почему так происходит? Потому что проверка по PTR-записи позволяет определить лишь то, что сервер-отправитель действительно тот, за кого себя выдает. Но никоим образом не определяет подлинность самого отправителя. Т.е. обращаясь к примеру обычной почты мы проверяем лишь то, что обратный адрес и индекс отделения отправителя совпадают, если место отправления Москва, а индекс указывает на Петропавловк-Камчатский, то проверку по PTR такое письмо не прошло, а если место отправления и индекс совпадают, то все нормально и теперь уже ваша задача думать, что делает ваш любимый дедушка в Петропавловске-Камчатском.
Непонимание этого момента приводит к тому, что PTR-запись оказывается настроена неправильно и, как результат, большая часть отправляемой почты не доходит до адресата. Особенно важно это понимать при настройке серверов обслуживающих несколько доменов. В этом случае PTR-запись должна указывать на имя почтового хоста (которое он передает в рамках SMTP-сессии), даже если он расположен в другом домене.
Разберем простой пример.
Сервер mail.example.com отправляет письмо для обслуживаемого им домена eхample.org. Сервер-получатель делает запрос PTR-записи и убеждается, что по адресу 123.123.123.123 действительно находится mail.example.com, следовательно такое письмо будет принято, хотя домен отправителя письма и домен сервера-отправителя не совпадают.
А теперь иная ситуация.
Администратор неправильно настроил DNS-зону, указав неправильный хост в PTR-записи. Cервер-получатель, проверив PTR-запись отклонит наше письмо, так как сервер отправитель не совпадает с результатом обратного DNS-запроса.
Отсутствие PTR-записи практически всегда ведет к отклонению письма, потому как существует негласное соглашение о том, что добросовестный отправитель имеет правильно настроенную обратную зону.
Вернемся к нашему дедушке. Допустим он сообщил вам, что летом собирается выезжать из села Макаровки в соседнее село Ивановка, к некой Марфе Васильевне и намерен оттуда посылать вам корреспонденцию. В таком случае вы без опаски будете принимать письма от дедушки как из Макаровки, так и из Ивановки, но откажетесь от якобы дедушкина письма из Петропавловска-Камчатского.
Подобная технология в системах электронной почты реализуется с помощью технологии SPF. Если коротко, то данная технология позволяет создать специальную DNS-запись, которая будет указывать, кто именно имеет право отправлять почту от имени вашего домена. В самом простом варианте запись будет иметь вид:
Что она означает? То, что для домена example.сom почту могут отправлять узлы указанные в А-записи (+а) и MX-записях (+mx), всю остальную почту следует отклонять (-all).
Рассмотрим еще одну ситуацию.
Ваша компания, кроме своего основного почтового сервера mail.example.com, использует услуги сторонних сервисов, которые могут отправлять почту клиентам компании от ее имени. Это может быть сервис экспресс-почты, который от вашего имени будет уведомлять клиентов о статусе доставки и т.п.
В нашем примере такая почта будет отправляться от имени zakaz@example.com с сервера mail.web-service.com, так как данный сервер не указан в MX-записях домена example.com, то, согласно указанному нами в SPF-записи правилу, такое письмо будет получателем отклонено.
Причем поведение сервера-получателя будет однозначным, так как мы сами вполне однозначно указали, что почту от иных отправителей принимать не следует. Поэтому если вы не уверены, что вся почта будет идти исключительно с ваших серверов, то следует указать более мягкое правило:
В отличие от -all (fail),
all (soft fail) обозначает, что отправители, кроме указанных явно, не имеют права отправлять почту, но не содержит требования отклонять такие письма. Чаще всего такая почта принимается, помечаясь как нежелательная.
Можно также использовать нейтральный префикс:
В этом случае правило сообщает о том, что отправлять почту от имени нашего домена имеют право хосты указанные в A- и MX- записях, насчет остальных узлов никакой информации нет. Прием почты с явно не разрешенных узлов производится на усмотрение сервера-получателя, чаще всего такая почта будет принята без каких либо пометок.
Как быть в нашем случае? Самым правильным решением будет добавить в SPF-запись еще одно правило:
в первом случае мы разрешим прием почты также от всех серверов, перечисленных в MX-записях домена web-service.com, во втором случае только для сервера mail.web-service.com.
В завершение рассмотрим случай, когда почта для вашего домена обслуживается сервером находящимся в другом домене. Например mail.example.com отправляет также почту для домена example.org. В этой ситуации будет правильно использовать для домена example.org те же самые правила, что и для example.com. Для этого используйте специальный вид записи:
Это позволит при необходимости изменять записи только один раз, для основного домена и избавляет администраторов иных обслуживаемых доменов от необходимости отслеживать и вносить изменения в DNS-записи.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Настройка собственного почтового сервера
Если есть необходимость освежить в памяти как всё это работает, то есть давняя, но актуальная статья об архитектуе почтовых систем.
Есть три основных шага, чтобы установить и настроить собственный почтовый сервер.
Настройка IP и DNS
Выбор и запуск приложения почтового сервера
Добавление своего почтового сервера в белые списки
Настройка IP и DNS
Обеспечение внешнего статического IP-адреса, публичного домена и записи PTR
Это основные требования для запуска собственного почтового сервера.
Публичный статический IP-адрес
IP-адрес почтового сервера должен быть общедоступным и постоянным во времени. Убедиться в этом можно у хостинг или Интернет-провайдера.
Доменное имя указывает на IP
DNS-запись публичного доменного имени почтового сервера должна указывать на этот IP-адрес. Им можно управлять в настройках DNS провайдера доменного имени.
IP указывает на доменное имя
Самое главное, обратная DNS-запись (именуемая PTR) должна указывать на доменное имя почтового сервера по IP-адресу. Можно попросить своего хостинг-провайдера или поставщика интернет-услуг настроить его. Его можно легко проверить по IP-адресу онлайн (например, тут), или с помощью команды ‘nslookup’ в Windows и команды ‘host’ в системах на основе UNIX.
Настройка MX записи в DNS
Запись почтового обмена (MX) указывает почтовый сервер, ответственный за прием сообщений электронной почты от имени домена.
Type
Host
Value
Priority
Priority (приоритет) используется, когда в домене более одного почтового сервера.
TTL (время жизни) можно установить любое предпочтительное значение, а наименьшее значение используется для применения конфигурации DNS как можно скорее при отладке настроек.
Настройка DKIM записи в DNS
Почта, идентифицированная ключами домена (DKIM) — это протокол безопасности электронной почты, который прикрепляет зашифрованную цифровую подпись к электронному письму. Принимающий сервер проверяет его с помощью открытого ключа, чтобы убедиться, что электронное письмо не было подделано.
И запись DNS будет выглядеть так:
Type
Host
Value
selector._domainkey
v=DKIM1; k=rsa; p=public_key
TTL (время жизни) имеет то же значение, что и в предыдущем разделе.
Настройка SPF записи в DNS
Инфраструктура политики отправителя (SPF) — это стандарт проверки подлинности электронной почты, который проверяет IP-адрес отправителя по списку авторизованных IP-адресов владельца домена для проверки входящей электронной почты.
Тут запись DNS будет выглядеть так:
Type
Host
Value
TTL (время жизни) имеет то же значение, что и в предыдущем разделе.
Можно использовать удобный онлайн-генератор записи SPF.
Дополнительные записи DNS
Некоторые поля не обязательны, но желательно иметь.
DMARC
Запись доменной проверки подлинности сообщений, отчетов и соответствия (DMARC) позволяет собственному почтовому серверу декларировать политику того, как другие почтовые серверы должны реагировать на недостоверные сообщения от него.
BIMI
Индикаторы бренда для идентификации сообщений (BIMI) — это новый стандарт, созданный для того, чтобы упростить отображение логотипа рядом с сообщением. Кроме того, BIMI предназначен для предотвращения мошеннических электронных писем и улучшения доставки.
TLS-RPT
TLS-отчетность (TLS-RPT) дает ежедневные сводные отчеты с информацией о электронных письмах, которые не зашифровываются и не доставляются.
Все эти записи кроме MTA-STS могут быть созданы с помощью Power DMARC Toolbox. Конфигурация MTA-STS похожа на Google, также описывалась на habr, и, наконец, может быть проверена с помощью Hardenize.
Выбор и запуск приложения почтового сервера
Конечно, хостинг должен позволять устанавливать программное обеспечение. Можно использовать любое подходящее приложение для почтового сервера. Например, есть бесплатный hMailServer для Windows, который предоставляет все необходимые функции с минимальным использованием ресурсов. Для систем на базе UNIX существует множество бесплатных почтовых серверов, таких как Exim Internet Mailer или iRedMail.
Если вы знаете ещё хорошие программы, то поделитесь ими в комментариях. Подробный обзор выбора такого программного обеспечения, конечно, заслуживает отдельной статьи.
Инициализация
Когда программное обеспечение выбрано и установлено, самое время его настроить.
Домен и пользователи
Нужно добавить домен и начальный набор пользователей почтового сервера.
Безопасность
Чтобы обеспечить соответствующий уровень безопасности, мы должны добавить сертификат SSL для домена. Конфигурацию SSL можно проверить здесь.
Подпись сообщений
Далее, следует настроить DKIM. Нужно указать полученные выше приватный ключ и селектор. Кроме того, методы заголовка и тела должны быть установлены на «расслабленный», алгоритм подписи должен быть установлен на «SHA256», иначе на некоторых SMTP серверах не проходит проверка (например, google).
Защита от спама
Наконец, нужно настроить антиспам-проверку специальными узлами черных списков, такими как spamhaus.org, чтобы защитить пользователей почтового сервера от нежелательных сообщений.
Протоколы электронной почты
Нужно настроить три протокола электронной почты, которые необходимы для её отправки и получения.
SMTP используется для приема входящей и исходящей почты с/на другие почтовые серверы. И это позволяет пользователям домена отправлять свои сообщения.
25 порт
Этот порт необходим для управления входящими подключениями от других почтовых серверов. Метод безопасности следует установить в STARTTLS.
587 порт
Он нужен для почтовых клиентов собственного почтового сервера. Метод безопасности следует установить в STARTTLS.
465 порт
Он не является официальным и может потребоваться для старых почтовых клиентов. И метод безопасности следует установить в SSL/TLS.
POP3, IMAP
POP3 и IMAP используются отдельными почтовыми клиентами, такими как Outlook на ПК или любой почтовый клиент на мобильных телефонах. Это позволяет пользователям домена управлять своими сообщениями.
Также можно настроить порты 143 для IMAP и 110 для POP3, но они не шифруются и сейчас их уже мало кто использует.
Проверка
Итак, когда все настроено, нужно протестировать почтовый сервер, отправив письмо кому-нибудь из списка пользователей. Кроме того, в некоторых почтовых приложениях есть функция самодиагностики (см. ниже пример от hMailServer).
Теперь пора проверить отправку на внешний адрес.
Аккаунт Gmail.com
Если есть учетная запись Gmail.com (что наверняка), можно отправить тестовое письмо на свой адрес Gmail. Затем открываем свою электронную почту в браузере и нажимаем «Показать подробности».
Если есть «подписано: домен», подпись DKIM настроена правильно. Если есть «отправлено по почте: домен», SPF в порядке.
Также, можно убедиться в оригинальных заголовках, что статус проверки пройден.
Также, в Outlook можно видеть те же заголовки в свойствах сообщения.
Специальные онлайн-сервисы
Существует множество онлайн-сервисов, которые могут проверять отправку электронной почты. Ниже приведены некоторые из них.
AppMailDev
Этот сервис позволяет тестировать конфигурацию почтового сервера, такую как DKIM и SPF, отправляя электронное письмо на указанный сгенерированный почтовый адрес. Нужно просто следовать инструкциям на экране и результаты теста будут отображены там же.
DKIMValidator
Предоставляет те же функции, что и предыдущая служба. Результаты тестирования будут отправлены на адрес отправителя.
HAD Email Auth Tester
Чтобы проверить отправку сообщения здесь, нужно отправить специальное сообщение на tester@email-test.had.dnsops.gov. Результаты тестирования будут отправлены на адрес отправителя.
PowerDMARC
Этот сервис предоставляет только облегченную проверку всех атрибутов, но у него есть удобные инструменты, указанные в ссылках выше.
Итак, если всё настроено правильно, но сервер присутствует в чёрных списках спама, нужно внести его в белый список.
Добавление почтового сервера в белые списки
Итак, если всё вышеперечисленное настроено правильно, другие почтовые серверы по-прежнему могут отмечать сообщения как спам и отклонять их. Это бывает, когда IP (или его диапазон) домена попадает в какой-то черный список. Чаще всего причиной этого является использование соседних IP-адресов для рассылки спам-сообщений.
Внесение в белый список в публичных источниках
Итак, сначала проверим IP (и, если необходимо, домен) онлайн на наличие в каких-либо черных списках. Его можно проверить в любом онлайн-чекере, который можно найти через поиск. Например, MXToolBox проверяет самые популярные черные списки. Также, multirbl.valli.org показывает много источников черного списка и доверие к каждому из них.
Затем нужно последовательно просмотреть каждый элемент в результатах и прочитать рекомендации о том, как внести IP-адрес в белый список в конкретном источнике черного списка. Но не все из них могут позволить это сделать бесплатно, например, немецкий UCEPROTECT®-Network.
Внесение в белый список определенных почтовых серверов
Обход черных списков
SendInBlue
Это еще один хороший сервис, который позволяет бесплатно отправлять 9 тысяч писем в месяц с лимитом 200 в день. Но есть нюансы: встроенное отслеживание электронной почты нельзя отключить и высоковатая цена сверх бесплатного лимита.
В каждой службе нужно зарегистрироваться и получить подтверждение почтового домена. После подтверждения, каждый из них дает указания на то, что должно быть настроено для DNS (DKIM, SPF и DMARK) и почтового приложения (адрес сервера ретрансляции SMTP, порт и учетные данные).
Заключение
Итак, теперь можно использовать все преимущества выделенного почтового сервера. Надеюсь, что этот материал поможет наиболее эффективно достичь поставленной цели. Если есть какие-либо вопросы или предложения по этой теме, буду рад обсудить в комментариях.
PTR запись для почтового сервера: что это такое, как ее добавить, настроить и проверить
Если у вас есть собственный почтовый сервер или вы намерены создавать почтовую рассылку с собственного домена, вам жизненно важно обезопасить себя от того, чтобы адресаты не сочли ваши письма так называемым спамом.
Дело в том, что многие почтовые службы ради снижения объема нежелательной и вредоносной электронной корреспонденции (то есть этого самого спама) осуществляют проверку PTR-записи у отправителя. И для того, чтобы ваши письма не считались спамом, а ваше доменное имя не вошло в категорию нежелательных отправителей, первым делом вам необходимо настроить PTR-запись для почтового сервера.
Название записи этого типа происходит от латинского слова pointer, что в переводе означает “указатель”. По сути, эта она связывает IP-адрес с вашим доменным именем, то есть PTRзапись в этом очень похожа на A-запись для DNS-сервера. Если первая связывает домен с IP-адресом месторасположения сайта, то вторая – наоборот, связывает IP-адрес с доменом.
В случае, если вы делаете рассылки довольно часто и у вас большая база, то стоит присмотреться к аренде выделенного сервера в европе или купить VDS сервер.
Как производится проверка PTR-записи онлайн
Когда письмо из рассылки приходит на почтовый сервер, тот проверяет его прежде, чем определить полученную корреспонденцию в папку “Входящие” или “Спам”. Первый этап – это проверка PTR-записи для IP, откуда пришло письмо. Если запись существует и совпадает с данными домена отправителя, то это может стать одним из решающих факторов одобрения корреспонденции и ее направления в папку “Входящие”.
Если же PTR-запись не совпадает или вообще отсутствует, то велика вероятность попадания письма в “Спам”. Впрочем, при отсутствии этой записи сервер будет проверять корреспонденцию по ряду других критериев, но проверка при этом будет очень строгой.
Как проверить PTR-запись для почтового сервера?
Проверка PTR-записи онлайн предполагает выполнение запроса в домене in-addr.arpa, а в ответ приходит обратная запись PTR. К примеру, если адрес вашего хоста – 111.222.333.444, то транслируется она в обратном порядке и выглядит, как 444.333.222.111.in-addr.arpa.
В целом же существуют несколько способов проверки своей PTR-записи. Давайте же рассмотрим самые простые из них.
Первый вариант – это проверка онлайн при помощи специальных whois-сервисов. Как проверить Ptr-запись для почтового сервера таким образом? Зачастую, достаточно просто ввести IP в проверочную строку. Например, вы можете использовать для этого сервис от RigWEB и в течение нескольких секунд получить всю необходимую информацию, в том числе и искомую запись.
Второй вариант – проверить PTR-запись при помощи командной строки. Для Windows это выполняется следующим образом:
Как добавить PTR запись для почтового сервера
Если вы не знаете, как прописать PTR-запись для почтового сервера, то вас наверняка успокоит то, что сделать это очень просто. Для этого вам всего лишь нужно связаться с обладателем IP-адреса, к которому привязан ваш сайт. Просто отправьте своему провайдеру просьбу добавить PTR запись, так как она вам нужна для вашего IP-адреса. Для виртуального же хостинга обычно ничего не нужно прописывать, так как эта запись чаще всего уже есть.
Вы арендуете виртуальный выделенный сервер и хотите узнать, как прописать PTR-запись для VDS? В этом случае вам нужно зайти в административную панель, перейти в раздел хостинг-услуг, а там уже выбрать пункт “Изменить обратную DNS-запись”, после чего – подтвердить свой выбор.
Как видите, ничего сложного. Другое дело, что многое в этой ситуации зависит от хостинг-провайдера, а точнее – от скорости реагирования его техподдержки. Поэтому стоит с самого начала очень скрупулезно подходить к выбору хостера. И если вы хотите пользоваться профессиональным хостингом с максимально удобными и выгодными условиями, то вам стоит обратить внимание на услуги, предоставляемые компанией RigWEB.
Воспользовавшись нашим хостингом, вас не будет волновать, как создать PTR-запись, ведь мы заботимся о комфорте наших клиентов и стараемся предоставить максимально качественный сервис. В зависимости от выбранного вами тарифного плана, мы готовы предоставить вам комплекс услуг, в число которых входит и настройка PTR-записи, если вам это необходимо. От обычного переноса сайта на наш виртуальный хостинг до полной настройки VDS-сервера в кратчайшие сроки – мы с радостью поможем вам с решением любых задач.
Кроме того, мы гарантируем вам:
Благодаря использованию качественного оборудования, размещенного в оснащенном по последнему слову техники дата-центре под круглосуточным контролем опытных специалистов, мы предоставляем максимально возможный в современных условиях UpTime серверов и стабильную работу ваших сайтов.
Любые вопросы, связанные с работой нашего хостинга, вы можете задавать нашим специалистам. Техподдержка RigWEB работает в режиме 24/7/365 и отвечает в течение 30 минут с момента отправки тикета, поэтому вы можете быть уверены в оперативном решении вашей проблемы. Так что если вы не знаете, как сделать PTR-запись, пользуясь нашим хостингом – можете смело задавать этот вопрос нашим специалистам.
Никаких скрытых платежей! Вы всегда будете знать, за что платите деньги, и взамен получите 100% оплаченных вами ресурсов наших серверов.
Пользуйтесь профессиональным хостингом от RigWEB и получайте удовольствие от работы над своими проектами, ведь вы всегда можете рассчитывать на максимально комфортные и выгодные условия сотрудничества с нами!