Czym jest rekord PTR (reverse DNS) w e-mailu?

Rekord PTR (rekord wskaźnikowy) to wpis odwrotnego DNS, który mapuje adres IP z powrotem na nazwę hosta - jest lustrzanym odbiciem rekordu A, który mapuje nazwę hosta na IP. W przypadku poczty jest to rekord, który odbierający serwer pocztowy sprawdza, aby odpowiedzieć na jedno pytanie: czy IP, które właśnie się połączyło, faktycznie jest tym, za kogo się podaje? Jeśli Twoje wysyłające IP nie ma rekordu PTR albo PTR nie zgadza się z DNS w przód, dostawcy skrzynek tacy jak Gmail traktują dziś połączenie jako niewiarygodne i mogą wprost odrzucić wiadomość.

Ma to największe znaczenie dla każdego, kto prowadzi własny serwer pocztowy na statycznym IP, ponieważ rekordy PTR znajdują się u właściciela adresu IP, a nie w strefie DNS, którą kontrolujesz dla swojej domeny. Jeśli wysyłasz wyłącznie przez dostawcę takiego jak Google Workspace, Amazon SES czy Mailgun, PTR jest już za Ciebie obsłużony na ich wysyłających IP. Jeśli hostujesz samodzielnie, to Twoim zadaniem jest zrobić to poprawnie, a od listopada 2025 roku ceną za błąd w Gmailu jest trwałe odbicie wiadomości.

Co właściwie robi odwrotny DNS

Zwykły (przedni) DNS odpowiada na pytanie "jakie jest IP dla mail.example.com?", zwracając rekord A (IPv4) lub rekord AAAA (IPv6). Odwrotny DNS odpowiada na pytanie przeciwne: "jaka nazwa hosta należy do 203.0.113.25?". Odpowiedź pochodzi z rekordu PTR.

Odwrotny DNS korzysta ze specjalnej przestrzeni nazw. Adresy IPv4 są odpytywane w in-addr.arpa z odwróconą kolejnością oktetów, więc 203.0.113.25 jest wyszukiwane jako 25.113.0.203.in-addr.arpa. IPv6 używa ip6.arpa w postaci z odwróconymi półbajtami. Rzadko wpisuje się to ręcznie, ale znajomość tego formatu wyjaśnia, dlaczego PTR jest delegowany do właściciela bloku IP, a nie do Twojej domeny.

Rekord PTR dla serwera pocztowego zwykle wygląda tak:

Zauważ, że oba rekordy wskazują na siebie nawzajem. Ta pętla to cały sens.

Reverse DNS potwierdzony w przód (FCrDNS)

Dostawcy skrzynek nie sprawdzają jedynie tego, czy rekord PTR istnieje. Uruchamiają reverse DNS potwierdzony w przód, nazywany też FCrDNS, pełnym reverse DNS, podwójnym reverse DNS lub iprev. To dwuetapowa weryfikacja zaufania:

1. Weź łączący się adres IP i sprawdź jego rekord PTR. Zanotuj zwróconą nazwę hosta.
2. Weź tę nazwę hosta i sprawdź jej rekord A lub AAAA. Czy wynik wskazuje z powrotem na pierwotne IP?

Jeśli oba kierunki się zgadzają, FCrDNS przechodzi. Jeśli PTR brakuje, wskazuje na ogólną nazwę przypisaną przez ISP (coś w rodzaju 203-0-113-25.dyn.example-isp.net) albo wyszukiwanie w przód nie rozwiązuje się z powrotem na to samo IP, FCrDNS nie przechodzi. Ogólny PTR, który mimo wszystko zamyka pętlę, przejdzie techniczną weryfikację, ale wygląda jak host domowy lub dynamiczny o niskim zaufaniu - dlatego dedykowana nazwa hosta poczty ma znaczenie.

FCrDNS jest celowo trudny do podrobienia. Atakujący może sfałszować powitanie HELO albo nagłówek From, ale nie stworzy rekordu PTR dla bloku IP, którego nie kontroluje. Dlatego odbiorcy przywiązują do niego tak dużą wagę jako do sygnału tożsamości i dlatego stoi on obok SPF, DKIM i DMARC w szerszym obrazie uwierzytelniania poczty.

Dlaczego dostawcy skrzynek tego wymagają

