Defaults.Exposed › Виправлення › Reverse DNS (PTR)

Як виправити Reverse DNS (PTR)

Зворотний DNS — це посвідчення особи для сервера, що надсилає пошту вашого бізнесу. Коли приймальний провайдер, як Gmail або Microsoft 365, перевіряє, хто стоїть за адресою відправника і отримує ім'я, що відповідає дійсності, — ваша пошта виглядає легітимно. Коли немає посвідчення — або ім'я і номер не збігаються — ваші цілком справжні рахунки і пропозиції сприймаються як підозрілі і тихо потрапляють до спаму або відхиляються.

Висновок для вашого бізнесу: Ваші рахунки, пропозиції і відповіді клієнтам тихо потрапляють до спаму або взагалі не доходять — тому угоди зависають, платежі запізнюються, а клієнти думають, що ви їх проігнорували, і жодне з цього не відображається як помилка, яку ви б помітили.

Що це може вам коштувати

• Ви надсилаєте пропозицію гарячому потенційному клієнту, вона потрапляє до спаму, і він обирає конкурента, що 'насправді відповів' — а ви так і не дізнаєтесь, що лист не дійшов.
• Рахунки клієнтам зникають у небажаних листах, платежі запізнюються на тижні, і ваш грошовий потік відчуває удар, бо ніхто ніколи не бачив листа.
• Клієнт скаржиться, що ви ніколи не відповіли — але ви відповіли. Їхній поштовий провайдер тихо викинув вашу відповідь, бо ваш сервер відправника не міг підтвердити, хто він такий.
• Ваш домен проходить усі перевірки безпеки нового клієнта, а потім отримує позначку через те, що ваш поштовий сервер не має належної ідентифікації — дрібниця, що змушує вас виглядати недбало.
• Ви перейшли на дешевий VPS або новий застосунок для відправки розсилок і рахунків, і протягом ночі ваш рівень доставлення впав — бо цей новий сервер не має посвідчення особи зворотного DNS і великі провайдери вже не довіряють йому.

Чому це важливо. Кожен великий поштовий провайдер перевіряє особу сервера, що надсилає вашу пошту, і перевіряє при кожному повідомленні. Якщо цей сервер не може підтвердити, хто він такий — або якщо його ім'я і номер суперечать один одному — ваша справжня ділова пошта обробляється так, ніби може бути спамом. Ви втрачаєте відповіді, платежі і довіру, і оскільки нічого не повертається, ви зазвичай ніколи не дізнаєтесь чому.

Коротко

Коли ваш бізнес надсилає лист, він відходить від поштового сервера, і кожен сервер в інтернеті має числову адресу — свій IP. Зворотний DNS (запис «PTR») — це посвідчення особи цього сервера: він дозволяє будь-кому, хто бачить номер, знайти правильне ім’я за ним, наприклад mail.yourcompany.com.

Великі приймальні провайдери — Gmail, Microsoft 365, Yahoo — перевіряють це посвідчення при кожному листі, що ви надсилаєте. Сервер, що може назвати себе і в якого ім’я і номер збігаються між собою, виглядає як законний поштовий сервер. Сервер без посвідчення або з посвідченням, що не відповідає дійсності, виглядає точнісінько як анонімні, одноразові машини, що використовують спамери. Тому ваші справжні рахунки і пропозиції розпочинають кожну розмову під підозрою — і багато з них програють.

Неприємна частина в тому, що ніщо вам про це не повідомляє. Немає повернення, немає помилки. Ваша пошта просто тихо недопрацьовує.

Що це може коштувати вам

Ось повсякденні способи, якими відсутній або невідповідний запис зворотного DNS перетворюється на втрату грошей і довіри.

• Пропозиція, що так і не дійшла. Ви надсилаєте детальну пропозицію потенційному клієнту, який просив її зранку. Їхній провайдер не може підтвердити ваш сервер відправника, тому відправляє повідомлення до спаму. Вони не переглядають небажану пошту. Опівдні вони беруть пропозицію конкурента — ту, що «насправді з’явилася». Ви пишете це неактивному ліду; насправді ваш лист ніколи не побачили.
• Рахунок у пустоті. Ви виставляєте рахунок хорошому клієнту. Він потрапляє до папки небажаних. Через тридцять днів ви переслідуєте прострочений платіж — і тепер маємо незручну розмову, натягнуті відносини і розрив грошового потоку, якого можна було повністю уникнути.
• «Ви так і не відповіли». Клієнт роздратований тим, що ви проігнорували його запитання. Ви не ігнорували — відповіли того ж дня. Їхній поштовий провайдер тихо викинув вашу відповідь, бо ваш сервер відправника виглядав ненадійно. Ви виглядаєте непрофесійно за те, що насправді зробили правильно.
• Самостійно налаштований сервер відправника, що тихо отруїв усе. Щоб заощадити, ваша пошта (або лише розсилки та автоматизовані рахунки) почала виходити через дешевий VPS або новий застосунок відправки. Цей сервер ніколи не отримав посвідчення зворотного DNS. Протягом ночі рівень доставлення просів по всій мережі — і оскільки немає повідомлення про помилку, знадобилися місяці, щоб навіть запідозрити причину.
• Позначка при перевірці безпеки. IT-відділ більшого клієнта проводить рутинну перевірку вашого домену під час адаптації. Все інше в порядку, але ваш поштовий сервер не має належної ідентифікації. Це незначний технічний момент, але він читається як недбалість — і тепер ви виправляєте це під тиском дедлайну або пояснюєте це, тоді як домен конкурента просто пройшов.

