rDNS/PTR відсутні: нудне виправлення DNS, яке рятує доставку пошти

Що таке rDNS/PTR (і чому пошті це важливо)

DNS зазвичай відповідає на питання: «Який IP-адресі відповідає mail.example.com?» Це прямий DNS (A/AAAA записи). Зворотний DNS відповідає навпаки: «Яке ім’я належить IP-адресі 203.0.113.10?» Це PTR-запис, збережений у спеціальній зоні зворотного відображення (in-addr.arpa для IPv4 і ip6.arpa для IPv6).

Для електронної пошти це зворотне відображення стає дешевим індикатором: «Чи достатньо компетентний оператор цієї IP-адреси, щоб правильно налаштувати базовий DNS, і чи виглядає заявлене ім’я узгодженим із рештою ідентичності?» Приймачі не потребують rDNS, щоб доставити пакет. Вони використовують його, щоб вирішити, чи довіряти відправнику настільки, щоб покласти повідомлення в папку «Вхідні», а не в лімб спаму.

Основне очікування щодо доставності: узгодженість

Зазвичай приймачі хочуть, щоб це збігалося:

• IP підключення SMTP-сервера має PTR, який вказує на хостнейм, наприклад mail01.example.com.
• Цей хостнейм має запис A/AAAA, що повертає ту саму підключну IP-адресу (forward-confirmed reverse DNS, часто скорочено FCrDNS).
• Ім’я в SMTP-привітанні (HELO/EHLO) співпадає (або принаймні належить до того ж доменного набору), що й цей хостнейм.
• SPF/DKIM/DMARC узгоджуються з envelope-from і/або header-from доменами (не строго про rDNS, але проблеми з rDNS часто корелюють з «інші речі теж в безладі»).

Зверніть увагу, що в цьому списку немає: «PTR має збігатися з доменом у From:». Це поширене непорозуміння. Ви можете відправляти листи як @example.com з хоста smtp-out.provider.net — це роблять багато легітимних відправників. Але якщо ви керуєте власною інфраструктурою, узгодження цих сигналів дешевше, ніж розбиратися, чому Outlook сьогодні на вас сердиться.

Практичне правило: якщо ви експлуатуєте IP, ви повинні мати можливість встановити PTR. Якщо ви не контролюєте IP (спільний хостинг, споживчий ISP, динамічна адреса), ви не запускаєте промисловий вихідний поштовий сервер; ви запускаєте експеримент.

Короткий жарт №1: Зворотний DNS — це як підписати двері офісу. Люди все одно можуть зайти до будівлі без нього, але припустять, що ви практикант і відправлять вас у папку «Спам».

Як приймачі використовують rDNS (реальна поведінка, не фольклор)

Різні приймачі по-різному оцінюють rDNS, і вони не публікують точну математику. Але rDNS з’являється в трьох місцях, які мають операційне значення:

1) Жорсткі відмови та політики доступу

Деякі організації (особливо в регульованих галузях) налаштовують вхідні шлюзи так, щоб відкидати SMTP-з’єднання без PTR або з PTR, що виглядає занадто загальним. Логіка груба: «Якщо вам байдуже налаштувати rDNS, ви несерйозні». Це примітивно, але легко пояснити аудиторам.

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

2) Оцінка спаму та обмеження швидкості

rDNS і FCrDNS часто підживлюють евристику: невідповідне або відсутнє відображення підвищує підозру, що може означати розміщення в спамі, обмеження швидкості або поведінку, схожу на greylisting. Ось де це стає бісівськи дратівливим: ваша пошта «іноді працює», за винятком 15% одержувачів, які опиняються за суворою вхідною політикою.

3) Інцидент-респонс і обробка зловживань

Коли вас позначають як джерело зловживань, хтось — людина або машина — намагається визначити, кому належить IP. PTR не є авторитетним джерелом власності, але це крихтка інформації. Чисте, узгоджене ім’я rDNS, що вказує на домен з робочими поштовими адресами postmaster/abuse, змушує світ ставитися до вас серйозніше. PTR виду ip-203-0-113-10.somecloud.internal не допоможе вашу справу.

