Зворотній DNS (PTR): чому ваша пошта страждає і як правильно виправити rDNS

Що таке зворотній DNS (PTR) насправді — і чим він не є

DNS зазвичай відповідає: «Яка IP‑адреса відповідає цьому імені?» — це прямий запит (A для IPv4, AAAA для IPv6).
Зворотній DNS відповідає на інше питання: «Яке ім’я відповідає цій IP‑адресі?» — це PTR‑запис.

PTR‑записи живуть у спеціальних зворотних зонах:
in-addr.arpa для IPv4 і ip6.arpa для IPv6.
IPv4‑адреса на кшталт 203.0.113.45 стає зворотнім ім’ям типу
45.113.0.203.in-addr.arpa. Власник зони встановлює PTR, що вказує на хостнейм, наприклад
mail01.example.com.

Ось чим PTR не є:

• Не є автентифікацією. PTR‑запис не доводить, що ви володієте доменом. Він лиш показує, що той, хто контролює зворотню зону, зробив таку заяву.
• Не є шифруванням. Він не захищає пошту в транзиті. Це робить TLS, MTA‑STS та суміжні технології.
• Не є необов’язковим, якщо ви хочете стабільну доставку. SMTP технічно працює без rDNS; але сучасні фільтри вважають вас підозрілим, якщо ви його ігноруєте.

Сумна реальність: контроль над rDNS зазвичай має ваш ISP або провайдер хмарних послуг, бо вони контролюють виділення IP і делегування зворотніх зон.
Тобто ви не можете «просто додати PTR у Cloudflare». Ви можете додати прямі записи для свого домену там. PTR прив’язаний до зони зворотньої адреси IP.

Чому поштові системи так переймаються PTR

Пошта — це федеративна гра довіри, яку відіграють машини, яким десятиліттями брехали. Якщо ви оперуєте поштовим сервером, ви отримуєте шквал:
підбори облікових даних, бот‑мережі, зламані WordPress‑хости, «маркетингові платформи», що поводяться як шкідливе ПЗ, і цілком легітимні бізнеси з поганою гігієною.

Тому приймачі застосовують дешеві евристики. PTR — одна з найпростіших:
один DNS‑запит, один рядок, швидке судження. Це не єдиний фільтр, але це гучний сигнал у стеку оцінки спаму.

Що приймачі роблять висновком із rDNS

• Чи «призначена» ця IP‑адреса для відправлення пошти? Багато динамічних і побутових діапазонів мають PTR на кшталт cpe-, dsl-, dynamic-. Це сильне «ні».
• Чи поводиться відправник як стабільний MTA? Справжні MTA мають стабільні імена та послідовне пряме/зворотне відображення. Бот‑мережі не морочаться цим.
• Чи виглядає рядок HELO/EHLO адекватно? Багато приймачів порівнюють SMTP‑привітання з PTR‑іменем або принаймні перевіряють, чи існує резольвований хостнейм.
• Чи не намагається відправник надто хитрувати? Занадто «оптимізовані» трюки з іменами можуть обернутися проти вас. Про це далі.

Що rDNS найчастіше ламає

• Жорсткі блоки від суворих приймачів (деякі корпоративні шлюзи досі роблять «немає PTR — немає пошти»).
• Зростання спам‑балу, який підсовує вас через межу при наявності інших дрібних проблем.
• Проблеми з greylisting, бо ваша «ідентичність» виглядає непостійною під час повторних спроб.
• Системи репутації, що класифікують ваш IP‑діапазон як динамічний/помилково налаштований.

Одне речення, яке заощадить вам тиждень: rDNS стосується IP, а не домену в заголовку From:
Якщо ваш SaaS відправляє листи як billing@yourbrand.com, але відправляє з випадкової VM‑IP, чиї PTR‑ім’я — ip-10-0-3-44.internal,
ви даєте фільтрам просту причину вам не довіряти.

Цікаві факти й історія: дивна витривалість ролі PTR

Кілька контекстних нотаток, що пояснюють, чому «старе» досі болить:

1. Зворотній DNS з’явився рано. Система DNS і зворотнє відображення in-addr.arpa були визначені в 1980‑х, коли Інтернет стандартизував імена.
2. PTR передував сучасній боротьбі зі спамом. PTR не створювався для контролю спаму; але спам зробив його корисним як дешевий сигнал.
3. SMTP старший за більшість фільтрувальної логіки. Ядро SMTP було визначене тоді, коли «ідентичність хоста» була переважно чесною, а мережі менші.
4. Багато корпоративних шлюзів досі використовують «PTR обов’язковий». Це грубо, але відсіює величезну кількість сміття з мінімальними витратами CPU.
5. Forward‑confirmed reverse DNS (FCrDNS) став де‑факто очікуванням. Це не формальна вимога протоколу, але фільтри трактують це як базовий рівень.
6. IPv6 ускладнив зворотній DNS. Зворотня зона для IPv6 побудована по ніблях і довга; делегування і коректність легше порушити.
7. Хмара ускладнила власність на rDNS. Ви можете володіти доменом в одному місці, а орендувати IP в іншому — це створює оперативні «сліпі плями».
8. Великі поштові провайдери рідко документують точні оцінки. rDNS не є «ключем», але входить у ширшу позицію: стабільна ідентичність, послідовна поведінка, низький рівень скарг.
9. Динамічні шаблони PTR навмисно стигматизовані. Багато ISP маркують динамічні пули в PTR, щоб приймачі могли їх фільтрувати.

Жарт №1: PTR‑записи як бейджі на конференції — формально необов’язкові, на практиці викликають підозру, і завжди зникають, коли вони потрібні.

Швидкий план діагностики: знайдіть вузьке місце за хвилини

Коли доставлення погіршується, команди люблять сперечатися про SPF vs DKIM vs «можливо, Microsoft ляг». Почніть з того, що найшвидше спростувати.
Ось порядок, який я застосовую, коли черга дзвонить, а кава ще не подружилась із кров’ю.

1) Перевірте вихідну IP і її PTR (перш за все)

• Знайдіть фактичну вихідну IP (NAT‑шифтери, балансувальники, реле всі можуть “брехати” на кшталт).
• Переконайтеся, що існує PTR‑запис і що він виглядає як поштовий хост, а не орендна адреса DHCP.
• Зробіть forward‑confirmation: ім’я з PTR має резольвитися назад на ту саму IP.

2) Перевірте банер SMTP і узгодження HELO/EHLO (друге)

• Переконайтеся, що ваш MTA оголошує стабільний FQDN у банері і HELO/EHLO.
• Переконайтеся, що цей FQDN має A/AAAA записи і послідовний з PTR‑іменем (не обов’язково ідентичний, але не абсурдний).

3) Перевірте автентифікацію (третє)

• SPF проходить для відправної IP.
• DKIM підписує і верифікується для домену From: (або вирівняного домену).
• Політика DMARC і вирівнювання не саботують вас (особливо для транзакційної пошти).

4) Перевірте репутацію і поведінку за обсягом (четверте)

• Якщо IP новий — очікуйте потреби в прогріванні (warm‑up).
• Шукайте сплески: відскоки, скарги, раптові зміни обсягів, проблеми з якістю списків.

5) Лише потім копайтеся в контенті й шаблонах (п’яте)

• Контент важливий, але якщо ваша ідентичність зламана, ідеальні тексти не врятують вас.

Практичні завдання: команди, результати і рішення (12+)

Це прагматичні перевірки, які можна виконати з Linux‑хоста з базовими DNS‑інструментами. Кожне завдання містить: команду, що означає її результат, і рішення.
Замініть прикладну IP/домен на свої.

Завдання 1: Знайдіть публічну вихідну IP з хоста (перевірка здорового глузду)

cr0x@server:~$ curl -4 ifconfig.me
203.0.113.45

Значення: Це IPv4‑адреса, яку бачать зовнішні сервіси. Якщо очікували інше, ви за NAT або egress‑маршрути відрізняються.

Рішення: Використовуйте цю IP для перевірок PTR/SPF. Якщо це не IP пошти — зупиніться і простежте egress.

Завдання 2: Підтвердіть, яку IP фактично використовує ваш MTA (приклад Postfix)

cr0x@server:~$ postconf -n | egrep '^(smtp_bind_address|smtp_bind_address6|myhostname|myorigin|inet_interfaces) ='
myhostname = mail01.example.com
myorigin = /etc/mailname
inet_interfaces = all

Значення: Явної адреси прив’язки немає; Postfix вибере на основі маршрутизації. Ваша вихідна IP може відрізнятися від IP інтерфейсу сервера.

Рішення: Якщо вам потрібна конкретна IP, задайте smtp_bind_address (або виправте маршрутизацію/NAT), потім знову перевірте, що бачить світ.

Завдання 3: Зворотний пошук (PTR) для вашої вихідної IP

cr0x@server:~$ dig +short -x 203.0.113.45
mail01.example.com.