Dla wysyłających masowo poprawny PTR jest teraz wyraźnym wymogiem, a nie miłym dodatkiem. Google i Yahoo opublikowały zasady dla nadawców, które weszły w życie w lutym 2024 roku, a Microsoft dołączył z własnym egzekwowaniem wobec nadawców masowych w 2025 roku. Wszyscy trzej oczekują, że wysyłające IP ma poprawny reverse DNS potwierdzony w przód. Wymagania Google i Yahoo dla nadawców wymieniają go wprost obok uwierzytelniania, wypisania jednym kliknięciem zgodnie z RFC 8058 oraz niskiego odsetka skarg na spam: Google chce, aby zgłaszany przez użytkowników spam utrzymywał się poniżej 0,3 procenta, a najlepiej poniżej 0,1 procenta, dla każdego, kto wysyła ponad 5000 wiadomości dziennie.

Za tą zasadą stoi praktyczny powód. Systemy reputacji śledzą zachowanie dla każdego adresu IP. Stabilna, samookreślająca się nazwa hosta na Twoim IP pozwala odbiorcom konsekwentnie przypisywać reputację właśnie Tobie. IP bez odwrotnej tożsamości wygląda jak przejęty host, otwarty relay albo spamer typu snowshoe skaczący między adresami, więc zaczyna z deficytem zaufania, zanim jeszcze treść wiadomości zostanie odczytana.

Zaostrzenie w Gmailu z listopada 2025

Przez 2024 rok i większość 2025 roku Gmail egzekwował te zasady głównie ostrzeżeniami i tymczasowymi odroczeniami, więc nadawca bez PTR często mógł się jeszcze prześlizgnąć. Ten okres przejściowy się skończył. W listopadzie 2025 roku Gmail przeszedł od łagodnego egzekwowania do twardych odrzuceń, a wiadomości z IP bez poprawnych rekordów PTR otrzymują teraz trwałą porażkę 550 zamiast odroczenia z możliwością ponowienia.

Konkretne odbicie, które zobaczysz, to rozszerzony kod statusu 550 5.7.25 z tekstem wskazującym, że wysyłające IP nie ma wymaganego rekordu odwrotnego DNS (PTR) albo że się on nie rozwiązuje. Kiedy to dostaniesz, wiadomość nie zostanie doręczona przy kolejnej próbie - problemem jest samo wysyłające IP i trzeba to naprawić u źródła.

Gdzie znajduje się rekord PTR (i kto go kontroluje)

To najczęstszy punkt nieporozumień, więc warto powiedzieć to wprost: rekordu PTR nie ustawiasz w strefie DNS swojej domeny.

• Przedni DNS (A, AAAA, MX, TXT oraz Twoje rekordy SPF i DKIM) znajduje się u tego, kto hostuje strefę Twojej domeny, zwykle u Twojego rejestratora lub dostawcy DNS. Jeśli nie masz pewności, kto to jest, zobacz jak znaleźć swojego dostawcę DNS.
• Odwrotny DNS (PTR) znajduje się u tego, kto jest właścicielem bloku adresów IP. To Twój dostawca hostingu, firma VPS, platforma chmurowa albo ISP. Odwrotny DNS dla IP jest delegowany do nich, więc tylko oni (albo panel sterowania, który udostępniają) mogą utworzyć lub zmienić PTR.

W przypadku VPS lub serwera dedykowanego większość dostawców udostępnia w panelu sterowania pole "reverse DNS" lub "rDNS", w którym samodzielnie wpisujesz nazwę hosta. Jeśli takiego pola nie ma, zakładasz zgłoszenie do pomocy technicznej i prosisz o ustawienie PTR dla Twojego IP na Twoją nazwę hosta poczty. Nie naprawisz tego u rejestratora i żadna edycja strefy domeny nie stworzy PTR.

Jak sprawdzić swój rekord PTR

Zanim mu zaufasz, możesz zweryfikować odwrotny DNS z dowolnego terminala.

• dig -x 203.0.113.25 +short zwraca nazwę hosta PTR dla adresu IPv4.
• host 203.0.113.25 wypisuje to samo w przyjaźniejszej formie.
• nslookup 203.0.113.25 działa na systemach bez dig.

Aby potwierdzić pełną pętlę, weź otrzymaną nazwę hosta i uruchom wyszukiwanie w przód: dig mail.example.com +short. Jeśli zwróci to samo IP, od którego zacząłeś, FCrDNS przechodzi. Jeśli któreś z poleceń nie zwraca nic albo oba IP się różnią, masz lukę do zamknięcia. Sprawdzenie działającego uwierzytelniania od początku do końca razem z PTR jest łatwiejsze ze skanerem, a te same sygnały pojawiają się, gdy odczytujesz nagłówek Authentication-Results doręczonej wiadomości.

Jak naprawić niedziałający PTR