Чого приймачі зазвичай не роблять

Приймачі зазвичай не «автентифікують» вас через PTR. PTR можна підробити тим, хто контролює делегацію зворотної зони (майже завжди провайдер/ISP). Це слабкий сигнал за своєю природою. Але слабкі сигнали — це саме те, чим харчуються фільтри спаму — багато таких сигналів, зважених і поєднаних.

Операційний підхід такий: rDNS не є магічним вирішенням проблем доставності. Це базова вимога. Ви не виграєте лише тому, що вона є; ви програєте тому, що її немає.

Факти та історія: чому це досі має значення

rDNS відчувається як «стаціонарний телефон» серед функцій DNS: всі роблять вигляд, що він застарів, але він досі керує половиною бізнес-логіки світу. Ось кілька конкретних фактів і історичних контекстів, що пояснюють, чому це ще працює:

1. PTR-записи передували сучасним захистам від спаму. Зворотне відображення існувало спочатку як зручність для іменування хостів з IP; пізніше електронна пошта взяла його як підказку довіри.
2. Зони зворотного DNS зазвичай контролюють власники IP, а не власники доменів. Ось чому ви часто не можете встановити PTR у звичайному інтерфейсі вашого DNS-провайдера.
3. Простір імен зворотного DNS відокремлений. IPv4 використовує in-addr.arpa з переверненими октетами; IPv6 — ip6.arpa з переверненими ніблами — так, це так само цікаво, як звучить.
4. «FCrDNS» (forward-confirmed reverse DNS) — це шаблон, а не протокол. Це перевірка здорового глузду: PTR → ім’я → A/AAAA → та сама IP.
5. Ранні захисні механізми від спаму опиралися на rDNS, бо це дешево. DNS-запити були простими, і багато спамерів використовували dial-up/динамічні пулі без стабільних PTR.
6. Деякі мережі навмисно ставлять загальні PTR для діапазонів споживачів. Це допомагає поштовим системам помітити «ймовірно домашніх» відправників, які намагаються запустити SMTP.
7. Електронна пошта — одна з останніх систем, що все ще цінує сигнали статичної інфраструктури. HTTP байдуже до вашого PTR. SMTP, культурно й технічно, досі звертає на це увагу.
8. Великі провайдери все частіше комбінують сигнали ідентичності. rDNS сам по собі не врятує, але відсутність PTR часто корелює з відсутністю SPF/DKIM/DMARC, і фільтри трактують кореляцію як зізнання.
9. IPv6 зробив rDNS операційно складнішим. Зворотне ім’я довге, делегація по ніблам складна, і його легко забути під час розгортання — тому це часта причина «чому v6-пошта не працює?».

Цитата, яка має бути на кожній операційній стіні, навіть якщо ви пам’ятаєте її лише під час інцидентів: Все ламається, постійно. — Werner Vogels

rDNS — це маленьке «все». Ставтеся до нього відповідно.

Швидкий план діагностики

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

Перше: виявіть реальний egress IP, що використовується для вихідної пошти

• Підтвердьте, який IP бачать одержувачі в логах SMTP або в повідомленнях про помилки.
• Якщо ви використовуєте релей, перевірте, чи у вас спільний пул чи виділені IP.
• Якщо у вас кілька інтерфейсів, NAT, Kubernetes egress або фаєрвол переписує вихідні адреси, вважайте, що ви помиляєтеся, доки не доведете протилежне.

Друге: перевірте наявність і коректність PTR

• Немає PTR? Виправляйте це в першу чергу. Припиніть сперечатися.
• PTR є, але загальний або неправильний домен? Вирішіть, чи можете ви його змінити; якщо ні — перемістіть пошту на кращий IP.

Третє: перевірте FCrDNS та SMTP-привітання