Спільна нитка: витрати падають на вас, вони невидимі в процесі, і виправлення безкоштовне.

Що це насправді є

Звичайний DNS перетворює ім’я на число: ви вводите yourcompany.com, і DNS повертає IP-адресу для підключення. Зворотний DNS робить навпаки — перетворює число назад на ім’я. Маючи IP 203.0.113.10, зворотний пошук (запис «PTR») відповідає mail.yourcompany.com.

Чому одержувачі дбають про це: коли ваш поштовий сервер підключається до Gmail для доставки повідомлення, Gmail бачить IP, що підключається. Перше, що робить серйозний поштовий фільтр, — запитує «хто ця машина?» — виконуючи зворотний пошук по цьому IP. Реальний бізнес-поштовий сервер має відповідь (mail.yourcompany.com). Одноразова спам-машина зазвичай ні, або має загальне ім’я, призначене провайдером, наприклад host-203-0-113-10.someisp.net. Тому наявність і якість посвідчення є одним із самих перших сигналів довіри, що застосовуються до вашої пошти — ще до SPF, DKIM або навіть змісту повідомлення.

Воно перевіряє поштовий сервер, а не ваш сайт. Це ставить людей у скрутне становище. Адреса вашого сайту часто знаходиться за CDN або проксі (як Cloudflare) і ніколи не матиме відповідного посвідчення — і це нормально, бо зворотний DNS для пошти стосується IP поштового сервера MX, цілком окремої машини. Ця перевірка правильно шукає основний поштовий сервер вашого домену (MX-запис із найнижчим пріоритетом), визначає його IP і перевіряє посвідчення цього IP.

Частина, яку більшість налаштувань неправильно виконує: воно має відповідати в обидва боки. Наявності імені на самоті недостатньо. Gmail та інші великі фільтри роблять щось суворіше, що називається forward-confirmed reverse DNS (FCrDNS):

1. Шукають IP → отримують ім’я (наприклад, mail.yourcompany.com).
2. Тепер шукають це ім’я назад → воно повинно повертатися до того самого IP, з якого почали.

Якщо два напрямки збігаються, сервер підтверджений і повністю довірений. Якщо є ім’я, але воно вказує кудись інде (або нікуди), сервер лише частково довірений — посвідчення, що не проходить другий погляд, сприймається як слабкіше, ніж можна сподіватися.

Саме так ця перевірка виставляє оцінки:

• Forward-confirmed (FCrDNS): IP іменує хост, і цей хост вказує назад на той самий IP. Повний бал — це правильна конфігурація, і саме їй довіряють одержувачі.
• Посвідчення є, але не підтверджує: є PTR-запис, але ім’я не повертається назад до IP поштового сервера. Лише частковий бал — виглядає налаштованим, але великі фільтри не довірятимуть повністю.
• Жодного посвідчення: немає PTR-запису на IP поштового сервера. Нуль балів, і реальна вартість для доставлення.

Як це виправити (безкоштовно, ~10 хвилин чиєїсь часу)

Передайте цей розділ тому, хто володіє IP-адресою вашого поштового сервера — зазвичай вашому поштовому або хостинговому провайдеру, або вашому дата-центру для сервера, що розміщується самостійно — і зверніть увагу, що виправлення безкоштовне. Це одне налаштування пошти, яке ви майже напевно не можете змінити самостійно у вашій звичайній DNS-панелі, бо зворотний DNS контролюється тим, хто володіє IP, а не тим, хто володіє доменом. Ми беремо плату лише за моніторинг коректності, ніколи за саму зміну.

Крок 1 — Знайдіть IP поштового сервера відправника. Визначте основний MX-хост домену (поштовий сервер з найнижчим номером пріоритету) і визначте його IP-адресу:

dig MX yourcompany.com        # знайдіть основний (найнижчий пріоритет) MX-хост
dig A mail.yourcompany.com    # визначте цей хост до його IP

Цьому IP потрібне посвідчення. Не використовуйте IP сайту — це інша машина і часто за CDN, що ніколи не збігатиметься.

Крок 2 — Попросіть власника IP встановити PTR-запис. Зворотний DNS знаходиться у того, хто контролює блок IP, тому запит іде до:

• Google Workspace / Gmail: управляється автоматично для власних поштових серверів Google — якщо домен, що надсилає лише через Google, чомусь показує збій, зверніться до підтримки Google. (На практиці вони проходять.)
• Microsoft 365: так само управляється автоматично для серверів Microsoft.
• Розміщений самостійно або VPS-поштовий сервер: відкрийте тікет у вашого хостинг-провайдера або дата-центру з проханням встановити PTR (зворотний DNS) для вашого IP на ваш поштовий хост. Більшість провайдерів відкривають це в панелі керування в розділі «Зворотний DNS», «rDNS» або «PTR».
• Сторонній застосунок відправки (розсилки / рахунки / CRM): якщо він надсилає з власних спільних серверів, провайдер обробляє зворотний DNS — для вас нема нічого для налаштування. Якщо він надсилає з виділеного IP, який ви купили у них, попросіть їх встановити PTR на нього.

Повідомте їм запис, який ви хочете, наприклад: 203.0.113.10 → mail.yourcompany.com.

Крок 3 — Зробіть forward-confirm (це крок, який більшість пропускає). Ім’я хоста в PTR також має вирішуватися назад до того самого IP через звичайний A-запис, яким ви керуєте у своєму DNS:

• PTR каже 203.0.113.10 → mail.yourcompany.com (це встановлює ваш провайдер).
• A-запис каже mail.yourcompany.com → 203.0.113.10 (це встановлюєте ви у вашому DNS, наприклад, Cloudflare → DNS → додайте запис A, Name mail, content 203.0.113.10).

Обидва напрямки повинні вказувати один на одного. Лише тоді це forward-confirmed і повністю довірено.

Крок 4 — Повторно перевірте ваш домен. Підтвердіть, що поштовий сервер тепер показує forward-confirmed зворотний DNS і перевірка проходить. Зміни DNS поширюються протягом кількох хвилин або годин.

Поширені помилки

• Встановлення посвідчення на IP сайту замість IP поштового сервера. Зворотний DNS для пошти стосується MX-сервера. Встановлення PTR на ваш веб/CDN-адрес нічого не дає для доставлення — неправильна машина отримує посвідчення.
• Зупинитися на «PTR існує». Ім’я на самоті дає лише часткову довіру. Якщо воно не повертається назад до того самого IP, суворі фільтри (Gmail, M365, Yahoo) не довірятимуть повністю. Завжди завершуйте forward-confirmation (Крок 3).
• Забути A-запис після встановлення PTR провайдером. Провайдер встановлює зворотну половину; ви повинні встановити пряму половину у вашому DNS. Люди роблять одне і вважають, що все готово.
• Звертатися до неправильної сторони. Відправлення запиту вашому доменному реєстратору або DNS-хосту замість власника IP призводить до «ми не можемо цього зробити» — бо вони справді не можуть. Запит має йти до того, хто володіє IP.
• Загальні імена хостів провайдера. PTR на зразок host-203-0-113-10.someisp.net технічно існує, але нічого не робить для вашого бренду або довіри. Використовуйте реальне ім’я хоста у вашому власному домені, що проходить forward-confirmation.

Де це вписується

Зворотний DNS — це ідентифікація сервера; SPF, DKIM і DMARC — це шар авторизації і захисту від видавання себе за інших на рівні домену. Вони відповідають на різні запитання, і великі провайдери перевіряють усе. SPF перераховує, які служби можуть надсилати від вашого імені; DKIM криптографічно підписує ваші повідомлення, щоб вони не могли бути підроблені; DMARC пов’язує два і повідомляє одержувачів, що робити з поштою, що не пройшла перевірку, і захищає видиме ім’я «від кого», яке бачать ваші клієнти. Зворотний DNS знаходиться під усім цим, підтверджуючи, що машина, що здійснює відправлення, є реальним, іменованим поштовим сервером. Правильно налаштуйте SPF, DKIM і DMARC для найсильнішого захисту від видавання себе за інших; правильно налаштуйте зворотний DNS, щоб новий або розміщений самостійно сервер відправника не зазнавав тихої недовіри, перш ніж решта навіть встигне показати себе. Кожне з цих виправлень безкоштовне.

FAQ