Значення: PTR існує і вказує на mail01.example.com.

Рішення: Продовжуйте з forward‑confirmation. Якщо порожньо — встановіть PTR у вашого ISP/хмарного провайдера.

Завдання 4: Перевірте наявність кількох PTR (зазвичай запах проблеми)

cr0x@server:~$ dig -x 203.0.113.45 +noall +answer
45.113.0.203.in-addr.arpa. 3600 IN PTR mail01.example.com.

Значення: Рівно один PTR. Кілька PTR можуть плутати фільтри й людей.

Рішення: Тримайте один стабільний PTR на відправну IP, якщо немає дуже конкретної і зрозумілої причини для інакшого.

Завдання 5: Прямий пошук PTR‑ім’я (A‑запис)

cr0x@server:~$ dig +short A mail01.example.com
203.0.113.45

Значення: PTR‑ім’я резольвиться назад на ту саму IP. Це класичний патерн «forward‑confirmed reverse DNS», який люблять приймачі.

Рішення: Якщо A вказує на іншу IP — виправте DNS або узгодьте PTR під реальність.

Завдання 6: Перевірте IPv6 rDNS теж (навіть якщо ви «переважно використовуєте IPv4»)

cr0x@server:~$ dig +short -x 2001:db8:abcd:10::25
mail01.example.com.

Значення: Ваша IPv6 теж має PTR. Добре. Якщо сервер може відправляти по IPv6, деякі отримувачі побачать саме його.

Рішення: Якщо відсутній — або додайте IPv6 PTR, або відключіть вихідний SMTP по IPv6, доки не буде все в порядку.

Завдання 7: Перевірте банер SMTP і ім’я EHLO ззовні

cr0x@server:~$ nc -v mail01.example.com 25
Connection to mail01.example.com 25 port [tcp/smtp] succeeded!
220 mail01.example.com ESMTP Postfix

Значення: Банер використовує коректний FQDN. Якщо він каже localhost або внутрішнє ім’я, ви виглядаєте аматором для фільтрів.

Рішення: Налаштуйте myhostname правильно і переконайтеся, що воно резольвиться в публічному DNS.

Завдання 8: Підтвердіть рядок HELO/EHLO під час тестової сесії

cr0x@server:~$ printf "EHLO test.example.net\r\nQUIT\r\n" | nc -w 3 mail01.example.com 25
220 mail01.example.com ESMTP Postfix
250-mail01.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME

Значення: Сервер відповідає своєю ідентичністю. Багато приймачів порівнюють те, що ви заявляєте в EHLO, з PTR/банером.

Рішення: Якщо EHLO‑ідентичність дивна — спочатку виправте конфігурацію MTA, а не ганяйтесь за привидами SPF.

Завдання 9: Перевірте SPF для домену From: (чи авторизує він відправну IP?)

cr0x@server:~$ dig +short TXT example.com | sed -n 's/"//g;/^v=spf1/p'
v=spf1 ip4:203.0.113.45 -all

Значення: SPF явно дозволяє IP і забороняє інші. Добре для транзакційної пошти з одного хоста.

Рішення: Якщо SPF відсутній або надто суворий щодо вашого шляху відправлення — виправте його. PTR не компенсує провали SPF.

Завдання 10: Перевірте, чи ваша IP у «динамічній» зворотній схемі імен (розпізнавання шаблонів)

cr0x@server:~$ dig +short -x 198.51.100.77
cpe-198-51-100-77.isp.example.

Значення: PTR кричить «домашній інтернет». Ви можете запускати MTA звідти, але багато отримувачів ставитимуться до вас як до бот‑мережі.

Рішення: Перенесіть вихідну пошту на нормальний статичний/бізнес IP або на авторитетний ретранслятор. Не сперечайтесь із фізикою.

Завдання 11: Перевірте, що зворотня зона доступна і не повертає SERVFAIL

cr0x@server:~$ dig -x 203.0.113.45 +time=2 +tries=1
; <<>> DiG 9.18.24 <<>> -x 203.0.113.45 +time=2 +tries=1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53112
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
45.113.0.203.in-addr.arpa. 3600 IN PTR mail01.example.com.

;; Query time: 26 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:00:00 UTC 2025
;; MSG SIZE  rcvd: 96

Значення: NOERROR і є відповідь. Якщо бачите SERVFAIL — ймовірно зламана делегація або lame‑сервери зворотньої зони.

Рішення: Ескалюйте до власника IP/провайдера; це не питання «змінити MTA».