• Хостнейм у PTR має резолвитися вперед назад на той самий IP.
• HELO/ EHLO вашого MTA має бути тим хостнеймом (або адекватним псевдонімом, який коректно резолвиться).

Четверте: підтвердіть, що SPF/DKIM/DMARC не підривають вас

• Проблеми з PTR часто супроводжуються SPF «~all» і DKIM, який «працює тільки по вівторках».
• Не виправляйте один сигнал і ігноруйте решту.

П’яте: перевірте базові списки блокувань/репутацію

• Якщо ви на «брудному» IP, коректний rDNS не відмиє вашу репутацію.
• Якщо ви на новому IP, прогрівайте його; не «оптимізуйте», розсилаючи повний обсяг одразу.

Короткий жарт №2: Доставність пошти — як сантехніка: проблема рідко в модному змішувачі, майже завжди в трубі, на яку ви не дивилися.

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

Це справжні операційні завдання. Кожне включає команду, приклад можливого виводу, що це означає і яке рішення приймати. Змініть IP/домени на свої. Використовуйте машину з робочою рекурсією DNS (або вказуйте інструментам відомий резолвер явно).

Завдання 1: Визначте, яку IP-адресу ваш сервер використовує для виходу в інтернет

cr0x@server:~$ ip route get 8.8.8.8
8.8.8.8 via 203.0.113.1 dev eth0 src 203.0.113.10 uid 1000
    cache

Значення: Ваш вихідний трафік (і ймовірно SMTP egress) використовує IP 203.0.113.10.

Рішення: Цей IP — той, для якого треба мати коректний PTR. Якщо ви очікували іншу адресу, шукайте правила NAT, cloud egress або SNAT балансувальник.

Завдання 2: Знайдіть публічний egress IP ззовні вашої мережі

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

Значення: Зовнішні сервіси бачать ваш egress як 203.0.113.10.

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

Завдання 3: Перевірте PTR (зворотний DNS) за допомогою dig

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

Значення: IP має PTR, що вказує на mail01.example.com.

Рішення: Добрий початок. Далі перевірте, чи це ім’я резолвиться вперед назад на той самий IP (FCrDNS).

Завдання 4: Виявлення відсутнього PTR

cr0x@server:~$ dig -x 203.0.113.11
; <<>> DiG 9.18.24-1-Debian <<>> -x 203.0.113.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1196
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Значення: Для цієї IP не існує зворотного запису.

Рішення: Виправте rDNS у провайдера IP (cloud/ISP). Не продовжуйте «тестувати доставність», поки це не буде зроблено — ваші результати будуть шумними і здебільшого поганими.

Завдання 5: Перевірте прямий DNS для імені з PTR

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

Значення: Прямий DNS відповідає підключній IP.

Рішення: Це означає проходження FCrDNS (щонайменше для IPv4). Якщо ви бачите інший IP, виправте A-запис, очікування NAT або змініть PTR на правильне ім’я хоста.

Завдання 6: Перевірте AAAA також (якщо у вас є IPv6)

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

Значення: Хост має також IPv6.

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

Завдання 7: Перевірте IPv6 PTR

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

Значення: Існує IPv6 зворотне відображення і воно збігається.

Рішення: Добре. Якщо воно відсутнє, очікуйте, що деякі приймачі трактуватимуть вашу IPv6-доставку як підозрілу або взагалі не прийматимуть її; або налаштуйте її, або вимкніть SMTP по IPv6 до готовності.

Завдання 8: Перевірте, яке ім’я MTA використовує для HELO/EHLO

cr0x@server:~$ postconf -n | egrep '^(myhostname|mydomain|smtp_helo_name)='
mydomain = example.com
myhostname = mail01.example.com
smtp_helo_name = $myhostname

Значення: Postfix вітається як mail01.example.com.

Рішення: Тримайте це узгодженим: HELO/EHLO має бути реальним FQDN з A/AAAA, бажано такий, що відповідає PTR. Якщо ви бачите localhost або випадкове внутрішнє ім’я, виправте конфігурацію.

