Зворотний DNS-запит

Чи стосується це вас?

Ймовірно, не безпосередньо, але варто знати чому.

Якщо ви надсилаєте електронну пошту через Gmail, Google Workspace, Outlook або Microsoft 365, зворотний DNS автоматично налаштовується Google і Microsoft на їхніх власних IP-адресах відправлення. Ви його не торкаєтесь. Те саме стосується спільних IP на платформах на кшталт Mailchimp чи Klaviyo. Ці ESP керують PTR-записами для IP-адрес, з яких надсилають їхні сервери.

Зворотний DNS стає вашою проблемою, якщо ви надсилаєте з виділеної IP-адреси (через сервіс на кшталт SendGrid чи Mailgun) або запускаєте власний поштовий сервер на VPS чи хмарному екземплярі. У таких ситуаціях PTR-запис для вашого IP не встановлюється автоматично. Вам потрібно налаштувати його. А якщо він відсутній або неправильно налаштований, страждає доставлюваність вашої пошти.

Практичний тест: якщо ваші листи потрапляють у спам, а ваші DKIM, SPF та DMARC-запис усі проходять перевірку, відсутній або зламаний PTR-запис — логічно наступне, що варто перевірити.

Як працює зворотний пошук DNS

Цей процес називається Forward-Confirmed reverse DNS (FCrDNS). Ось що відбувається, коли ваш лист надходить на сервер-одержувач.

Сервер-одержувач бере IP-адресу вашого відправлення й запитує DNS для пов'язаного з нею PTR-запису (Pointer). Цей запит іде в спеціальну зону DNS під назвою in-addr.arpa. Якщо PTR-запис налаштований, запит повертає ім'я хоста, щось на кшталт mail.yourbusiness.com.

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

Ця двонаправлена перевірка і є суттю. Будь-хто може стверджувати, що надсилає з yourbusiness.com. Значно менше людей можуть маніпулювати як PTR-записом, так і прямим DNS, щоб змусити їх збігатися. Відколи Google і Yahoo посилили вимоги до масових відправників у 2024 році, Gmail тепер повертає конкретну помилку (421 4.7.23) для IP без дійсного PTR-запису. Це більше не опція для будь-кого, хто надсилає значний обсяг.

Відсутній або невідповідний зворотний DNS — одна з найпідступніших проблем доставлюваності. Вона не завжди дає чіткий відскок. Ваші листи можуть просто тихо потрапляти у спам без жодних пояснень.

Як перевірити ваш PTR-запис

Перш ніж намагатися щось виправити, перевірте, чи існує PTR-запис і чи він правильний.

MXToolbox: Перейдіть на mxtoolbox.com/ReverseLookup.aspx та введіть IP-адресу вашого поштового сервера. Він поверне PTR-запис або позначить, якщо його немає.

Командний рядок (Mac/Linux/Windows):

nslookup [your IP address]

Або на Mac/Linux:

dig -x [your IP address]

Вивід має показувати PTR-запис, що вказує на ім'я хоста вашого поштового сервера. Якщо він нічого не показує або вказує на щось загальне, як-от стандартне ім'я хоста хмарного провайдера (ec2-203-0-113-25.compute-1.amazonaws.com), це проблема, яку варто виправити.

Як налаштувати або виправити PTR-запис

Ось критична деталь, яку більшість людей роблять неправильно: PTR-записами керує той, кому належить IP-адреса (ваш хостинг- або VPS-провайдер, а не реєстратор домену).

Ви не можете встановити PTR-запис у Cloudflare чи GoDaddy. Ви встановлюєте його через DigitalOcean, Vultr, Hetzner, AWS, Linode або там, де розміщена IP-адреса вашого поштового сервера.

Загальний процес (самостійно розміщений поштовий сервер):

1. Увійдіть у панель керування вашого хостинг-провайдера
2. Знайдіть розділ мережі або керування IP (шукайте «Reverse DNS» або «PTR records»; розташування залежить від провайдера)
3. Введіть ім'я хоста вашого поштового сервера (напр., mail.yourdomain.com) як значення PTR для IP вашого сервера
4. Збережіть і дайте час на поширення DNS (зазвичай година, іноді до 48 годин)
5. Перевірте за допомогою інструменту зворотного пошуку MXToolbox

Щоб ваше налаштування пройшло FCrDNS, вам також потрібно підтвердити, що ім'я хоста вашого поштового сервера має A-запис, який перетворюється назад на той самий IP. Обидва напрямки повинні працювати.

Якщо ви на виділеному IP через ESP: SendGrid, Mailgun і подібні сервіси мають власні процеси налаштування зворотного DNS у своїх панелях керування. Для SendGrid це в Settings > Sender Authentication > Reverse DNS. Перегляньте посібник SendGrid зі зворотного DNS для повного покрокового опису. Вони генерують записи й проведуть вас через їхню публікацію.

Якщо ви на спільному IP через ESP: Провайдер керує PTR-записами для спільних IP. Вам не потрібно нічого налаштовувати.

Підтримання зворотного DNS у чистоті

Уникайте загальних хмарних імен хостів. Стандартний PTR від хмарного провайдера сигналізує про «загальний VPS-екземпляр», а не «керований поштовий сервер». Сервери-одержувачі сприймають це як жовтий прапорець. Замініть його на власне ім'я хоста, що відповідає вашому домену.

PTR — це один шар, а не весь стек. Чистий PTR допомагає встановити базову легітимність відправлення, але він працює разом із DKIM, SPF і DMARC, а не замість них. Ідеальний PTR без DKIM усе одно матиме труднощі. Спочатку налаштуйте всі три шари автентифікації; потім перевірте ваш PTR.

Перевіряйте знову після будь-яких змін інфраструктури. Якщо ви мігруєте на новий сервер, отримуєте новий IP або змінюєте хостинг-провайдера, ваш PTR-запис не переноситься автоматично. Його потрібно переналаштувати для нового IP. Легко забути. Варто перевірити.

Один PTR-запис на IP, що вказує на ім'я хоста вашого відправлення. Ваш PTR-запис має перетворюватися на те саме ім'я хоста, яке ваш SMTP-сервер оголошує в SMTP-обміні (команда HELO/EHLO). Невідповідності виглядають непослідовними для спам-фільтрів.

Пов'язані терміни

• DKIM
• DMARC-запис