Завдання 12: Розгляньте bounce за підказками щодо rDNS/PTR (не гадати — читати)

cr0x@server:~$ grep -iE 'ptr|reverse|rdns|helo|host name|554|550' /var/log/mail.log | tail -n 6
Dec 31 12:01:12 mail01 postfix/smtp[22145]: host mx.receiver.example[192.0.2.10] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname (in reply to RCPT TO command)
Dec 31 12:01:12 mail01 postfix/smtp[22145]: to=<user@receiver.example>, relay=mx.receiver.example[192.0.2.10]:25, delay=0.6, delays=0.1/0/0.2/0.3, dsn=5.7.1, status=bounced (host mx.receiver.example[192.0.2.10] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname (in reply to RCPT TO command))

Значення: Приймач прямо відхилив вас через відсутній rDNS. Це найближче до чіткого повідомлення про помилку в електронній пошті.

Рішення: Виправте PTR і перевірте; повторно поставте пошту в чергу після виправлення.

Завдання 13: Підтвердіть, що вихідні підключення використовують ту IP, яку ви думаєте

cr0x@server:~$ sudo ss -ntp | awk '$4 ~ /:25$/ {print $4, $5}' | head
203.0.113.45:54322 192.0.2.10:25
203.0.113.45:54324 192.0.2.11:25

Значення: Джерельна IP — 203.0.113.45 для вихідного SMTP. Добре: це та IP, яку ви перевіряли.

Рішення: Якщо бачите іншу IP — ви дебагали не ту адресу. Виправте маршрутизацію/NAT або налаштування прив’язки MTA.

Завдання 14: Підтвердіть, що ваш резолвер не брешe (запитайте публічний резолвер)

cr0x@server:~$ dig +short -x 203.0.113.45 @1.1.1.1
mail01.example.com.

Значення: Публічний резолвер підтверджує. Якщо ваш локальний резолвер показує інше, у вас можуть бути проблеми з кешуванням або split‑horizon.

Рішення: Використовуйте зовнішню резоляцію як джерело істини для питання доставності. Локальний кеш не отримує пошту за вас у світі.

Жарт №2: Нічого не каже «довіра» так, як поштовий сервер зі зворотнім DNS ubuntu. Це майже як прийти в банк в підробному вусі.

Як правильно виправити rDNS: нудні, але важливі кроки

Виправлення PTR просте в концепції й дратує в реалізації, бо контрольна площина часто поза вашим постачальником DNS.
Правильний підхід — менше «хитрого DNS», більше «чітко вкажіть власність і іменування».

Крок 1: Визначте, яким має бути PTR

Оберіть хостнейм, який:

• Є повністю кваліфікованим доменним іменем, яким ви володієте (наприклад, mail01.example.com).
• Стабільний з часом (не прив’язаний до авто‑масштабованих інстансів, якщо ви це не керуєте свідомо).
• Має відповідний A‑запис (і AAAA, якщо використовуєте IPv6).
• Не прикидається доменом отримувача або чужим брендом. Фільтри не люблять «косплей».

Крок 2: Створіть прямі DNS‑записи першими (A/AAAA)

Багато провайдерів відмовляться приймати значення PTR, яке не резольвиться. Навіть якщо приймуть — forward‑confirmation вам потрібен.
Створіть:

• mail01.example.com A 203.0.113.45
• mail01.example.com AAAA 2001:db8:abcd:10::25 (якщо релевантно)

Крок 3: Встановіть PTR у того, хто володіє IP‑простором

Це та частина, де люди помиляються. PTR‑записи зазвичай не встановлюються у зоні вашого домену.
Ви встановлюєте їх:

• У консолі вашого хмарного провайдера (для еластичних/публічних IP), або
• Через запит/техпідтримку вашого ISP / колокації, або
• Через делегування зворотньої зони, якщо ви контролюєте достатньо великий блок IP (рідко, але буває в великих підприємствах).

Крок 4: Почекайте поширення, потім верифікуйте зовні

Зміни PTR поширюються як будь‑яка DNS‑зміна: кеші поважають TTL, і деякі резолвери тримають застарілі дані довше, ніж варто.
Перевіряйте з кількох мереж/резолверів. Ваш ноутбук у VPN офісу — ненадійний оракул.

Крок 5: Узгодьте ідентичність MTA з реальністю

Для Postfix базові налаштування:

• myhostname має бути публічним FQDN (часто — ім’ям PTR).
• smtpd_banner не має показувати сміття, але мусить бути послідовним.
• Сервер має використовувати це ім’я в HELO/EHLO, або за замовчуванням, або явно.