Завдання 9: Подивіться SMTP-привітання зовні

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

Значення: Банер показує адекватне ім’я.

Рішення: Якщо банер показує localhost або внутрішнє ім’я, виправте конфіг MTA. Деякі фільтри трактують невідповідність банера як підозру.

Завдання 10: Підтвердіть, що ім’я в TLS-сертифікаті відповідає поштовому хостнейму (необов’язково, але часто)

cr0x@server:~$ openssl s_client -starttls smtp -connect mail01.example.com:25 -servername mail01.example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer
subject=CN = mail01.example.com
issuer=CN = R3, O = Let's Encrypt, C = US

Значення: TLS-ідентичність відповідає mail01.example.com.

Рішення: Не обов’язково для rDNS, але це частина картини «узгодженого відправника». Якщо не відповідає — виправте; бажано мати якомога менше причин, аби приймачі вам не довіряли.

Завдання 11: Перевірте SPF для домену, від імені якого ви надсилаєте

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

Значення: SPF явно авторизує IP і суворий.

Рішення: Якщо SPF відсутній або не включає ваш egress IP, виправте SPF. Ідеальний PTR не компенсує невдачу SPF у багатьох приймачів.

Завдання 12: Перевірте наявність селектора DKIM (з боку DNS)

cr0x@server:~$ dig +short TXT default._domainkey.example.com | head -n 1
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Значення: Публічний ключ DKIM існує для селектора default.

Рішення: Переконайтеся, що ваш MTA підписує вихідну пошту цим селектором і що в заголовках на приймальній стороні видно DKIM=pass. Якщо DKIM не налаштовано, виправлення rDNS допоможе лише частково.

Завдання 13: Перевірте політику DMARC

cr0x@server:~$ dig +short TXT _dmarc.example.com | sed 's/"//g'
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Значення: DMARC є з політикою quarantine і суворою узгодженістю.

Рішення: Якщо DMARC відсутній, доставність може варіюватися; якщо DMARC суворий, а ваш From: домен не узгоджується з DKIM/SPF, ви підриваєте себе. Виправте узгодженість перед посиленням політики.

Завдання 14: Перевірте делегацію/авторитет зворотнього DNS (хто може встановлювати PTR)

cr0x@server:~$ dig +noall +authority -x 203.0.113.10
10.113.0.203.in-addr.arpa.  3600 IN SOA ns1.provider.net. hostmaster.provider.net. 2026010301 7200 3600 1209600 3600

Значення: Імена серверів провайдера є авторитетними для зворотної зони.

Рішення: Ви повинні встановити PTR через панель/API провайдера або запросити через техпідтримку. Зміна вашого авторитетного DNS-провайдера не допоможе.

Завдання 15: Підтвердіть, що PTR, який ви встановили, видно глобально (а не тільки в кеші локально)

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

Значення: Публічний резолвер бачить правильний PTR.

Рішення: Якщо публічні резолвери дають різні відповіді, ви переганяєтеся за пропагацією або маєте split-horizon DNS. Приймачі використовують власні резолвери; довіряйте тому, що бачать публічні резолвери.

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

cr0x@server:~$ dig -x 203.0.113.10 +noall +answer
10.113.0.203.in-addr.arpa. 300 IN PTR mail01.example.com.
10.113.0.203.in-addr.arpa. 300 IN PTR mail-gateway.example.com.

Значення: Для однієї IP існує два PTR.

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

Завдання 17: Слідкуйте за SMTP-транзакціями й знайдіть відмови, пов’язані з rDNS

cr0x@server:~$ sudo tail -n 50 /var/log/mail.log | egrep -i 'reject|rbl|helo|ptr|reverse'
Jan 03 09:14:22 mail01 postfix/smtp[12044]: host mx.remote.example[198.51.100.25] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname (in reply to RCPT TO command)

