Якщо у вас є власний поштовий сервер або ви маєте намір створювати поштове розсиланняз власного домену, вам життєво важливо убезпечити себе від того, щоб адресати не вважали ваші листи так званим спамом.
Справа в тому, що багато хто поштові службизаради зниження обсягу небажаної та шкідливої електронної кореспонденції(тобто цього спаму) здійснюють перевірку PTR-запису у відправника. І для того, щоб ваші листи не вважалися спамом, а ваше доменне ім'я не увійшло до категорії небажаних відправників, насамперед вам необхідно налаштувати PTR-запис для поштового сервера.
Назва запису цього типу походить від латинського слова pointer, що в перекладі означає покажчик. По суті, ця вона пов'язує IP-адресу з вашим доменним ім'ям, тобто PTR запис у цьому дуже схожий на A-запис для DNS-сервера. Якщо перша пов'язує домен з IP-адресою розташування сайту, то друга – навпаки, пов'язує IP-адресу з доменом.
Як проводиться перевірка 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 це виконується так:
- Натисніть кнопку "Пуск" і виберіть пункт "Виконати".
- Наберіть cmd.
- У командному рядку, що відкрився, введіть nslookup -type=PTR IP, де IP - ваша IP адреса.
- Подивіться отриманий звіт – у ньому ви знайдете потрібний вам запис PTR.
Для сімейства Unix-систем схема дій трохи інша: відкрийте термінал або консоль і введіть команду dig -x IP, де IP - ваша IP-адреса. В результаті виконання команди вам буде показаний звіт, де можна побачити, зокрема, і PTR-запис.
Крім того, ви можете запустити перевірку PTR записуонлайн. Під час перевірки було виявлено відсутність PTR-запису? Тоді її обов'язково потрібно прописати.
Як додати PTR запис для поштового сервера
Якщо ви не знаєте, як прописати PTR-запис для поштового сервера, то вас, напевно, заспокоїть те, що зробити це дуже просто. Для цього вам лише потрібно зв'язатися з власником IP-адреси, до якого прив'язаний ваш сайт. Просто надішліть своєму провайдеру прохання додати PTR запис, так як він вам потрібний для вашої IP-адреси. Для віртуального ж хостингу зазвичай нічого не потрібно прописувати, тому що цей запис найчастіше вже є.
Ви орендуєте віртуальний виділений сервер та хочете дізнатися, як прописати PTR-запис для VDS? У цьому випадку вам потрібно зайти в адміністративну панель, перейти до розділу хостинг-послуг, а там уже вибрати пункт “Змінити зворотний запис DNS”, після чого – підтвердити свій вибір.
Як бачите, нічого складного. Інша річ, що багато що в цій ситуації залежить від хостинг-провайдера, а точніше – від швидкості реагування його техпідтримки. Тому варто від початку дуже скрупульозно підходити до вибору хостера. І якщо ви хочете користуватися професійним хостингом з максимально зручними та вигідними умовами, то варто звернути увагу на послуги, що надаються компанією RigWEB.
Скориставшись нашим хостингом, вас не хвилюватиме, як створити PTR-запис, адже ми дбаємо про комфорт наших клієнтів та намагаємось надати максимально якісний сервіс. Залежно від вибраного вами тарифного плану, ми готові надати вам комплекс послуг, до яких входить і налаштування PTR-запису, якщо вам це необхідно. Від звичайного перенесеннясайту на наш віртуальний хостингдо повного налаштування VDS-сервера в найкоротший термін– ми з радістю допоможемо вам із вирішенням будь-яких завдань.
Крім того, ми гарантуємо вам:
- Стабільну роботу та UpTime 99.9%
Завдяки використанню якісного обладнання, розміщеного в обладнаному по останньому словутехніки дата-центрі під цілодобовим контролем досвідчених фахівців, ми надаємо максимально можливий сучасних умовах UpTime серверів та стабільну роботуваші сайти.
- Оперативну та кваліфіковану техпідтримку
Будь-які питання, пов'язані з роботою нашого хостингу, ви можете ставити нашим фахівцям. Техпідтримка RigWEB працює в режимі 24/7/365 і відповідає протягом 30 хвилин з моменту відправлення тикета, тому ви можете бути впевнені у оперативне рішеннявашої проблеми. Тож якщо ви не знаєте, як зробити PTR-запис, користуючись нашим хостингом – можете сміливо ставити це питання нашим фахівцям.
- Справедливі тарифи та прозоре ціноутворення
Жодних прихованих платежів! Ви завжди знатимете, за що платите гроші, і натомість отримаєте 100% оплачених вами ресурсів наших серверів.
Користуйтеся професійним хостингом від RigWEB та отримуйте задоволення від роботи над своїми проектами, адже ви завжди можете розраховувати на максимально комфортні та вигідні умови співпраці з нами!
У наших попередніх матеріалах ми вже розглядали налаштування DNS-зони для правильної роботипоштового сервера та роль окремих DNS-записів. Однак, як показує практика, не всі адміністратори правильно розуміють механізм роботи систем електронної поштиіз DNS-записами. Тому ми вирішили присвятити цьому питанню окрему статтю, в якій розберемо його глибше і розповімо про порівняно нової технології SPF.
Основна проблема сучасних поштових систем- Спам. існує багато різних методикборотьби з ним, але основна - аналіз відправника, враховуючи, що вся необхідна інформація в листі є.
Проведемо аналогію зі звичайною поштою. На поштовому конверті або бандеролі завжди містяться адреса відправника, адреса одержувачі та штампи тих поштових відділень, в яких побувало це поштове відправлення. Так само електронний лист у своїх заголовках містить відомості про відправника, одержувача та позначки тих поштових серверів, які брали участь у обробці пошти.
Допустимо ви отримали на пошті вкрай підозрілого виду посилку, нібито від коханого дідуся Костянтина Макаровича, але чомусь штемпель відправника вказує не на поштове відділення села Макарівки, а на хутір Гадюкіне зовсім в іншому кінці країни. Ви відкриватимете таку посилку, ризикуючи виявити замість банки варення з райських яблучок суперечки сибірки, або відправте її назад, від гріха подалі?
Так само і в системах електронної пошти. Якщо вам надійшов лист від дідуся [email protected] , але сервер відправник чомусь 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-записи. Сервер-одержувач, перевіривши PTR-записвідхиляє наш лист, оскільки сервер відправник не збігається з результатом зворотного запиту DNS.
Відсутність PTR-записиМайже завжди веде до відхилення листа, оскільки існує негласна угода про те, що сумлінний відправник має правильно налаштовану зворотну зону.
Повернемося до нашого дідуся. Припустимо, він повідомив вам, що влітку збирається виїжджати з села Макарівки в сусіднє село Іванівка, до Марфи Василівни і має намір звідти посилати вам кореспонденцію. У такому разі ви без побоювання прийматимете листи від дідуся як з Макарівки, так і з Іванівки, але відмовитеся від нібито дідуся листа з Петропавловська-Камчатського.
Подібна технологія в системах електронної пошти реалізується за допомогою технології SPF. Якщо коротко, то дана технологіядозволяє створити спеціальний DNS-запис, який вказуватиме, хто саме має право відправляти пошту від імені вашого домену. В самому простому варіантізапис матиме вигляд:
Example.com. IN TXT "v=spf1 +a +mx -all"
Що вона означає? Те, що для домену example.сom пошту можуть відправляти вузли вказані в А-запису (+а) та MX-записах (+mx), решту пошти слід відхиляти (-all).
Однак не все так райдужно. По-перше, підтримка SPF все ще не є стандартом де-факто та відсутність SPF-записиу домену відправника не привід відхиляти листа. Друга проблема - сервера пересилання або випадки коли пошту відправляють сервера не вказані в А або MX записах, а то й взагалі, що знаходяться в інших доменах. Це може бути обумовлено як архітектурою IT-системи підприємства, так і використанням для відправлення чужих серверів, коли ви прив'язуєте свій домен до провайдерського чи публічного сервісу. В останньому випадку необхідно бути особливо обережним і дуже бажано проконсультуватися за допомогою сервісу.
Розглянемо ще одну ситуацію.
Ваша компанія, окрім свого основного поштового сервера mail.example.com, використовує послуги сторонніх сервісів, які можуть надсилати пошту клієнтам компанії від її імені. Це може бути сервіс експрес-пошти, який від вашого імені повідомлятиме клієнтів про статус доставки тощо.
У нашому прикладі така пошта надсилатиметься від імені [email protected] із сервера mail.web-service.com, так як даний серверне вказано в MX-записах домену example.com, то, згідно з зазначеним нами в SPF-записиправилом, такий лист буде одержувачем відхилено.
Причому поведінка сервера-одержувача буде однозначним, оскільки ми цілком однозначно вказали, що пошту від інших відправників приймати годі було. Тому якщо ви не впевнені, що вся пошта буде йти виключно з ваших серверів, слід вказати м'якше правило:
Example.org IN TXT "v=spf1 +a +mx ~all"
На відміну від -all(Fail), ~all(soft fail) означає, що відправники, крім зазначених явно, не мають права надсилати пошту, але не містить вимоги відхиляти такі листи. Найчастіше така пошта приймається, позначаючи як небажана.
Можна також використовувати нейтральний префікс:
Example.org IN TXT "v=spf1 +a +mx ?all"
У цьому випадку правило повідомляє про те, що відправляти пошту від імені нашого домену мають право хости, зазначені в A- і MX-записах, щодо решти вузлів жодної інформації немає. Прийом пошти з явно не дозволених вузлів проводиться на розсуд сервера-отримувача, найчастіше така пошта буде прийнята без будь-яких позначок.
Як бути у нашому випадку? Найправильнішим рішенням буде додати до SPF-записще одне правило:
Example.org IN TXT "v=spf1 +a +mx +mx:web-service.com -all"
Example.org IN TXT "v=spf1 +a +mx +a:mail.web-service.com -all"
у першому випадку ми дозволимо прийом пошти також від усіх серверів, перерахованих у MX-записах домену web-service.com, у другому випадку тільки для сервера mail.web-service.com.
На завершення розглянемо випадок, коли пошта для вашого домену обслуговується сервером, який знаходиться в іншому домені. Наприклад mail.example.comнадсилає також пошту для домену example.org. У цій ситуації буде правильно використовувати для домену example.orgті ж самі правила, що і для example.com. Для цього використовуйте спеціальний видзапису:
Example.org IN TXT "v=spf1 redirect=example.com"
Це дозволить при необхідності змінювати записи тільки один раз, для основного домену і позбавляє адміністраторів інших доменів, що обслуговуються, від необхідності відстежувати і вносити зміни в DNS-записи.
Теги:
Для коректної роботипоштового сервера важливо мати правильно налаштовану DNS зону, в якій повинні бути присутніми A, MX та PTR-записи. Якщо з першими двома все більш-менш зрозуміло, то налаштування PTR-запису ( зворотної зони, коли необхідно перевірити ім'я сервера знаючи його IP-адресу) не рідко викликає складнощі у розумінні, де вона має бути прописана і хто за неї відповідає. Без PTR-запису частина поштових серверів відмовиться приймати пошту з вашого сервера, відправивши вам у відповідь приблизно таку лайку:
550-There is no reverse (PTR) запису, що використовується для вашого користувача, або як запис не 550 відповідь PTR запису (в reply до RCPT TO command) 550-Reverse DNS скинути необхідний. Якщо ви думаєте, що це є, 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)
Тож у чому, власне, полягає складність? По-перше - непорозуміння як влаштована та працює DNS, а по-друге - банальне небажання деяких провайдерів виконувати свої прямі обов'язки чи некомпетентності "технічних фахівців", на кшталт самі дурні. На жаль, зустрічається і таке. Але давайте спробуємо розібратися.
Розглянемо поширену ситуацію. З якихось причин вам перестало вистачати можливостей поштового сервера, що надається хостингом, там, де знаходиться ваш сайт (або ви зареєстрували домен і хочете налаштувати свій поштовий сервер). У свого провайдера ви отримали статична ip-адреса(або навіть невелику підмережу) і на хостингу прописали А і MX записи із зазначенням на вашу поштовику (та сама, виділена вам провайдером ip-адреса).
А ось далі бувають непонятки, хто ж повинен розмістити у себе PTR-запис про ваш поштовий сервер - хостер (той у чиїм віданні знаходяться DNS-сервера, відповідальні за ваш домен) або провайдер (той, хто видав вам статичну ip-адресу). Для визначення імені вузла за його IP-адресою передбачена особлива доменна зона in-addr.arpa.
Так ось, хто видав вам статичну IP-адресу, той і прописує на своєму DNS-сервері PTR-записудля поштового сервера в зоні in-addr.arpa. Для цього необхідно надіслати запит тому, хто видав вам статичну IP-адресу з проханням зареєструвати PTR запис для вашого домену.
Примітка: якщо адреси домену та поштового сервера не співпадають, PTR-запис повинен створюватися саме для MX-запису.
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і пишемо:
> set type=PTR<-- установили тип ресурсной записи > 93.158.134.89 <-- интересующий ip-адрес ----- полученный ответ ----- Не заслуживающий доверия ответ: 89.134.158.93.in-addr.arpa name = mx.yandex.ru 134.158.93.in-addr.arpa nameserver = ns1.yandex.net 134.158.93.in-addr.arpa nameserver = ns2.yandex.net ns1.yandex.net internet address = 213.180.193.1 ns2.yandex.net internet address = 93.158.134.1 >
У полі `name` бачимо ім'я одного з поштових серверів яндексу. При правильному налаштуваннізворотної зони, дане поле має відобразити ім'я вашого поштового сервера за відповідною IP-адресою.
Існує багато типів DNS записіві для новачків може бути занадто складно зрозуміти, яка функція цього DNS-запису або як його налаштувати. У цьому уроці ви дізнаєтеся, що таке PTR запис і як перевірити чи налаштований він для IP-адреси.
Що таке PTR запис
PTR запис – це як зворотна версія запису A. A запис зв'язує доменне ім'я з IP-адресою, а PTR запис пов'язує IP-адресу з ім'ям хоста. Однак ці два записи є незалежними один від одного.
Навіщо необхідний PTR запис
Вона є корисною для вихідних поштових серверів. Цей запис підвищує надійність сервера, що відправляє, і дозволяє отримати зворотну відповідь для перевірки імені хоста через IP-адресу. Це відмінний спосібзахисту від усіх видів спамерів, які використовують шахрайські доменні імена для розсилки спаму. Ось чому деякі великі провайдерипослуги пошти, такі як yahoo.com, gmail.com роблять зворотний пошук у DNS, перш ніж приймати вхідні листи.
Перед тим, як ви почнете це керівництво, вам знадобиться таке:
- Доступ до консолі комп'ютера (необов'язково)
Спосіб 1 - Перевірка PTR за допомогою nslookup або dig
Windows, Unix та подібні Операційні системи(Linux, MacOS) мають вбудовані інструменти для перевірки DNSзаписів. Якщо ви є користувачем Windows, дотримуйтесь цих етапів:
- Увійдіть до меню Пуск Windows , впишіть cmd та натисніть ENTER.
- Повинно з'явитися чорне вікно ( командна строка windows).
- Впишіть наступну команду для отримання імені хоста IP-адреси (змініть IP_ADDESS на потрібний вам IP):
- Наприклад, якщо ви хочете перевірити PTR запис для 54.243.154.xx, ви побачите схожий результат:
Як видно з результату, PTR запис – ec2-54-243-154-49.hostinger.com.
Для користувачів Linuxабо Mac процессхожий:
- На MacOS, увійдіть в термінал за допомогою ( F4). Більшість дистрибутивів Linuxдозволяють відкрити термінал поєднанням клавіш Ctrl+Alt+T.
- Використовуйте цю команду для перевірки PTR запису (змініть IP_ADDRESS на потрібний вам IP):
- Наприклад, результат перевірки PTR запису для IP адреси 54.243.154.xx:
З розділу ANSWER SECTIONможна дізнатися значення PTR запису – ec2-54-243-154-49.hostinger.com
Спосіб 2 - Використання онлайн інструментів
Ще один спосіб отримати інформацію про ім'я хоста IP-адреси, це використовувати інструмент для зворотного пошуку MxToolBox . Все, що потрібно, це вписати в поле IP адресу і натиснути кнопку Reverse Lookup (Зворотній пошук).
Висновок
На жаль, якщо пошук показує, що запис не налаштований для IP-адреси, в більшості випадків вам доведеться звернутися до вашого хостинг-провайдера або інтернет-провайдера з проханням створити його. Однак тепер ви знаєте, що таке PTR запис і як перевірити чи має IP-адресу. Це корисно, якщо ви зіткнулися з помилками DNS і поверненнями при спробі надіслати електронну пошту, оскільки це допоможе вам вирішити проблему.
Усі поштові сервери, які здійснюють підключення до поштових серверів, повинні мати валідні та осмислені зворотні DNS записи.
Коректно налаштовані адреси rDNS потрібні, щоб надсилати повідомлення з вашого власного сервера. Практично всі поштові сервери відкинуто прийом повідомлення ще на стадії початку сесії, якщо IP-адреса вашого сервера відсутня запис у зворотній зоні DNS. Причина відмови віддаленим поштовим сервером може бути такою:
550-"IP-адреса не має PTR (адреса до електронної пошти) запису в DNS, або якщо PTR повідомлень не має жодного запису A (посилання на адресу) запису. Pls check and correct your DNS record." 550-There's не відповідають PTR для вашої IP-адреси (IP-адреси), які є 550 required. Sorry, bye.
Число 550 у всіх трьох випадках є стандартним кодом поштового SMTP сервера, що повідомляє про критичну помилку, яка перешкоджає подальшій роботі в рамках цієї поштової сесії. Взагалі, всі помилки серії 500 є критичними і продовження передачі пошти після їх появи неможливо. Текст пояснює причину відмови більш докладно і повідомляє, що адміністратор поштового сервера-отримувача налаштував його на перевірку наявності у поштового сервера-відправника запису в зворотній зоні DNS (rDNS) і у разі її відсутності сервер-отримувач зобов'язаний відмовляти відправнику в з'єднанні (SMTP- помилки серії 5XX).
Налаштування rDNS
Правами на налаштування зворотної зони DNS (reverse DNS) має лише власник відповідного блоку IP-адрес, якій ця зона відповідає. Як правило, цим власником виявляється провайдер, який володіє власною автономною системою.
Оператору блоку IP-адрес для реєстрації зворотної зони DNS необхідно зареєструвати у своєму особистому кабінеті на сайті RIPE об'єкт типу «domain», вказати адресу DNS-серверів, які підтримуватимуть зону rDNS та налаштуватимуть підтримку зони виду 3.2.1.in-addr.arpa на них. За ресурси у зворотній зоні відповідає покажчик (pointer) – запис типу PTR. До неї і йдуть запити про дозвіл IP-адреси та ім'я хоста (див. нижче опис принципу побудови PTR запису).
Якщо ви не є власником автономної системи, то налаштування rDNS для IP-адреси або адрес поштового сервера вирішується запитом у службу підтримки провайдера або хостера.
В обох випадках ім'я IP-адреси поштового сервера, особливо корпоративного поштового сервера, слід давати осмислено.
Приклади хороших імен для сервера пошти:
Mail.domain.ru mta.domain.ru mx.domain.ru
Приклади поганих імен:
Host-192-168-0-1.domain.ru customer192-168-0-1.domain.ru vpn-dailup-xdsl-clients.domain.ru
Такі імена з високою ймовірністю потраплять під фільтр як призначені клієнтським комп'ютерам, на яких не може бути встановлений поштовий сервер, отже, з них ймовірно розсилається спам.
З успіхом використовувати запити до зворотних зон DNS можна і потрібно одразу після запуску поштового сервера. Для цього необхідно зробити лише невелике налаштування ПЗ. У різних поштових серверах налаштування перевірки rDNS робиться по-різному:
У Postfix необхідно включити опцію
Reject_unknown_client
Verify = reverse_host_lookup
Перевірка зворотної зони DNS: http://remote.12dt.com
Введіть свою IP-адресу, якщо відображається ваш домен - налаштування правильне
PTR
PTR-запис(Від англ. Pointer - покажчик) пов'язує IP хоста з його канонічним ім'ям. Запит у домені in-addr.arpa на IP хоста у зворотній формі поверне ім'я цього хоста.
З метою зменшення обсягу небажаної пошти сервери-отримувачі електронної пошти перевіряють наявність PTR запису для хоста, з якого відбувається надсилання. У цьому випадку PTR запис для IP адреси повинен відповідати імені поштового сервера, яким він представляється в процесі SMTP сесії.
in-addr.arpa- Спеціальна доменна зона, призначена для визначення імені хоста за його IPv4-адресою, використовуючи PTR-запис. Адреса хоста AAA.BBB.CCC.DDD транслюється у зворотній нотації і перетворюється на DDD.CCC.BBB.AAA.in-addr.arpa. Завдяки ієрархічній моделі керування іменами з'являється можливість делегувати керування зоною власнику діапазону IP-адрес. Для цього в записах авторитативного DNS-сервера вказують, що зону CCC.BBB.AAA.in-addr.arpa (тобто за мережу AAA.BBB.CCC/24) відповідає окремий сервер.
Наприклад, якщо IP поштового сервера 78.56.158.23. То в NS запис сервера або налаштування хостера необхідно додати наступний DNS запис (IP при цьому записується в зворотному порядку).