1. Zidentyfikuj swoje prawdziwe wysyłające IP. To publiczne IP, którego Twój serwer pocztowy używa do wychodzącego SMTP, a nie zawsze jest ono tym samym co Twoje IP przychodzące lub webowe. Sprawdź linie Received wiadomości testowej albo konfigurację serwera.
2. Wybierz nazwę hosta i najpierw ustaw przedni DNS. Utwórz rekord A (i AAAA, jeśli wysyłasz przez IPv6) w strefie swojej domeny, na przykład mail.example.com wskazujący na 203.0.113.25. To musi istnieć, zanim strona odwrotna zamknie pętlę.
3. Ustaw PTR u właściciela IP. W panelu sterowania swojego hosta ustaw odwrotny DNS dla 203.0.113.25 na mail.example.com. Jeśli nie ma opcji w panelu, poproś o to pomoc techniczną.
4. Dopasuj powitanie SMTP. Twój serwer pocztowy powinien ogłaszać tę samą nazwę hosta w powitaniu HELO/EHLO. W Postfiksie jest to myhostname; inne serwery nazywają to ServerName lub podobnie. PTR, który nie zgadza się z powitaniem, osłabia sygnał, nawet gdy FCrDNS technicznie przechodzi.
5. Poczekaj na propagację i przetestuj ponownie. Odwrotny DNS może zająć od kilku minut do doby. Uruchamiaj dig -x ponownie, aż zwróci Twoją nazwę hosta, a następnie potwierdź, że wyszukiwanie w przód się zgadza.

IPv6 zasługuje na szczególną uwagę. Jeśli Twój serwer ma rekord AAAA i wysyła przez IPv6, ten adres IPv6 potrzebuje własnego PTR. Wiele porażek 550 5.7.25 bierze się z serwera z włączonym IPv6, którego PTR dla IPv4 jest poprawny, ale którego PTR dla IPv6 nigdy nie ustawiono, a Gmail często preferuje połączenie IPv6. Ustaw PTR dla IPv6 albo wyłącz wysyłanie przez IPv6.

Najczęściej zadawane pytania

Czy potrzebuję rekordu PTR, jeśli używam Google Workspace lub usługi wysyłkowej?

Nie. Gdy wysyłasz przez Google Workspace, Microsoft 365, Amazon SES, Mailgun lub podobnego dostawcę, poczta wychodzi z ich adresów IP, a oni utrzymują poprawne rekordy PTR na tych IP. O PTR musisz się martwić tylko wtedy, gdy wysyłasz bezpośrednio z serwera na IP kontrolowanym przez Ciebie lub Twojego hosta. Twoją pracą przy uwierzytelnianiu są w takim wypadku SPF, DKIM i DMARC, omówione w jakich rekordów DNS potrzebuję do poczty.

Jaka jest różnica między rekordem PTR a rekordem SPF?

Weryfikują różne rzeczy. Rekord PTR dowodzi, że wysyłające IP ma prawdziwą tożsamość w odwrotnym DNS i znajduje się u właściciela IP. SPF to rekord TXT w strefie Twojej domeny, który wymienia, którym IP wolno wysyłać w imieniu Twojej domeny, i ma własne zasady, takie jak limit 10 wyszukiwań DNS, którego przekroczenie wywołuje PermError. Potrzebujesz obu; zobacz SPF, DKIM i DMARC wyjaśnione.

Dlaczego Gmail mówi, że mój PTR nie przechodzi, choć wyszukiwanie wygląda poprawnie?

Zwykłe przyczyny to niezgodność między przednim a odwrotnym DNS, brakujący PTR dla IPv6 na serwerze dwustosowym albo DNS, który nie zakończył propagacji. Potwierdź pełną pętlę: dig -x na IP musi zwrócić Twoją nazwę hosta, a wyszukiwanie w przód tej nazwy hosta musi zwrócić to samo IP. Jeśli Twój serwer wysyła przez IPv6, sprawdź adres AAAA osobno, ponieważ potrzebuje on własnego dopasowanego PTR.

Jak długo trwa wprowadzenie zmiany rekordu PTR?

Większość dostawców wprowadza zmianę odwrotnego DNS w ciągu kilku minut, ale propagacja może zająć do 24 godzin, zależnie od TTL w delegowanej strefie in-addr.arpa lub ip6.arpa. Uruchamiaj dig -x na swoim IP okresowo, aż zwróci nową nazwę hosta, i dopiero wtedy przetestuj ponownie doręczanie do Gmaila.

Odwrotny DNS to jedna z pierwszych rzeczy, które sprawdza odbiorca, i jedna z najłatwiejszych do przeoczenia, bo nie znajduje się w strefie Twojej domeny. Uruchom darmowy skan SPFWise, aby potwierdzić, że Twoja konfiguracja wysyłkowa, od zgodności PTR po SPF, DKIM i DMARC, rozwiązuje się bez zarzutu, zanim ruszy Twoja kolejna kampania.