Значення: Одержувач явно відкинув через відсутнє зворотне ім’я.

Рішення: Виправте PTR негайно. Якщо PTR встановлено, перевірте пропагацію і що підключна IP збігається з тією, яку ви виправляли.

Завдання 18: Підтвердіть, що ваш MTA прив’язаний до планованого інтерфейсу/IP

cr0x@server:~$ sudo ss -ltnp | egrep ':25\s'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=912,fd=13))

Значення: SMTP слухає на всіх IPv4 інтерфейсах.

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

Завдання 19: Підтвердіть вихідну IP для SMTP на рівні пакетів

cr0x@server:~$ sudo tcpdump -ni eth0 tcp port 25 and host 198.51.100.25 -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:15:01.102938 IP 203.0.113.10.48214 > 198.51.100.25.25: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0

Значення: SMTP-з’єднання походить від 203.0.113.10.

Рішення: Цей IP — той, для якого має бути коректний rDNS. Якщо ви бачите інший джерельний IP, ніж очікували, виправте маршрутизацію/NAT або конфігурацію джерельної адреси MTA.

Завдання 20: Перевірка reverse + forward в один крок (швидка перевірка FCrDNS)

cr0x@server:~$ ip=203.0.113.10; host $ip; hn=$(host $ip | awk '/domain name pointer/{print $5}'); host ${hn%.}
10.113.0.203.in-addr.arpa domain name pointer mail01.example.com.
mail01.example.com has address 203.0.113.10

Значення: PTR повертає mail01.example.com, і це ім’я повертає ту саму IP.

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

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

1) Інцидент, спричинений хибним припущенням: «Хмара точно налаштує rDNS»

Середня компанія мігрувала з керованого поштового сервісу на «власний вихідний SMTP задля зниження витрат». План виглядав добре в таблиці: кілька VM, Postfix, релей для резервування та новий виділений діапазон IP від хмарного провайдера. Вони зберегли SPF і DKIM переважно без змін. У них навіть був моніторинг черги та затримки.

Потім почалися відмови. Не драматичний збій — гірше. Деякі клієнти отримували пошту. Дехто — ні. З’явилися дивні звернення до підтримки: «Запит на скидання пароля не приходить», «Лист із виставленням рахунку відсутній», «Ваша система глючить». Команда перевірила звичні підозри: обмеження швидкості, фільтри контенту, налаштування TLS та чи ненадсилають вони випадково з неправильного домену. Вони гордилися автоматизацією, тому природно підозрювали всіх інших.

Хибне припущення було просте: «Якщо VM має IP, rDNS буде налаштовано». Ні. У їхнього блокa IP PTR вказували на загальні імена провайдера. MTA віталось як mail.example.com, SPF авторизував IP, але зворотна ідентичність виглядала як тимчасовий хост у пулі обчислювальних ресурсів.

Виправлення було антикліматичним: запросити кастомні PTR у провайдера, зробити їх такими, що збігаються з іменем MTA, переконатися, що прямий A-запис співпадає, і чекати очищення кешів. Звіт після інциденту виявився цікавішим за сам ремонт. Вони додали пункт у передрелізний чекліст: «PTR створено та перевірено зовні для всіх вихідних IP». Це не технічний прорив; це організаційна зрілість, замаскована під нудьгу.

2) Оптимізація, що призвела до проблем: «Давайте чергувати egress IP, щоби розподілити ризик»

Інша компанія мала проблеми з доставністю і захотіла перехитрити системи репутації. Ідея: обертати вихідні IP через пул, щоби жодна IP не «накопичувала» негативну репутацію. Хтось навіть назвав це «шардингом доставності». Це формула для тривоги.

Вони побудували хиткий NAT-слой, що розподіляв вихідні SMTP-з’єднання через кілька публічних IP. У пулі були нові IP і кілька тихих роками. Їхні екземпляри Postfix не прив’язувалися до конкретного джерельного IP; мережа виконувала балансування. Інженери люблять чисті абстракції, а NAT — найчесніша брехня, яку ми собі дозволяємо.

