Блог компанії 3v-Hosting
9 хв.
Коли недосвідчений адміністратор вперше налаштовує власний поштовий сервер, зазвичай усе виглядає майже підозріло просто. Встановив SMTP, відкрив 25-й порт, прописав DNS - і листи полетіли. Здається, що система працює.
Але потім починають виявлятися деякі дивні речі.
То Gmail відправляє повідомлення в спам без пояснень. То Outlook може просто обірвати з'єднання. А деякі сервери й зовсім відповідають повідомленням "550 5.7.1 Client host rejected: cannot find your reverse hostname".
У цей момент багато хто вперше стикається з таким поняттям, як reverse DNS. Ця річ настільки стара, що розмови про неї можуть здаватися чимось з епохи dial-up модемів. Але проблема в тому, що поштові сервери досі живуть за досить консервативними правилами, серед яких є й майже обов'язкове правило перевірки reverse DNS. Без нього сучасна пошта працює погано, нестабільно або взагалі ніяк. Іноді листи доходять, а іноді ні. Ну і незручним моментом також є те, що багато сервісів навіть не повідомляють безпосередньо, що проблема саме в PTR-записі.
Окрема іронія полягає в тому, що відсутність reverse DNS впливає не тільки безпосередньо на доставку електронних листів, але й здатна зіпсувати репутацію IP-адреси, присвоєної поштовому серверу, буквально за кілька годин, навіть якщо сервер новий, чистий і ще не відправив жодної масової розсилки.
Давайте в цій статті розберемося, що ж таке reverse DNS, як і де це налаштовується та як взагалі з цим працювати.
Що таке reverse DNS на практиці зрозуміти досить просто. Для цього спочатку освіжимо в пам'яті, що таке звичайний DNS.
DNS - це система, яка пов'язує доменні імена з IP-адресами. Людині зручно запам'ятати example.com, а сервери в мережі працюють з IP-адресами. Тому DNS можна собі спрощено уявити як велику таблицю, в одній колонці якої написані всі домени, а в другій колонці - відповідні їм IP-адреси.
Тобто коли ви вводите адресу сайту в пошуковий рядок браузера, браузер не знає заздалегідь, де знаходиться цей сайт. Йому потрібна IP-адреса сервера, тому система відправляє DNS-запит і запитує: "Яка IP у домену example.com?".
У результаті, після нетривалої ланцюжка перевірок, на тому чи іншому DNS-сервері (деталі опустимо) знаходиться запис, де вказано приблизно наступне:
example.com → 203.0.113.10
Ваш браузер отримує IP-адресу і вже після цього підключається до потрібного сервера.
Так ось із reverse DNS (rDNS) все відбувається у зворотному напрямку. Є IP-адреса, і потрібно з'ясувати, яке доменне ім'я за нею закріплено. І ось для цього існують так звані PTR-записи.
Знову ж таки, за аналогією, можна уявити собі всю систему DNS як телефонний довідник. В одному випадку ви знаєте ім'я людини і шукаєте її номер, а в іншому випадку у вас є номер телефону, і ви намагаєтеся дізнатися, кому він належить. Приблизно так працює різниця між звичайним DNS і rDNS.
Ось так виглядає стандартний DNS-запис, коли за іменем хоста знаходиться IP-адреса:
mail.example.com → 203.0.113.10
А ось зворотне розпізнавання, коли за IP-адресою визначається ім'я сервера:
203.0.113.10 → mail.example.com
Швидко перевірити наявність PTR-запису для тієї чи іншої IP-адреси можна командою:
dig -x 203.0.113.10
або командою:
host 203.0.113.10
І якщо все налаштовано правильно, то у відповіді ви побачите доменне ім'я.
Але на цьому перевірку закінчувати зарано, оскільки поштові системи люблять, коли пряме та зворотне розпізнавання збігаються між собою. Тому після перевірки PTR корисно переглянути й звичайний (прямий) DNS-запис:
dig mail.example.com
В ідеальній ситуації виходить замкнутий ланцюжок, коли IP вказує на домен, а домен повертає той самий IP. Саме таку конфігурацію очікують багато поштових сервісів та антиспам-систем. Іноді відсутність цієї відповідності викликає більше проблем, ніж повністю відсутній запис PTR.
Щоб зрозуміти значення reverse DNS, варто ненадовго зазирнути в історію електронної пошти.
Перші поштові системи з'явилися задовго до сучасних антиспам-фільтрів. Інтернет був значно меншим, а більшість серверів належала університетам, дослідницьким центрам і великим організаціям. Поштові вузли спілкувалися один з одним майже повністю ґрунтуючись на довірі. І якщо сервер представився коректно та зміг встановити SMTP-з'єднання, то його листи зазвичай приймалися без зайвих перевірок.
А потім Інтернет дуже швидко виріс. З'явилися ботнети, масові спам-розсилки, зламані сервери, шкідливе ПЗ та цілі мережі заражених пристроїв, які цілодобово надсилали мільйони листів. У нових умовах поштовим сервісам довелося шукати способи швидко відрізняти легітимні сервери від підозрілих.
Так поступово сформувався набір ознак, за якими оцінюється репутація поштового вузла, і Reverse DNS виявився одним із найпростіших і водночас найефективніших критеріїв.
Логіка тут досить проста. Так, якщо сервер належить компанії, організації або звичайному системному адміністратору, то його зазвичай налаштовують повністю, за всіма правилами. Тобто є доменне ім'я, налаштований hostname, прописані DNS-записи, працює SPF, підключений DKIM. PTR-запис теж присутній, тому що він входить до базового набору поштової інфраструктури.
Типовий коректно налаштований поштовий сервер виглядає приблизно так:
mail.example.com;
Відразу давайте ознайомимося і з цими визначеннями, вони нам знадобляться.
SPF (Sender Policy Framework) - DNS-запис, який вказує, які сервери мають право надсилати пошту від імені вашого домену. Дозволяє серверу-одержувачу перевірити, чи не підроблена адреса відправника.
DKIM (DomainKeys Identified Mail) - механізм цифрового підпису листів. Поштовий сервер підписує повідомлення спеціальним ключем, а одержувач перевіряє підпис і переконується, що лист не було змінено по дорозі.
DMARC (Domain-based Message Authentication, Reporting and Conformance) - політика перевірки пошти, яка об'єднує SPF і DKIM. Дозволяє власнику домену вказати, що робити з листами, які не пройшли перевірку: прийняти, відправити у спам або відхилити.
Тепер продовжимо.
З підозрілими серверами картина часто зовсім інша. Особливо це стосується заражених машин, випадково піднятих SMTP-сервісів або VPS, які використовують виключно для масових розсилок.
Для них характерні такі ознаки, як:
Для антиспам-систем це є набором дуже показових сигналів нелегітимного або шкідливого поштового сервісу.
Звичайно, наявність PTR-запису сама по собі не гарантує хорошу репутацію, оскільки спамер теж може налаштувати reverse DNS. Але відсутність PTR майже завжди виглядає підозріло. Саме тому багато поштових сервісів починають перевірку сервера з найпростіших речей: чи існує зворотний DNS-запис, чи відповідає він імені хоста і чи не виникає суперечностей між прямим і зворотним розпізнаванням адрес. Саме на цьому етапі відсівається величезна кількість сміттєвого трафіку.
Найчастіше проблема проявляється не відразу. Поштовий сервер відправляє повідомлення без помилок, SMTP-сесії завершуються успішно, у логах з'являється звичне status=sent. Тільки ось листи чомусь не доходять до одержувачів.
Одні листи опиняються в папці "Спам", інші отримують низький рейтинг довіри. Деякі поштові сервіси можуть взагалі відхилити з'єднання ще на етапі прийому повідомлення і повернути помилку:
550 5.7.1 Client host rejected: cannot find your reverse hostname
Особливо уважно наявність PTR-запису перевіряють такі глобальні поштові сервіси як Gmail, Outlook, Yahoo, а також корпоративні поштові шлюзи та популярні антиспам-системи.
Найнеприємніша ситуація виникає тоді, коли явних помилок немає. Лист прийнято до відправлення, сервер повідомив про успішну доставку, але фактична доставка стає непередбачуваною, коли одні повідомлення доходять без проблем, інші потрапляють під фільтри.
Для звичайного сайту це може означати втрату листів із форм зворотного зв'язку, повідомлень CRM або повідомлень про реєстрацію користувачів. У практичному сенсі, наприклад для інтернет-магазину, це втрачені замовлення та звернення клієнтів, а отже, і втрачені гроші.
У PTR-записів є одна особливість, яка часто збиває новачків з пантелику. Керує ними не власник домену, а власник IP-адреси.
З цієї причини додати PTR через звичайну DNS-панель домену у вас не вийде. Якщо ви орендуєте сервер у хостинг-провайдера або розмістили свій власний сервер у дата-центрі, то налаштування reverse DNS виконується через панель управління цього провайдера або дата-центру, як окрема послуга або найчастіше за запитом до служби підтримки.
Сама схема виглядає досить просто.
Спочатку для поштового сервера створюється звичайний A-запис:
mail.example.com → 203.0.113.10
Після цього для IP-адреси налаштовується зворотний запис:
203.0.113.10 → mail.example.com
На сервері бажано використовувати те саме ім'я як hostname:
hostnamectl set-hostname mail.example.com
У результаті виходить замкнутий ланцюжок перевірок, коли домен розшифровується в IP-адресу, а IP-адреса повертає той самий домен через PTR-запис.
Таку конфігурацію зазвичай називають Forward-Confirmed Reverse DNS (FCrDNS). Саме її й очікують побачити багато поштових сервісів під час перевірки SMTP-з'єднань. Чим менше розбіжностей між hostname, PTR-записом і DNS-записами домену, тим вищий рівень довіри до поштового сервера.
У різних хостинг-провайдерів механізм налаштування reverse DNS може відрізнятися.
Десь PTR можна змінити самостійно через панель управління в особистому кабінеті, а десь, у тому числі в 3v-Hosting, налаштування виконується за запитом клієнта до служби підтримки.
Для цього зазвичай потрібно вказати:
Після оновлення DNS зміни зазвичай починають діяти протягом декількох хвилин або годин.
Також важливо розуміти, що PTR майже завжди прив'язується тільки до одного домену, тобто один IP - один основний reverse DNS hostname.
На звичайному віртуальному хостингу питання, пов'язані з поштою, найчастіше вже вирішені провайдером. Поштові сервери налаштовані, PTR-записи прописані, репутація IP-адрес підтримується централізовано.
А ось у випадку з VPS-серверами ситуація інша. Адміністратор отримує практично повний контроль над своїм сервером, а разом з ним і відповідальність за налаштування поштової інфраструктури.
Тому нерідко виникає ситуація, коли Postfix або Exim начебто вже працюють, листи відправляються, а про PTR-запис ніхто навіть не згадав. У таких випадках проблема може виявитися далеко не відразу. Просто одного разу, наприклад, перестають надходити повідомлення з WordPress, повідомлення з CRM починають потрапляти в спам, а деякі одержувачі взагалі не бачать надіслані листи.
Є ще один момент, який часто викликає питання. Навіть якщо PTR налаштований правильно, вихідна пошта все одно може не працювати. І це не обов'язково помилка або недоробка провайдера.
Більше того, така практика давно стала стандартом у галузі.
Багато VPS- та хмарних провайдерів обмежують вихідні SMTP-з'єднання, особливо на нових серверах і нових акаунтах. Причина досить проста: велика частина світового спаму надсилається саме зі зламаних серверів і віртуальних машин. Якщо дозволити будь-якому новому VPS без обмежень відправляти пошту в Інтернет, то IP-підмережа дуже швидко опиниться в чорних списках.
З цієї причини провайдери вводять додаткові перевірки, тимчасові обмеження або вимагають окремого запиту на розблокування поштових портів. Така політика захищає не тільки інфраструктуру провайдера, але й звичайних клієнтів, які використовують її для легальних завдань.
Тому для повноцінної роботи поштового сервера зазвичай потрібно відразу кілька умов: коректний PTR, налаштовані SPF, DKIM і DMARC, а також відсутність обмежень на вихідні SMTP-з'єднання з боку майданчика, де розміщений VPS. Якщо один з цих елементів відсутній, проблеми з доставкою пошти цілком можливі навіть при зовні правильній конфігурації сервера.
Але PTR-записи потрібні не тільки для перевірки окремого поштового сервера. Вони давно стали одним із інструментів боротьби зі спамом на рівні дата-центрів, хостинг-провайдерів і великих поштових сервісів.
Проблема в тому, що значна частина спаму в інтернеті надсилається не з якихось спеціальних серверів зловмисників, а зі звичайних VPS. Сервер орендується за кілька хвилин, на нього встановлюється поштове ПЗ, після чого починається масова розсилка. Іноді такі сервери навіть не належать спамерам безпосередньо - це можуть бути зламані віртуальні машини або заражені сайти.
Поштові системи давно навчилися шукати характерні ознаки подібних вузлів, і одна з них - саме відсутність PTR-запису або його низька якість.
Якщо сервер намагається відправляти тисячі листів і при цьому не має коректного reverse DNS, це виглядає підозріло ще до аналізу змісту повідомлення. У деяких випадках достатньо кількох подібних сигналів, щоб IP-адреса сервера, з якого відправлялися листи, отримала негативну репутацію.
Далі механізм починає працювати досить жорстко.
Спочатку листи з цього сервера починають частіше потрапляти в спам. Потім IP може опинитися в одній з репутаційних баз або DNSBL-списків, наприклад у Spamhaus SBL. Після цього інші поштові системи починають автоматично перевіряти таку адресу та знижувати рівень довіри до повідомлень. У важких випадках нові підключення від цього IP можуть відхилятися ще до передачі листа.
Окрему увагу приділяють самим іменам хостів. Наприклад, такі PTR-записи:
ip-203-0-113-10.provider.local
або
vps123.hosting.internal
зазвичай створюються автоматично під час встановлення сервера і мало що говорять про його власника.
Для поштових систем набагато переконливіше виглядають імена, пов'язані з реальним доменом:
mail.example.com
smtp.example.com
mx1.example.com
Такий hostname показує, що сервер не просто отримав IP-адресу і почав відправляти пошту, а був налаштований адміністратором як частина повноцінної поштової інфраструктури.
Звичайно, сам по собі PTR не врятує від потрапляння в чорні списки, оскільки якщо з сервера надходить спам, то його все одно рано чи пізно заблокують. І по заслузі. Але відсутність PTR або випадкове ім'я хоста часто стають першим тривожним сигналом, через який довіра до IP починає знижуватися ще до появи реальних скарг на розсилки, і в таких випадках провайдер може знову обмежити вихідний поштовий трафік або взагалі відмовити в обслуговуванні, якщо IP-адреса вашого сервера постійно потрапляє в спам-листи.
Схожа ситуація трапляється після отримання нового VPS. Адміністратор налаштовує PTR, SPF, DKIM та інші записи, але листи все одно доставляються погано. Причина може критися в історії самої IP-адреси. IPv4-адреси давно стали дефіцитним ресурсом, тому провайдери постійно перерозподіляють їх між клієнтами. Якщо попередній власник використовував сервер для спам-розсилок або його IP встиг потрапити в репутаційні бази, наслідки можуть зберігатися ще довгий час після передачі адреси новому клієнту. У таких випадках доводиться не тільки налаштовувати поштову інфраструктуру, але й займатися відновленням репутації IP або запитувати його заміну у провайдера. Іноді проблема виявляється ширшою і зачіпає цілий діапазон адрес або навіть всю мережу дата-центру. Тому наявність PTR варто розглядати як обов'язкову умову для роботи пошти, але далеко не як єдину перевірку, яку проходять сучасні поштові сервіси.
У часи, коли антиспам-фільтри були набагато простішими, наявність PTR-запису вже вважалася хорошим ознакою коректно налаштованого сервера. Але зараз цього явно недостатньо.
Сучасні поштові системи оцінюють не якийсь один параметр, а всю інфраструктуру в цілому. Перевіряється домен, IP-адреса, історія відправки, DNS-записи, налаштування SMTP і безліч непрямих ознак, за якими можна зрозуміти, наскільки сервер заслуговує на довіру. По суті, PTR сьогодні знаходиться приблизно в тому ж становищі, що й HTTPS для сайту. Його наявність нікого не дивує, тому що це базова вимога. А ось відсутність майже відразу викликає питання.
Мінімальна конфігурація поштового сервера зазвичай включає коректний PTR-запис, hostname, SPF, DKIM, DMARC, валідні MX-записи, TLS для SMTP та чисту репутацію IP-адреси. Все це працює як єдина система, і якщо один з елементів відсутній, то ймовірність проблем із доставкою листів починає зростати.
З цієї причини при діагностиці поштових проблем завжди корисно дивитися на картину в цілому. Наприклад, сервер може мати ідеальний PTR, але перебувати в чорних списках. Або навпаки - мати бездоганну репутацію IP, але використовувати некоректний hostname.
До речі, саме hostname часто стає джерелом проблем у початківців-адміністраторів.
Ось ви налаштували сервер, запустили сайт, встановили SSL, налаштували Postfix або будь-який інший поштовий сервіс, опублікували SPF-записи в DNS тощо. На перший погляд ви все зробили правильно. Але потім з'ясовується, що сервер, як і раніше, використовує ім'я на кшталт:
ubuntu
localhost
vps123
або взагалі не має PTR-запису.
При цьому пошта може працювати частково. Листи на одну адресу доходять, на іншу потрапляють у спам, а третій поштовий сервер повністю відхиляє з'єднання. Така ситуація може залишатися непоміченою тижнями, тому що тестове відправлення на власний Gmail часто проходить успішно.
Перевірити базові налаштування можна досить просто. Для перевірки PTR достатньо виконати в консолі команду:
dig -x YOUR_IP
або:
nslookup YOUR_IP
Після цього корисно перевірити прямий DNS-запис домену і переконатися, що він вказує на ту саму IP-адресу. Потім варто подивитися hostname сервера:
hostname -f
В ідеальній конфігурації hostname, PTR-запис і DNS-записи домену повинні посилатися один на одного без суперечностей - про це ми вже писали вище більш детально.
Пошта залишається однією з найбільш консервативних технологій Інтернету. Багато механізмів перевірки були придумані десятиліття тому і продовжують використовуватися досі за логікою "працює - не чіпай". І Reverse DNS якраз є одним із таких механізмів. Звичайно, він давно перестав бути єдиним критерієм довіри до поштового сервера, але без нього повноцінна поштова інфраструктура все ще виглядає незавершеною і викликає сумніви.
Технічно можна. Але на практиці багато поштових сервісів ставляться до таких листів з недовірою, тому вони частіше потрапляють у спам або отримують низький рейтинг довіри.
Майже. Reverse DNS - це механізм пошуку доменного імені за IP-адресою, а PTR - це конкретний запис, який забезпечує його роботу. Хоча в повсякденній практиці ці терміни часто використовують як синоніми.
Зазвичай від кількох хвилин до кількох годин. Іноді зміни поширюються довше через різного роду DNS-кеші у провайдерів та поштових сервісів.
Для роботи сайту - зазвичай не потрібен. А ось для поштового сервера - майже завжди потрібен, якщо потрібна нормальна доставка листів.
Тому що, як ми з'ясували, PTR - це лише одна з безлічі перевірок. Gmail додатково оцінює SPF, DKIM, DMARC, репутацію IP-адреси та історію відправлення пошти.
Залежить від провайдера. Десь PTR можна змінити через панель управління, а десь для цього потрібно звернутися до служби підтримки.
Отже, PTR-запис належить до тих налаштувань, про які зазвичай згадують лише після появи проблем із поштою. Він не впливає на продуктивність сервера, не прискорює роботу сайту та ніяк не змінює роботу додатків. Зате саме за такими дрібницями поштові системи оцінюють, наскільки можна довіряти серверу.
Сьогодні reverse DNS входить до числа базових вимог для будь-якої поштової інфраструктури. Відсутність PTR не обов'язково призведе до негайної відмови в доставці, але майже напевно створить зайві проблеми та знизить довіру до повідомлень, що надсилаються.
Якщо сервер використовується для корпоративної пошти, надсилання повідомлень, роботи CRM, WordPress або будь-якого іншого програмного забезпечення, яке розсилає листи, то перевірка PTR має бути такою ж стандартною процедурою, як і налаштування SPF, DKIM або TLS-сертифіката.
Поштова система Інтернету досі будується на репутації та довірі. І дуже часто ця довіра залежить від налаштувань, які користувачі ніколи не побачать, а адміністратори згадують про них лише тоді, коли листи перестають доходити до адресатів.
Недосвідченому користувачеві, якому з тих чи інших причин вперше довелося орендувати віртуальний або виділений сервер, навігація та робота в середовищі Linux мо...
При виборі між VPS і хмарним хостингом дуже важливо розуміти переваги, які може надати віртуальний приватний сервер. У цій статті представлено п'ять вагомих тех...
Proxy та VPN часто плутають, але це різні інструменти. Розбираємося, як вони працюють, у чому різниця, коли використовувати кожен із них і як правильно застосов...
Як перенести сайт WordPress на VPS без Docker чи Kubernetes. Покроковий посібник з використанням Nginx, MariaDB, HTTPS, порадами з оптимізації та поширеними пом...
Дізнайтеся, що означає помилка HTTP 504 Gateway Timeout, чому вона виникає в Nginx, Cloudflare, Docker та Kubernetes, а також як правильно діагностувати та усун...
SFTP для безпечного обміну файлами: налаштування в Linux, SSH-ключі, команди та рекомендації. Дізнайтеся, як налаштувати, використовувати та захистити обмін фай...