Для інших MTA (Exim, Sendmail, Exchange) принцип однаковий: ім’я, яке ви пред’являєте під час SMTP, має резольвитися і не суперечити PTR.

Крок 6: Не забувайте про край мережі

Якщо ви відправляєте через:

• NAT‑шлюзи (поширені в VPC хмари), ваша вихідна IP — це публічна IP NAT, а не внутрішня інстанс‑IP.
• Вихідні ретранслятори / smart hosts, IP і rDNS ретранслятора важливіші за ваші.
• Балансувальники (рідко для SMTP, але трапляється), впевніться, що ідентичність бекенду не «засвічується» або не суперечить.

rDNS — це не «налаштував і забув», якщо ваші маршрути змінюються щомісяця.
Включіть це в управління змінами для мережевого egress, а не покладайтеся на племінну пам’ять.

Узгодження: PTR, A/AAAA, HELO/EHLO, SPF, DKIM, DMARC

Невдала доставність любить компанію. PTR рідко буває єдиною проблемою, але часто — перша легка причина вам не довіряти.
Мета не «ідеальне вирівнювання» як на екзамені, а «відсутність очевидних суперечностей».

Правила вирівнювання, які важливі на практиці

• PTR ↔ A/AAAA: Ім’я PTR має резольвитися назад на ту саму відправну IP. Це перевірка FCrDNS.
• HELO/EHLO ↔ DNS: HELO‑ім’я має бути резольвованим FQDN з A/AAAA. Уникайте сирих IP у HELO, якщо ви не любите фільтри.
• SPF ↔ відправна IP: IP, що підключається до приймача, має бути авторизований SPF для envelope‑from домену (або домену HELO, залежно від логіки приймача).
• DKIM ↔ домен повідомлення: DKIM має підписувати домен, вирівняний із видимим From:, щоб DMARC пройшов.
• DMARC ↔ політика: DMARC не використовує PTR, але відмови DMARC + слабкий rDNS — часта суміш, що карає.

Як виглядає «добре»

Чисте, нудне налаштування для транзакційної пошти:

• Вихідна IP: 203.0.113.45
• PTR: mail01.example.com
• A‑запис: mail01.example.com → 203.0.113.45
• SMTP‑банер/HELO: mail01.example.com
• SPF: включає відправну IP (або ретранслятор), достатньо суворий, щоб запобігти зловживанням
• DKIM: увімкнений і зі стабільними ключами
• DMARC: на початковому етапі принаймні p=none, потім посилюйте політику з ростом впевненості

Як виглядає «погано»

• PTR відсутній або вказує на ip-203-0-113-45.provider.example, тоді як ваш HELO — mail.yourbrand.com.
• PTR вказує на одне ім’я, A‑запис вказує на іншу IP, а ваш SMTP‑банер використовує третє ім’я.
• IPv6 увімкнений і використовується, але не має PTR, тож половина трафіку виглядає зламаною залежно від переваг отримувача.
• Ви відправляєте з shared IP, де не можете контролювати PTR; сусіди псують вашу репутацію.

Операційний максимум на видноті: послідовність краще за кмітливість.
Приймачі роблять патерн‑матчинг, а не читають вашу діаграму архітектури.

Парафраз ідеї Gene Kranz: «Будьте жорсткі і компетентні». У термінах доставності пошти: будьте нудними і правильними щодня.

Три корпоративні міні‑історії з практики

1) Інцидент через хибне припущення: «Ми налаштували DNS, значить rDNS налаштовано»

Середня B2B‑компанія мігрувала свій сервіс сповіщень від керованого постачальника до «self‑hosted Postfix задля зниження витрат».
Розгортання пройшло гладко: SPF оновлено, DKIM імплементовано, DMARC встановлено в режим моніторингу, шаблони протестовано.
На стейджингу доставка була нормальною. У продакшні — ні.

У черзі підтримки почали накопичуватися «ніколи не отримав скидання пароля». Продажі заголосили, бо потенційні клієнти перестали отримувати запрошення на тести.
Інженери подивилися метрики: MTA віддавав повідомлення, черга не зростала, логи показували відскоки — деякі від строгих шлюзів,
деякі від великих поштових провайдерів, а ще багато зникало в пітьмі greylisting.

Хибне припущення: команда вірила, що створення mail01.company.com і його A‑запису означає, що зворотній DNS автоматично «покрито».
Вони виконали роботу в своїй авторитативній зоні і ментально поставили галочку «DNS зроблено».
Ніхто не запитав, хто володіє зворотною зоною IP. Це були не вони.