Що сталося далі — передбачувано, якщо ви коли-небудь мали справу з електронною поштою: приймачі бачили непослідовні сигнали ідентичності. Одне з’єднання приходило з IP з PTR mail01.example.com. Інше — з IP без PTR. Третє мало PTR, що вказував на списане ім’я хоста, яке більше не мало прямого A-запису. HELO був сталим, джерельний IP — ні. Спам-фільтри не потребували докторського ступеня: вони побачили нестабільність і трактували її як ризик.

Доставність погіршилася. Дебаг став складнішим, бо повернення вказували різні джерельні IP залежно від того, яке NAT-мапування виграло того дня. «Оптимізація» розмила їхню репутацію і не дала жодній IP сформувати послідовну історію. Вони відкотилися, закріпили SMTP-egress на одному прогрітому IP з коректним rDNS, і лише потім додали другий IP — вже правильно налаштований — після стабілізації першого.

Урок не в тому, щоб ніколи не використовувати кілька IP. Урок у тому, що якщо ви не можете зберегти узгодженість ідентичності в пулі (PTR, прямий DNS, HELO, SPF), не будьте хитрунами. Пошта карає хитрощі.

3) Нудна, але правильна практика, що врятувала ситуацію: «Підхід до PTR як до продакшн-залежності»

Велике підприємство мало ритуал, що виглядав майже комічно процедурним. Кожного разу, коли виділяли новий вихідний IP — хмара, колокація, аварійне відновлення — створювався невеликий «ticket ідентичності пошти», який потрібно було закрити до того, як IP можна було використовувати. Тикет не був опціональним. У ньому був чекліст: PTR запрошено, створено прямий A/AAAA для хосту, налаштовано HELO, оновлено SPF і виконано зовнішнє валідування з машини поза корпоративним DNS.

Під час регіонального збою вони переключилися на вторинний сайт. MTA піднялися, черги спорожнилися, і клієнти майже не помітили. Чому? Бо вторинні IP ще місяці тому мали коректні PTR і прямий DNS, навіть якщо сайт здебільшого був неактивний. Ніщо не «відкривалося» під час інциденту. Нудна робота була передоплачена.

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

Це не героїчна інженерія. Це просто відмова запускати пошту з напівналаштованою ідентичністю. Манtra команди була проста: якщо ви не розгортаєте без TLS, не розгортайте без PTR.

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

Ось шаблони, які я часто бачу в продуктивних середовищах. Кожен має конкретний симптом, ймовірну корінну причину і виправлення без фатальних сподівань.

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

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

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

2) Симптом: Пошта потрапляє в спам у Microsoft/Google, але не скрізь

Корінна причина: PTR є, але загальний, неузгоджений або не резолвиться вперед назад (FCrDNS не проходить). Часто поєднується з новою/низькою репутацією.

Виправлення: Налаштуйте PTR на ім’я, яке ви контролюєте; забезпечте, щоб A/AAAA для цього імені повертали ту саму IP. Узгодьте HELO. Прогрівайте IP поступово.

3) Симптом: У повідомленнях про помилки згадується IP, якого ви не впізнаєте

Корінна причина: NAT, вихідний релей, load balancer або мультихомований сервер використовують інший egress IP, ніж очікувалося.

Виправлення: Підтвердіть egress за допомогою packet capture або перевірки маршрутів. За потреби прив’яжіть MTA до конкретного джерельного IP. Налаштуйте PTR для реальної вихідної IP.

4) Симптом: PTR вказує на хостнейм, але прямий запит дає іншу IP

Корінна причина: Хтось змінив A-запис під час міграції або PTR був скопійований зі старої інфраструктури. FCrDNS не проходить.

Виправлення: Визначте, що канонічне (зазвичай реальний поштовий хостнейм для цієї IP), потім оновіть PTR і A/AAAA так, щоб вони збігалися. Одна відправна IP — одна ідентичність.

