Довідник помилок / 550 5.7.25 Reverse DNS PTR failure
550 5.7.25: перевірка зворотного DNS (PTR) не пройдена
550 5.7.25 - це відмова поштового сервера отримувача, а не помилка на вашому компʼютері. Вона означає, що отримувач узяв IP-адресу, з якої прийшов лист, подивився її зворотний DNS (запис PTR) і не отримав відповіді, яка його влаштовує. Зазвичай ви бачите це в листі про недоставку або в логах власного поштового сервера, з формулюванням "reverse DNS validation failed", "no PTR record" чи "client host rejected: cannot find your reverse hostname". Стикаються з цим ті, хто надсилає пошту зі свого сервера або VPS: власники сайтів з формами звʼязку та сповіщеннями про замовлення, розробники й адміністратори поштових серверів.
Перевірте свій сайт
Через що виникає
Найчастіше PTR-запису для IP відправника просто немає: на багатьох VPS і в хмарах його не створюють, поки ви самі не попросите. Далі за поширеністю - PTR є, але не підтверджується прямим запитом: імʼя з PTR не резолвиться назад на ту саму IP, зазвичай тому, що A-запис для нього не створили або він застарів після переїзду сервера. Третій випадок - PTR технічно коректний, але типовий провайдерський (на кшталт 203-0-113-45.dynamic.example-isp.net): перевірку він проходить, та виглядає як домашнє чи динамічне підключення, і Google з Microsoft відхиляють таких відправників за будь-якого помітного обсягу. Окрема пастка - пошта йде через IPv6, а PTR є лише для IPv4.
Як виправити
- Знайдіть точну IP-адресу, з якої виходить ваша пошта. Вона є в тексті листа про недоставку, зазвичай у квадратних дужках після "client host" або "from". Це вихідна IP сервера, і вона не завжди збігається з IP, на якій відповідає ваш сайт.
- Запустіть перевірку зворотного DNS на цій сторінці для цієї IP. Вона показує імʼя з PTR, чи резолвиться це імʼя назад на ту саму IP (forward-confirmed reverse DNS - саме це перевіряють отримувачі), а також ASN і оператора мережі, тобто компанію, якій належить адреса і яка керує PTR. Якщо сервер надсилає пошту ще й через IPv6, перевірте IPv6-адресу окремо: відсутній PTR для IPv6 дає таку саму відмову, тоді як з IPv4 усе виглядає бездоганно.
- Якщо перевірка показує, що PTR немає взагалі, напишіть у підтримку компанії, яку названо оператором мережі, тобто вашого хостера чи провайдера, і попросіть встановити PTR для цієї IP на імʼя вашого поштового сервера, наприклад mail.example.com. У власній DNS-зоні це не додається: зворотний DNS належить власнику блоку адрес, окрім рідкісних випадків, коли провайдер делегував зворотну зону вам. На VPS чи виділеному сервері багато провайдерів дають поле rDNS прямо в панелі, тож спершу подивіться там.
- Якщо перевірка показує PTR, але каже, що він не підтверджується прямим запитом, полагодьте другу половину самі. Створіть або виправте A-запис (AAAA для IPv6) саме для того імені, яке повернув PTR, щоб воно вказувало на ту саму IP, дочекайтеся закінчення TTL і повторюйте перевірку, доки обидва напрямки не збігатимуться. Якщо імʼя з PTR у чужому домені, попросіть провайдера змінити PTR на імʼя, яким керуєте ви.
- Якщо перевірка підтверджує обидва напрямки, але PTR типовий провайдерський, попросіть провайдера замінити його на імʼя у вашому домені, бажано те саме, яким сервер представляється в HELO/EHLO, і залиште відповідний A-запис. На шаред-хостингу змінити це зазвичай неможливо, а з домашніх і динамічних діапазонів пошту можуть не приймати за будь-якого PTR.
- Якщо провайдер не хоче ставити нормальний PTR, не воюйте з цим: надсилайте вихідну пошту через сервер або сервіс з коректним зворотним DNS (смартхост хостера чи сервіс транзакційної пошти) або перенесіть пошту до хостера, у якого це налаштовано. Коли PTR виправлено, повторіть перевірку і надішліть тестовий лист, перш ніж чекати, що черга розійдеться сама.