Виправлення було непомітним. Вони відкрили запит у провайдера, щоб встановити PTR для публічної egress‑IP на mail01.company.com.
Узгодили банер і HELO у Postfix. Тимчасово відключили IPv6, доки провайдер не встановить IPv6 PTR також.
В межах дня жорсткі bounce за відсутній PTR припинилися, і затримки від greylisting зменшилися, бо ідентичність відправника перестала змінюватися.

Тривала зміна: роадмап / runbook, що каже «PTR належить провайдеру IP; перевіряйте за допомогою dig -x зовні».
Це той тип інституційної пам’яті, який приходить після приниження в продакшні перед фінансами.

2) Оптимізація, що відбилася назад: «Зробімо per‑customer rDNS для брендингу»

Платформа Enterprise захотіла, щоб кожен клієнт виглядав так, ніби листи йдуть від нього, хоча надсилались з інфраструктури вендора.
Хтось запропонував: виділити пул IP і робити PTR типу customer-a-mail.vendor.example, customer-b-mail.vendor.example,
можливо навіть використовувати домен клієнта в PTR для підвищення довіри.

На папері це виглядало розумно: сегментувати репутацію, ізолювати шумних орендарів і дати клієнтам відчуття контролю.
В реальності це стало крихкою павутиною. Зміни PTR були прив’язані до автоматики й тикетних процесів.
Іноді прямі записи відставали від PTR. Іноді HELO не оновлювався разом із відображенням клієнта.
Іноді пул крутився швидше, ніж TTL встигав завершитись.

Приймачі бачили непослідовність: підключаюча IP мала PTR customer-a-mail.vendor.example, але HELO казав mail-gw.vendor.example.
Або PTR вказував на ім’я, в якого ще не існував A‑запис.
Доставність платформи не просто впала; вона впадала періодично, що найгірше, бо породжує забобони.

Відбій був передбачуваний: «динамічна ідентичність» виглядає як зловживання.
Деякі фільтри трактують часто змінні PTR/HELO як підозрілі, бо бот‑мережі мають таке саме «жваве» поводження.
Одночасно зростав операційний тягар: більше рухомих частин, більше проблем із часом поширення, більше винятків.

Зрештою вони відкотили зміни з полегшенням. Залишили виділені IP для великих клієнтів, але повернулися до стабільної, нудної схеми імен:
невеликий набір поштових gateway‑імен з послідовним PTR і HELO, а розділення клієнтів робили на рівні envelope‑доменів і автентифікації.
Брендинг має бути в From: і DKIM‑вирівнюванні, а не в PTR‑гігантиці.

3) Нудно, але правильно, і це врятувало: перевірки перед релізом у pipeline

Компанія з високими вимогами відповідності відправляла пошту через контрольований шар ретрансляції. Вони були не швидкими, але послідовними.
Кожна інфраструктурна зміна проходила чекліст: інвентар egress‑IP, верифікація PTR, авторизація SPF, налаштування TLS, моніторинг кодів bounce.

Під час оновлення мережі був введений новий NAT‑шлюз для спрощення маршрутизації. Він працював. Трафік пішов.
Але вихідна IP змінилася. Саме тут більшість команд дізнається про rDNS суворим способом — після скарг.

Їхній pipeline помітив це раніше за користувачів. Preflight‑job зробив зворотні запити для кандидатної egress‑IP і порівняв результати
з allowlist‑ом схвалених PTR‑імен. Зміна провалила перевірку, бо NAT‑IP мала PTR за замовчуванням провайдера.
Міграцію призупинили, подали запит на PTR, і продовжили лише після проходження верифікації.

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

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: «550 5.7.1 Client host rejected: cannot find your reverse hostname»

Корінна причина: Відсутній PTR для підключаючої IP або зламана делегація зворотнього DNS.

Виправлення: Встановіть PTR у власника IP/провайдера. Перевірте за допомогою dig -x через публічний резолвер. Якщо SERVFAIL — ескалюйте питання делегації зворотньої зони.

2) Симптом: Пошта потрапляє в спам у одних провайдерів, в інбокс у інших

Корінна причина: rDNS є, але не збігається з прямим DNS (FCrDNS fail), або HELO‑ім’я не резольвиться.

Виправлення: Переконайтеся, що ім’я PTR має A/AAAA, що повертає ту саму IP, і що MTA HELO використовує резольвований FQDN, узгоджений з PTR.

3) Симптом: Все працювало до «дрібної мережевої зміни»