5) Симптом: PTR вказує на localhost або внутрішнє ім’я в логах

Корінна причина: Неправильна конфігурація myhostname або HELO у MTA; банер не відповідає реальності.

Виправлення: Встановіть hostname MTA як реальний FQDN з коректним прямим DNS. Переконайтеся, що HELO використовує його. Не вітайтеся внутрішніми іменами.

6) Симптом: IPv4 OK; IPv6-пошта частіше падає

Корінна причина: Існує AAAA; SMTP пропонує IPv6; але IPv6 PTR відсутній або неправильний. Або IPv6-адреса з пулу з поганою репутацією.

Виправлення: Налаштуйте IPv6 rDNS і FCrDNS або не рекламируйте IPv6 для вихідної пошти, поки не виправите це правильно.

7) Симптом: Ви «встановили PTR», але деякі приймачі все одно кажуть, що його нема

Корінна причина: Пропагація/кешування, або ви встановили PTR для неправильної IP (часто з NAT), або ви тестували через внутрішній резолвер, який бреше.

Виправлення: Запитуйте публічні резолвери напряму. Підтвердіть підключну IP у логах. Чекайте TTL-ів, але не плутайте очікування з виправленням.

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

Корінна причина: PTR скинувся на провайдерський дефолт; SPF не оновлено; HELO не збігається; холодний старт репутації IP.

Виправлення: Розглядайте міграції як міграції ідентичності. Попередньо підготуйте PTR і прямі записи. Прогрівайте нові IP. За можливості тримайте старого відправника працюючим під час переходу.

Контрольні списки / покроковий план

Покроково: як безпечно виправити відсутній PTR

1. Визначте реальні відправні IP. Використовуйте повернення, логи SMTP або захоплення пакетів. Не вгадуйте.
2. Оберіть канонічний поштовий хостнейм для кожної відправної IP. Наприклад: mail01.example.com для 203.0.113.10. Тримайте його стабільним.
3. Спочатку створіть прямий DNS. Додайте A (і AAAA, якщо потрібен) для хостнейма, що вказує на відправну IP.
4. Запросіть/встановіть PTR у провайдера. Вкажіть його на канонічний хостнейм. Уникайте множинних PTR.
5. Перевірте FCrDNS. PTR резолвиться в ім’я; ім’я резолвиться назад у ту саму IP.
6. Вирівняйте HELO/EHLO. Налаштуйте MTA так, щоб він вітатися як канонічний хостнейм.
7. Переконайтеся, що SPF включає відправні IP. Використовуйте сувору політику, якщо можете її підтримати.
8. Переконайтеся, що DKIM підписування працює наскрізь. Перевіряйте заголовки повідомлень на стороні одержувача.
9. Перевірте узгодженість DMARC. Особливо якщо ви застосовуєте quarantine/reject.
10. Моніторьте черги і повернення протягом 48–72 годин. Очікуйте, що частина кешів відстає. Корелюйте за доменом одержувача.
11. Документуйте межі відповідальності. Хто може змінювати PTR (провайдер), хто керує прямими записами (ви) і який SLA.

Операційний чекліст: перед введенням нового вихідного IP у експлуатацію

• PTR встановлено і перевірено щонайменше з двох публічних резолверів.
• A/AAAA для PTR-хостнейма існують і відповідають IP.
• MTA HELO-ім’я — цей хостнейм; банер збігається.
• SPF оновлено для доменів-відправників.
• Опубліковано селектор DKIM; підписування увімкнено; тестова пошта показує DKIM=pass.
• DMARC на місці і узгоджений з вашою стратегією автентифікації.
• IPv6 або повністю налаштовано (включно з rDNS), або спеціально відключено для SMTP.
• Встановлено обмеження виходу; є план прогріву для нових IP.
• Логи дозволяють простежити message-id → домен одержувача → відправну IP.

Чого уникати, коли вас тягне «просто змусити працювати»

• Не використовуйте динамічну/домашню IP для вихідної пошти.
• Не чергуйте джерельні IP без послідовного rDNS і прогрітої репутації.
• Не встановлюйте PTR на хостнейм, який не існує в прямому DNS.
• Не вітаєтесь як localhost, внутрішнє ім’я або ім’я без A/AAAA запису.
• Не публікуйте AAAA для поштового хостнейма, якщо не можете встановити IPv6 PTR.
• Не припускайте, що ваші DNS-тести відображають те, що бачать зовнішні приймачі; тестуйте через публічні резолвери.

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

1) Чи обов’язково мати PTR-запис, щоб відправляти пошту?

Технічно SMTP можна надсилати без нього, але багато приймачів карають або відкидають такі листи. На практиці відсутній PTR — це самозавдана шкода доставності.

2) Хто контролює PTR — мій DNS-провайдер чи мій ISP/хмара?

Контролює власник IP. Зазвичай це ваш ISP або хмарний провайдер. Ваш звичайний авторитетний DNS-провайдер керує прямими записами (A/AAAA), а не PTR.

3) Чи має PTR збігатися з доменом у From:?

Не обов’язково. PTR має відображати ідентичність відправної інфраструктури (hostname сервера). Якщо ви керуєте своїм доменом, найчистіше, коли PTR-хостнейм належить вашому домену, але він не повинен точно збігатися з доменом у From:.

4) Що таке FCrDNS і чи воно обов’язкове?

FCrDNS означає PTR → hostname → A/AAAA → та сама IP. Це не вимога протоколу, але це поширена перевірка здорового глузду. Проходження зменшує підозру.

5) Чи може одна IP мати кілька PTR-записів?

Може, але зазвичай не варто. Для пошти одна відправна IP має мати одну стабільну ідентичність. Кілька PTR створюють двозначність і можуть шкодити евристиці.

6) Якщо я виправлю PTR, чи відновиться доставність миттєво?

Іноді ви побачите негайне покращення в жорстких відмовах. Розміщення в спамі може зайняти більше часу, бо системи репутації мають пам’ять. Виправлення PTR припиняє кровотечу; воно не зітре історію.

7) А що щодо IPv6 — чи потрібен там PTR теж?

Якщо ви доставляєте пошту по IPv6 — так. Деякі приймачі суворіші щодо IPv6, бо зловмисникам легше отримати великий простір адрес. Якщо не можете налаштувати IPv6 rDNS правильно — не рекламyйте IPv6 для SMTP.

8) Мій провайдер дозволяє лише PTR виду ip-203-0-113-10.provider.net. Чи нормально це?

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

9) Чи замінює PTR SPF/DKIM/DMARC?

Ні. PTR — це слабкий інфраструктурний сигнал. SPF/DKIM/DMARC — це сигнали автентифікації та політики. Сучасні фільтри використовують усі ці дані разом з репутацією і контентом.

10) Яке ім’я слід використати для PTR?

Використовуйте стабільний, присвячений хостнейм для вихідної пошти: mail01.example.com або smtp-out.example.com. Переконайтеся, що він має відповідний A/AAAA і що ваш MTA використовує його для HELO.

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

1. Знайдіть реальний SMTP egress IP. Не довіряйте схемам; довіряйте захопленням пакетів і повідомленням про повернення.
2. Зробіть три запити: dig -x <ip>, dig A <ptr-name>, і (якщо потрібно) dig AAAA <ptr-name>. Домовтеся, щоб вони узгоджувалися.
3. Виправте HELO/банер вашого MTA, щоб це було реальним, резольвованим FQDN, що відповідає вашій PTR-ідентичності.
4. Перевірте зовні через публічні резолвери, щоб не купитися на внутрішньому DNS.
5. Потім працюйте над узгодженням SPF/DKIM/DMARC і прогрівом IP. rDNS проходить вас через «ви серйозні?» гейт; автентифікація впускає вас у будівлю.

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