Корінна причина: Вихідна IP змінилася (новий NAT, новий egress), але PTR/SPF не оновлено.

Виправлення: Розглядайте egress‑IP як залежність. Оновіть PTR і SPF перед переключенням; верифікуйте зовнішніми DNS‑запитами.

4) Симптом: IPv4‑доставність OK, IPv6‑доставність жахлива

Корінна причина: Для IPv6 відсутній PTR, або AAAA вказує не туди, або провайдер не делегував IPv6‑зворотню зону.

Виправлення: Налаштуйте IPv6 PTR і AAAA правильно, або відключіть IPv6 SMTP, поки все не вирівняєте. Не дозволяйте «частково налаштованому IPv6» підривати вас.

5) Симптом: PTR налаштований правильно, але деякі приймачі все одно кажуть «no reverse»

Корінна причина: DNS‑поширення/кешування, або ви тестуєте не ту фактичну підключаючу IP, або split‑brain DNS.

Виправлення: Підтвердіть джерельну IP за допомогою ss або логів MTA; опитуйте публічні резолвери; зачекайте TTL; очистьте локальні кеші там, де треба.

6) Симптом: Ви не можете встановити PTR у UI вашого DNS‑провайдера

Корінна причина: Ви не контролюєте зворотню зону для цієї IP. Провайдер вашого домену тут недоречний.

Виправлення: Використовуйте PTR‑функцію хмари або подайте тикет ISP. Якщо ви володієте блоком IP — налаштуйте делегування зворотньої зони правильно.

7) Симптом: PTR вказує на ім’я, але A‑запис відповідає іншій IP «за задумом»

Корінна причина: Спроба абстрагуватись (балансувальник, пул або брендинг) без врахування перевірок FCrDNS.

Виправлення: Зробіть так, щоб ім’я PTR мапилось назад на ту саму IP. Якщо потрібна абстракція — реалізуйте її в вищих шарах, а не шляхом руйнування сигналів ідентичності.

8) Симптом: Доставність варіюється по орендарях/клієнтах на спільній інфраструктурі

Корінна причина: Спільна репутація IP і обмежений контроль над PTR/ідентичністю. Поведінка сусідів отруює пул.

Виправлення: Використовуйте виділені IP для вихідної пошти або надійний ретранслятор. Якщо мусите ділити — впровадьте жорсткі політики щодо зловживань і обмеження швидкостей.

Чеклісти / покроковий план

Чекліст A: Новий вихідний поштовий сервер (мінімум, щоб не соромно)

1. Обрати стабільний хостнейм для MTA: mail01.example.com.
2. Створити A‑запис: mail01.example.com → your outbound IPv4.
3. Створити AAAA, якщо використовуєте IPv6: mail01.example.com → your outbound IPv6.
4. Запросити/встановити PTR для IPv4 на mail01.example.com.
5. Запросити/встановити PTR для IPv6 на mail01.example.com (або відключити IPv6 вихід).
6. Налаштувати банер/HELO MTA на mail01.example.com.
7. Переконатися, що egress на порт 25 дозволений і стабільний (провайдери хмари інколи блокують його).
8. Налаштувати SPF так, щоб авторизувати ваші вихідні IP або ретранслятора.
9. Увімкнути DKIM‑підписування для видимого домену From:.
10. Встановити DMARC у моніторинговий режим спочатку, потім посилювати після отримання звітів і впевненості.
11. Надіслати тест на контрольовану зовнішню скриньку; перевірити заголовки на результати автентифікації.
12. Налаштувати моніторинг: коди bounce, глибина черги, аномалії швидкості, і DNS‑перевірки для PTR/FCrDNS.

Чекліст B: Коли ви змінюєте мережу (NAT, egress, провайдери)

1. Інвентар нових egress‑IP для SMTP.
2. Попередньо забезпечити PTR для кожної IP (v4 і v6).
3. Переконатися, що PTR‑імена мають A/AAAA, які повертають ті IP.
4. Оновити SPF, щоб включити нові IP (або механізм include для ретранслятора).
5. Запустити зовнішню верифікацію: dig -x через кілька резолверів.
6. Переключати поступово, якщо можливо; стежити за логами про відмови через rDNS.
7. Тримати старі IP активними доти, поки кеші і віддалені системи не зійдуться, якщо бізнес може це дозволити.

Чекліст C: Операційні запобіжники, що не дозволяють rDNS регресувати

1. Документувати, хто відповідає за зміни PTR (консоль провайдера? тикет ISP?). Призначити відповідальних.
2. Тримати інвентар вихідних IP у системі конфігурацій, а не в чиїйсь пам’яті.
3. Додати періодичну задачу для валідації: outbound IP → PTR існує → PTR‑ім’я → A/AAAA повертає ту саму IP.
4. Сповіщати при відмові, але зробити це низькошумно (достатньо щоденного контролю, якщо ви не часто міняєте IP).
5. Під час інцидентів вимагати, щоб команда ідентифікувала підключаючу IP перед тим, як дебатувати про DNS.

Питання й відповіді

1) Чи потрібен зворотній DNS, щоб пошта працювала?

SMTP все ще доставляє до деяких місць без PTR, але багато приймачів відкинуть або поставлять у спам. Якщо доставність важлива, ставте PTR як обов’язковий елемент.

2) Де створювати PTR‑запис?

У того, хто контролює зворотню зону IP — ваш ISP, хостинг‑провайдер або хмарна платформа. Звичайний DNS‑провайдер домену, як правило, не може встановити PTR для орендованих IP.

3) Чи має PTR відповідати моєму MX?

Не обов’язково. PTR має представляти підключаючий хост/IP. MX‑записи представляють маршрути для вхідної пошти домену.
Часто вони пов’язані, але змушувати їх збігатися не потрібно і може бути контрпродуктивно.

4) Що таке FCrDNS і чи потрібен він?

Forward‑confirmed reverse DNS означає: IP → PTR‑ім’я, і ім’я → A/AAAA включає ту саму IP. Це не формальний закон, але поширена перевірка фільтрів.
Якщо ви можете її виконати — зробіть. Це прибирає легку причину для недовіри.

5) Чи можна використовувати PTR як «smtp.example.com», якщо кілька IP відправляють пошту?

Можна, але тоді A/AAAA‑відображення ускладнюється. Якщо кілька IP ділять одне PTR‑ім’я, FCrDNS може провалитись, якщо forward‑запис не містить усіх IP.
Операційно чистіше мати унікальне ім’я на IP для кращої діагностики й сигналу доставки.

6) Що робити зі спільними IP, де я не контролюю PTR?

Це структурна незручність. Ви успадковуєте репутацію і інколи погану практику rDNS.
Для серйозної вихідної пошти використовуйте виділений IP або ретранслятор, де PTR і репутацією керують правильно.

7) Якщо мій PTR правильний, чи гарантовано я потраплю в інбокс?

Ні. PTR — це базова вимога, а не золотий квиток. Доставність залежить від автентифікації, репутації, рівня скарг, гігієни списків, патернів обсягів і контенту.
PTR просто прибирає причину вважати вас «непрофесіоналом».

8) Як швидко поширюються зміни PTR?

Це залежить від TTL і кешування резолверів. Очікуйте від хвилин до годин. Деякі системи тримають старі дані довше, ніж хотілося б.
Завжди перевіряйте з кількох публічних резолверів і зовнішніх мереж перед тим, як оголосити перемогу.

9) Чи вимагає DMARC PTR?

DMARC не перевіряє PTR. Але приймачі оцінюють багато сигналів разом. Успішний DMARC може бути знівечений очевидно зламаною ідентичністю хоста.
Навпаки, хороший rDNS не врятує провали DMARC.

10) Чи варто відключити IPv6, якщо я не можу отримати IPv6 PTR?

Якщо ваш MTA може відправляти по IPv6 і IPv6‑ідентичність зламана, практичним кроком є відключити вихідний IPv6, поки ви не виправите його.
Частково налаштований IPv6 — пастка для доставності.

Наступні кроки, які можна зробити сьогодні

1. Визначте реальну відправну IP. Не припускайте; перевіряйте через логи або вихідні сокети.
2. Запустіть PTR + FCrDNS перевірки принаймні через один публічний резолвер.
3. Зробіть HELO і банер MTA нудними та резольвованими. По можливості вирівняйте їх з PTR.
4. Виправляйте IPv6 свідомо. Або налаштуйте AAAA + IPv6 PTR правильно, або тимчасово не дозволяйте вихідний IPv6.
5. Операціоналізуйте це. Додайте періодичну перевірку і крок управління змінами, пов’язаний зі змінами egress мережі.

Зворотній DNS не гламурний і не принесе архітектурних нагород. Через це його часто ламають.
Але якщо ви відправляєте пошту зі своїх систем, rDNS — це різниця між «професійним сервісом» і «таємничим грілом пошти».
Обирайте нудність. Ваше місце в інбоксі скаже вам дякую.